browser-harness-js vs browser-use
browser-use's thinnest LLM-to-Chrome bridge: all 652 CDP methods as typed JS calls over one WebSocket — no click() helpers, no rails; the protocol is the API. — versus — The standard library for letting AI agents drive a real browser — click, type, fill forms and complete tasks from a natural-language goal. 100k+ stars, Python.
Same team, opposite philosophy: browser-use is the batteries-included agent library with helpers; the harness strips it to 652 typed raw CDP calls and bets the model can write the protocol itself.
| browser-harness-js | browser-use | |
|---|---|---|
| Stars | 472 | 105k |
| Forks | 32 | 12k |
| Language | TypeScript | Python |
| License | MIT | MIT |
| Last activity | 2 months ago | 2 days ago |
| Topics | web | agents, web |
| Curated connections | 2 | 8 |
browser-harness-js — the curator's take
The bitter-lesson answer to browser frameworks, from the browser-use team themselves: no helpers — the agent writes raw CDP calls, with types as the docs. Brilliant for capable models on weird pages; frustrating for weak models that need click() rails — that's what browser-use itself is for.
browser-use — the curator's take
When the task lives behind login walls, forms and JavaScript — 'book this', 'apply to that', 'put these in my cart' — this is the default tool: it feeds the agent a cleaned DOM, executes its clicks/typing, and recovers from the endless weirdness of real websites. Install-as-skill support means Claude Code/Cursor agents pick it up in one prompt. NOT for bulk data extraction — an LLM driving a browser is the slowest, most expensive way to scrape a thousand pages (use a crawler); and treat any agent-with-a-browser as having the keys to whatever it's logged into — sandbox accordingly.