Hey HN,

We got tired of browser frameworks restricting the LLM, so we removed the framework and gave the LLM maximum freedom to do whatever it's trained on. We gave the harness the ability to self correct and add new tools if the LLM wants (is pre-trained on) that.

Our Browser Use library is tens of thousands of lines of deterministic heuristics wrapping Chrome (CDP websocket). Element extractors, click helpers, target managemenet (SUPER painful), watchdogs (crash handling, file downloads, alerts), cross origin iframes (if you want to click on an element you have to switch the target first, very anoying), etc.

Watchdogs specifically are extremely painful but required. If Chrome triggers for example a native file popup the agent is just completely stuck. So the two solutions are to: 1. code those heuristics and edge cases away 1 by 1 and prevent them 2. give LLM a tool to handle the edge case

As you can imagine - there are crazy amounts of heuristics like this so you eventually end up with A LOT of tools if you try to go for #2. So you have to make compromises and just code those heuristics away.

BUT if the LLM just "knows" CDP well enough to switch the targets when it encounters a cross origin iframe, dismiss the alert when it appears, write its own click helpers, or upload function, you suddenly don't have to worry about any of those edge cases.

Turns out LLMs know CDP pretty well these days. So we bitter pilled the harness. The concepts that should survive are: - something that holds and keeps CDP websocket alive (deamon) - extremely basic tools (helpers.py) - skill.md that explains how to use it

The new paradigm? SKILL.md + a few python helpers that need to have the ability to change on the fly.

One cool example: We forgot to implement upload_file function. Then mid-task the agent wants to upload a file so it grepped helpers.py, saw nothing, wrote the function itself using raw DOM.setFileInputFiles (which we only noticed that later in a git diff). This was a relly magical moment of how powerful LLMs have become.

Compared to other approaches (Playwright MCP, browser use CLI, agent-browser, chrome devtools MCP): all of them wrap Chrome in a set of predefined functions for the LLM. The worst failure mode is silent. The LLM's click() returns fine so the LLM thinks it clicked, but on this particular site nothing actually happened. It moves on with a broken model of the world. Browser Harness gives the LLM maximum freedom and perfect context for HOW the tools actually work.

Here are a few crazy examples of what browser harness can do: - plays stockfish https://x.com/shawn_pana/status/2046457374467379347 - sets a world record in tetris https://x.com/shawn_pana/status/2047120626994012442 - figures out how to draw a heart with js https://x.com/mamagnus00/status/2046486159992480198?s=20

You can super easily install it by telling claude code: `Set up https://github.com/browser-use/browser-harness for me.`

Repo: https://github.com/browser-use/browser-harness

What would you call this new paradigm? A dialect?

1.	WinBoat: Drive by Client RCE and Sandbox Escape(hack.do) 2 points by mattaustin 145 days ago \| 0 comments
2.	Hacking Facebook with HTML5(m-austin.com) 2 points by mattaustin 15 years ago \| 0 comments

user:	mattaustin
created:	July 18, 2010
karma:	11