Last week Vercel shipped agent-browser — a browser-automation CLI built for AI agents, rewritten in Rust, now sitting at nearly 39,000 GitHub stars. It's fast, it's polished, and it makes exactly the architectural bet we made when we built the browser Rush agents drive: talk to Chrome over the DevTools Protocol, hand the model an accessibility-tree snapshot with stable refs, and never make it guess pixel coordinates.
We build the other one. So we did the obvious thing: installed agent-browser 0.32.3, pointed both tools at the same page, and measured. Not spec sheets — the same ten-command loop through each, timed, on a byte-identical page.
It was a split. And the way it split is the whole point.
Two numbers decide a browser agent
Every turn a browser agent takes, it does the same small loop: read the page into something the model can reason about, let the model decide, send the click back. The cost of that loop shows up as two different numbers, and they are not the same number.
The first is latency — the wall-clock milliseconds between "look at the page" and "here's what's on it." It's the number you feel. A slow loop feels slow.
The second is tokens — how much text the page snapshot turns into before it goes into the model's context window. It's the number you don't see, because it's not on your stopwatch. It's on your bill, and in your context limit, on every single turn.
agent-browser optimized the first. We optimized the second. Here's what that looks like in numbers.
The head-to-head
Same page both times: a small dashboard with a form and a 40-row table — 57 interactive controls, served locally so the network is out of the equation and both tools see identical bytes. Warm snapshot, median of nine runs, clean machine.
agent-browser is ~5.8× faster per snapshot. Our snapshot is ~5.8× smaller — 1.5 KB of text against their 8.9 KB, ~390 tokens against ~2,200. The same factor, on opposite axes. Nobody is fudging here; both numbers are real, reproducible, and measured against Vercel's current release.
Neither of these is an accident. They fall directly out of two different design choices.
Why they're fast
agent-browser is a native Rust binary. It cold-starts in about 24 milliseconds and speaks to its own persistent daemon over a Unix socket. Ours is a CLI on a TypeScript runtime; before it does a single millisecond of browser work, it spends ~128ms just booting. That's most of the gap, and it's an honest one — if your agent shells out a command per action and your bottleneck is wall-clock, that overhead is real, and you should know it before you pick a tool.
Their snapshot is also richer. When agent-browser reads that 40-row table, it hands the model the table — every row, every cell, the structure that tells you which "Assign" button belongs to which ticket. That's 268 nodes of context. It costs tokens, and in exchange the model can see where it is.
Why we're lean
Ours returns a flat list of the 57 things you can actually click, type into, or select — and nothing else. No cells, no structural scaffolding, no headings the model won't act on. 57 nodes instead of 268. The model gets handles, not a document.
That's the bet: for an agent, the snapshot is not a page to read, it's a set of things to do. Strip it to the actionable surface and the token cost of looking collapses.
Latency is paid once per action. Tokens are paid on every action, at every model call, for the entire length of the session — and they don't just cost money, they eat the context window the agent has to think in.
This is why we think tokens are the number that compounds. A 300-millisecond snapshot is annoying once. A 2,000-token snapshot is 2,000 tokens every turn — ten turns into a task it's 20,000 tokens of the model's finite attention spent describing table cells it never touched. On a long task, the lean loop isn't a little cheaper. It's the difference between fitting in the window and falling out of it.
And here's the part we'll say out loud, because it's the sharpest version of the point: the reason everyone knows agent-browser is efficient is Vercel's own headline — "94% fewer tokens than Playwright MCP." They're right that tokens are the metric that matters for agents. We agree so completely that, measured head-to-head on the same page, our snapshot is 5.8× leaner than theirs. We took the metric they chose and pushed it further.
Credit where it's due
agent-browser is a genuinely good piece of engineering, and in ways that have nothing to do with this benchmark. It's public, Apache-licensed, a brew install away, with a live-streaming dashboard, React DevTools introspection, and a first-class cloud-provider menu. It is the polished, open version of this idea, and if raw per-action latency is your constraint, its Rust core will beat us today — we're closing the runtime-boot half of that gap, but we're not going to pretend the number isn't there.
What ours is built for is different. It lives inside the agent OS Rush agents run in — same accessibility-ref targeting, same warm daemon, but tuned so that the thing an agent does thousands of times a day, look at the page, costs as close to nothing as we can make it.
Two ways to make a browser agent fast, then. Shrink the milliseconds, or shrink the tokens. agent-browser bet on the number you feel. We bet on the number you pay. The best browser agent will eventually do both — and the honest state of things today is that each of us has one half, and we can each see the other half from here.
We wrote up the token half of our own work — how a repeat snapshot went from 632ms to 3ms — in The Other Way to Speed Up a Browser Agent. This is the comparison that post was missing: not against our old selves, but against the fastest browser in the game.
Rush is the agent OS where those agents run. The browser they drive is built in — and it reads a page in about 390 tokens.
