browser-harness-js vs pinchtab
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 — Small Go HTTP/MCP server that gives AI agents direct control over Chrome — stealth CDP injection, multi-instance orchestration and a real-time dashboard. Local-first, single binary.
Both are thin bridges surfacing raw CDP to LLM agents; browser-harness-js is a JS/WebSocket library, PinchTab is a standalone Go HTTP server with stealth and instance orchestration.
| browser-harness-js | pinchtab | |
|---|---|---|
| Stars | 473 | 9.5k |
| Forks | 33 | 705 |
| Language | TypeScript | Go |
| License | MIT | MIT |
| Last activity | 3 months ago | today |
| Topics | web | web, agents |
| Curated connections | 4 | 5 |
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.
pinchtab — the curator's take
Reach for it when you want one language-agnostic browser control plane that many agents (or non-JS stacks) share over HTTP/MCP, with stealth and several Chrome instances managed as a background daemon. Skip it if you just need an in-process Python/JS browser tool for a single agent — browser-use or browser-harness-js are lighter. The dashboard/API is a privileged operator surface: local-first by design, never expose it publicly without locking down tokens, TLS and endpoint families.