Vercel agent-browser: CLI browser automation for AI agents

Vercel's agent-browser is a browser automation CLI for agents that can run shell commands. Its snapshot -i command returns interactive elements with refs such as @e1, which the agent can use in a later click command.

This command-and-text workflow gives agents compact page context without requiring an MCP server connection. The choice depends on your client and task; compare token use and completion time on your own workflow before treating a published benchmark as a general performance guarantee.

The Context Window Tax

Browser automation via MCP spends tokens before any work starts. According to community benchmarks, when Playwright MCP starts a session, it loads an estimated ~13,700 tokens of tool definitions into the agent's context window before a single page is visited. Chrome DevTools MCP is reportedly higher at ~17,000 tokens, which is roughly 9% of a 200K context window.

Each action has a cost as well. In a test by Engin Diri at Pulumi, one Playwright MCP click response was 12,891 characters long. The same click through agent-browser returned six characters: Done. Page complexity changes the numbers, but the difference stays large.

Over a longer workflow the difference grows. Third-party benchmarks have estimated the token cost of a 10-step automation flow across three tools:

In this estimate, agent-browser uses 94% fewer tokens than Playwright MCP for the same 10-step flow. That leaves much more of the context window for the task itself.

How agent-browser Works

agent-browser has two layers. A Rust CLI handles argument parsing in sub-millisecond time. Behind it runs a native Rust daemon that communicates with Chrome directly via CDP (Chrome DevTools Protocol), no Node.js or Playwright required. The daemon stays warm between commands via Unix domain sockets, so each command avoids a browser startup. You can also swap Chrome for Lightpanda, a Zig-based headless browser that claims roughly 10x faster performance and 10x less memory in its own benchmarks.

The first command in a session takes about 500ms to start the daemon and launch the browser. After that, each command completes in sub-100ms. In Playwright MCP, every action involves a full JSON-RPC round-trip with tool schemas, parameters, and verbose response objects.

Snapshots and Refs: How agent-browser Addresses Elements

The core of agent-browser is its snapshot + refs system. Instead of CSS selectors, XPath, or full DOM dumps, agent-browser captures the page's accessibility tree , filters it to interactive elements, and assigns each one a stable reference.

button "Sign In" [ref=e1]
textbox "Email" [ref=e2]
textbox "Password" [ref=e3]
link "Forgot password?" [ref=e4]
link "Create account" [ref=e5]

This snapshot has five elements and five refs. The agent runs agent-browser click @e1 to click Sign In, or runs agent-browser fill @e2 "user@example.com" to type an email address. It needs no CSS selectors, pixel coordinates or vision model to parse a screenshot. Refs resolve by matching accessibility role and name via CDP's Accessibility API, conceptually the same approach as Playwright's getByRole .

For comparison, Playwright MCP returns this for a similar page:

- heading "Welcome back" [level=2]
  - paragraph: "Sign in to your account"
- form:
  - textbox "Email" [required] (ref=s1e4)
  - textbox "Password" [required] (ref=s1e5)
  - button "Sign in" (ref=s1e6)
- navigation:
  - link "Forgot password?" (ref=s1e7)
  - link "Create account" (ref=s1e8)
  - link "Terms of Service" (ref=s1e9)
  - link "Privacy Policy" (ref=s1e10)
  ... (continues for entire page)

Playwright MCP returns the full accessibility tree, including every heading, paragraph, landmark, and decoration on the page. The -i flag of agent-browser (interactive only) keeps just the elements you can click, type into, or toggle. In Engin Diri's testing, a homepage snapshot was ~280 characters with agent-browser versus ~8,247 with Playwright MCP. Numbers vary with page complexity.

The Accessibility Tree, Again

Our earlier piece on how AI agents see your website covers the basics. The accessibility tree is a browser-generated structured view of your page: roles, names, states, descriptions. For agent-browser, the accessibility tree is the interaction interface used to create refs. Other browser agents may combine the DOM, accessibility tree, and screenshots.

In agent-browser, the snapshot command is an accessibility tree query. When an agent calls agent-browser snapshot -i, it gets the same tree that screen readers consume and that Playwright tests query with getByRole . The output format differs, with compact text instead of YAML.

