nanobrowser vs pinchtab
Chrome extension running a Planner/Navigator multi-agent loop inside the browser you already use, with your own API keys — a free, local alternative to OpenAI Operator. — 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.
pinchtab controls Chrome from outside as an MCP server your own agent calls; nanobrowser is the agent, living in the side panel. Pick by whether the reasoning loop should be yours or theirs.
| nanobrowser | pinchtab | |
|---|---|---|
| Stars | 14k | 10k |
| Forks | 1.4k | 768 |
| Language | TypeScript | Go |
| License | Apache-2.0 | MIT |
| Last activity | 6 days ago | 2 days ago |
| Topics | web, agents | web, agents |
| Curated connections | 4 | 6 |
nanobrowser — the curator's take
The lowest-friction way to get an agent driving a real, already-logged-in browser: install from the Web Store, paste keys, assign a cheap model to the Navigator and a strong one to the Planner, watch it self-correct in the side panel. Everything stays in the tab, which is exactly the tradeoff — great for privacy and for sites that demand your session, useless for headless runs, CI or fleets, and Chrome/Edge only. You are the sandbox: it can act inside every account that browser is signed into, so supervise it rather than leaving it unattended. Server-side or scripted automation belongs in a library or a CDP server instead.
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.