vs agent-browser
Different products that look alike. Measured, with respect — and a clear rule for which to pick.
agent-browser is Vercel Labs' browser-automation CLI for agents. It's good — fast, token-efficient, and its snapshot/ref loop set the bar (Chrome Relay's own loop ergonomics owe it a debt, openly). If you're choosing tooling, here's the honest comparison.
The one-line difference
agent-browser gives your agent a browser. Chrome Relay gives your agent yours.
agent-browser downloads its own Chrome for Testing and drives it headless behind a daemon — a fresh, disposable sandbox. Chrome Relay attaches to the Chrome you're already using, with everything that implies: your logins, your extensions, your localhost, and a human sharing the browser.
| agent-browser | Chrome Relay | |
|---|---|---|
| Browser | its own Chrome for Testing, headless by default | the one you have open |
| Auth state | none (profile copy is a read-only snapshot) | everything you're signed into |
| Anti-bot (Cloudflare etc.) | fingerprinted as automation, often blocked | indistinguishable from you |
| Parallel isolated sessions | yes — its core strength | one browser; isolation via workspaces |
| CI / headless servers | yes | no — needs a running desktop Chrome |
| Human + agent simultaneously | n/a — the agent owns the browser | yes — background tabs, no focus stealing |
| Attach to a real Chrome | via --cdp debug port (requires relaunching Chrome; port exposes everything to localhost) |
native: extension + native messaging, no relaunch, Chrome-gated |
We tested both on the same machine, same minute, same URL: agent-browser's Chrome saw logged-out Hacker News; Chrome Relay saw a logged-in session. Every page behind auth only exists in one of those worlds.
The ergonomics are now comparable
The historical knock on real-browser bridges was clunky loops. Measured today, same page (HN front page):
| agent-browser | Chrome Relay | |
|---|---|---|
| Interactive snapshot | 13.5 KB | 14.3 KB |
| Act on an element | click @e12 |
click @e12 |
| Click round-trip | ~40 ms | ~150 ms |
The remaining latency gap is Node process startup vs a Rust binary — real, and irrelevant next to LLM turn time. Two places Chrome Relay's loop goes further:
- Refs heal. agent-browser's refs go stale on any DOM change, and its docs tell agents to re-snapshot constantly — a real-world migration measured ~30% of turns burned on re-snapshots. Chrome Relay refs survive same-page churn via a role/name re-find that writes the fix back; they die only on real navigation, loudly.
- Refs are tab-safe under a human. In a browser only the agent uses, "active tab" is unambiguous. In your browser it's whatever you're reading — so Chrome Relay refs carry their tab, and a bare
click @e12can never land in your inbox.
agent-browser counters with breadth Chrome Relay doesn't have: built-in wait primitives, snapshot diffs, batch execution, video, traces, proxies, cloud-provider backends. If you need those today, that's a real reason to pick it.
The rule
- E2E tests, CI, scraping, parallel fleets, no auth needed → agent-browser (or Playwright). The sandbox is the feature.
- Operating apps you're signed into, debugging your own logged-in product, anything behind SSO or Cloudflare, working alongside the agent → Chrome Relay. The real browser is the feature.
They compose, too: plenty of workflows scrape with a sandbox and act with the real browser. Nothing about installing one precludes the other.