For website owners the advice stays the same. If your button is a <div onclick> instead of a <button>, it won't appear in the snapshot. If your form fields lack labels, the agent sees textbox "" and has no label that says what to type. If your navigation is built with unsemantic divs, the snapshot has no links for the agent to use. These are the same rules as before, now with a tool that has 22,000+ GitHub stars.

The annotated screenshot feature shows the same refs visually. Running agent-browser screenshot --annotate overlays numbered labels on every interactive element, and each label maps to a ref. This works as a visual debugger for the accessibility tree. A multimodal model can reason about layout and still use the same refs for interaction.

Less Is More: What Vercel's D0 Data Shows

The design of agent-browser resembles findings from Vercel's own D0 text-to-SQL agent research. Both projects come from Vercel and follow the same idea: give the agent fewer tools. In D0, Vercel tested two architectures: one with 17 specialized tools and one with 2 general-purpose tools.

The 17-tool version had an 80% success rate, took 274.8 seconds, and used ~102,000 tokens. The 2-tool version had a 100% success rate, took 77.4 seconds, and used ~61,000 tokens. All three metrics improved with fewer tools.

As Vercel's D0 team put it: "We were constraining reasoning because we didn't trust the model to reason." With 17 specific tools, the agent had to pick the "right" one at each step. With 2 flexible tools, it worked out the approach itself. agent-browser applies a similar idea to the browser by keeping its output small.

This matches what Andrej Karpathy argued about CLIs being the ideal agent interface . A CLI uses flags, stdin, and stdout, with no tool schema negotiation and no capability discovery. The agent runs a command and reads the output. agent-browser applies this to the browser with 50+ commands, each aimed at one action and returning little output.

What This Means for Your Website

agent-browser documents integrations with Claude Code, Cursor, GitHub Copilot, OpenAI Codex, Google Gemini, and other agents that can run shell commands. It can be installed with npm install -g agent-browser without MCP configuration. Those compatibility options do not measure how many workflows use it or whether browsing succeeds.

The same patterns that make your site work with Playwright MCP apply here: semantic HTML, proper form labels, accessible names on buttons and links, and a clean heading hierarchy. The feedback loop is short with agent-browser. When an agent runs snapshot -i on your homepage and gets two refs instead of twelve, you can see where the problem is.

Our scanner measures related published signals. Checkpoints in the Content & Semantics category cover semantic HTML, heading hierarchy, alt text, ARIA usage, form labels, and descriptive links. These overlap with inputs used to build accessibility-tree snapshots, but the static checks do not run agent-browser or predict whether it can navigate the site. SSR detection is a separate signal for whether fetch-only crawlers and non-rendered retrieval can access meaningful initial HTML.

agent-browser ships with an AGENTS.md file and a skills/ directory that AI coding agents read to learn its command set. It also supports multi-session isolation with separate sockets, cookies, and ref caches per session, so agents can operate in parallel without interfering with each other. With multiple releases per day and hundreds of open issues, the project changes quickly.

Sources

• vercel-labs/agent-browser on GitHub (22,000+ stars, Apache-2.0, Rust CLI for AI browser automation)
• agent-browser.dev: Official Documentation (commands, architecture, and engine support for Chrome and Lightpanda)
• Why agent-browser Is Winning the Token Efficiency War (DEV Community) (benchmark comparison of 10-step flow token consumption across tools)
• Self-Verifying AI Agents: agent-browser in Practice (Pulumi) (token comparison: 12,891 chars for Playwright MCP vs 6 chars for agent-browser per click)
• DeepWiki: agent-browser Architecture Analysis (native Rust daemon, snapshot + refs system, ref resolution via CDP)
• We Removed 80% of Our Agent's Tools (Vercel) (D0 research: 17 tools with 80% success vs 2 tools with 100% success)
• IsAgentReady: How AI Agents See Your Website (The Accessibility Tree Explained)
• IsAgentReady: Playwright: From Test Runner to AI Agent Interface
• IsAgentReady: Build for Agents: Why CLIs Are the New Distribution Channel