The short answer, before anything else: agent-browser and Chrome DevTools MCP are two different jobs (public-data speed, live-session debugging), and ego (lite) is what their strengths combine into for daily work: agent-browser's isolated programmatic control plus the real signed-in sessions auto-connect reaches for, without the shared window.
ego (lite)'s part of that split, stated up front: agents like Claude Code and Codex work in isolated Spaces that inherit your logged-in state, so tasks run without taking your window. On Real-World Bench, a 31-task suite against live sites run with the same model and the same judge, it finished 30 of 31 tasks perfectly (96.8%), against 23 of 31 (74.2%) for agent-browser and 19 of 31 (61.3%) for chrome-devtools-cli, the closest measured stand-in for DevTools MCP. The full head-to-head, with costs, is below.
If you've researched agent browsing past the first blog post, you've met these three: Vercel's agent-browser, Google's Chrome DevTools MCP, and ego (lite). They get lumped together constantly. Two are different bets about what an agent needs; the third is what those bets combine into once the costs are engineered away.
Full disclosure before the comparison: we build ego (lite). Every claim below about all three tools is sourced from their official docs or published benchmarks, and ego (lite)'s shortcomings are listed with the same bluntness as everyone else's.
What are the three architectures?
agent-browser: CLI in front, disposable browser behind.
A native Rust CLI (with a Rust daemon speaking raw CDP) that downloads Chrome for Testing and exposes a snapshot-plus-refs loop: agent-browser snapshot returns an accessibility tree with refs like @e1, then agent-browser click @e2 acts on them.
Sessions are deliberately isolated, each with its own cookies and auth state; it also connects outward to CDP endpoints and cloud browser farms like Browserbase and Browserless. The design goal is fast, deterministic automation on browsers that exist for the task and vanish after.
Chrome DevTools MCP: agent attached to your Chrome.
An MCP server wrapping the DevTools protocol's diagnostic surface: performance traces with Core Web Vitals, V8 heap snapshots, network inspection across navigations, device emulation. With auto-connect on Chrome 144+, it operates inside the browser you're signed into, after a permission dialog. The design goal is letting an agent see what you see, including everything behind your logins, in your window.
ego (lite): a browser built for sharing.
A free desktop browser built for sharing your logged-in browser state with AI agents, like Codex or Claude Code.
Under the hood, the ego-browser skill drives it over CDP, the same protocol agent-browser's daemon speaks, pointed at a browser built to be driven. The agent-facing surface is a CLI: any agent that can run a shell command writes JavaScript that executes as whole workflows outside the model's context, in a Space that inherits your signed-in sessions without touching the window you're using.
Two bets, and the combination they point to.
You can hear the difference in what a task looks like. agent-browser: snapshot, click @e2, fill @e3, one command per action. DevTools MCP: "start a performance trace and tell me what's delaying LCP." ego (lite): a ten-line script piped in once, and the agent reads back only the result.
That difference, run for real: the session below was executed on 2026-08-15 against GitHub Trending, and the target is not a staged demo page. Pulling the week's top trending Python repo is literally one of the 31 benchmark tasks scored below (rwb-github-trending-py-01).
ego (lite), targeted extraction
ego-browser nodejs <<'EOF'
const task = await egoBrowser.newTaskSpace('article demo evidence 0820')
console.log({ taskSpaceId: task.id })
await task.page.goto('https://github.com/trending/python?since=weekly', { waitUntil: 'load', timeout: 30000 })
const repo = await task.page.locator('article.Box-row h2 a').first().innerText()
const stars = await task.page.locator('article.Box-row .float-sm-right').first().innerText().catch(() => null)
console.log(JSON.stringify({ url: task.page.url(), topRepo: repo.replace(/\s+/g, ' ').trim(), starsThisWeek: (stars || '').trim() }))
EOF
# output:
{ "taskSpaceId": 10 }
{"url":"https://github.com/trending/python?since=weekly","topRepo":"cactus-compute / needle","starsThisWeek":"3,772 stars this week"}One JSON object, roughly 130 characters, returned from a single execution round. For the other side of the contrast: a take_snapshot we measured on Hacker News via Chrome DevTools MCP returned 38,285 characters of accessibility tree for one page, the per-action observation cost of the snapshot-based design. That gap in what flows back to the model is the shape of the difference this section is describing.
How do they compare, dimension by dimension?
Five dimensions decide real usage. Every cell states the limit as well as the strength, because the limits are where decisions happen.
| Dimension | agent-browser | Chrome DevTools MCP | ego (lite) |
|---|---|---|---|
| Login state | Isolated sessions by design; your accounts aren't there unless you script them in | Full access via auto-connect, inside your own window | Inherited: every site you've signed into stays signed in for the agent |
| Window ownership | Its own browser; yours untouched | Shares the window you're using; turn-taking required | Its own Space; your window stays yours, tasks run in parallel |
| Real-World Bench, 31 tasks | 74.2% perfect (23 of 31); $2.76 avg cost, $3.72 per completed task | 61.3% perfect (19 of 31), measured as chrome-devtools-cli, not the MCP server; $4.95 avg, $8.08 per completed task | 96.8% perfect (30 of 31); $1.92 avg, $1.98 per completed task |
| Debugging | Console, network interception, Web Vitals; no full trace analysis | The category's best: traces, heap snapshots, emulation | No debugging panel; not this tool's job |
| Price and license | Free, Apache-2.0 | Free, open source | Free; closed source |
How do the three score on the same 31 tasks?
Real-World Bench runs 31 tasks against live production sites (X, Expedia, Redfin, Amazon, government data portals) plus deterministic local sites for stateful flows, with the same model, gpt-5.6-sol at max effort, driving all five tools and the same independent judge grading every run from raw session logs and screenshots. Each task carries up to 6 binary rubrics (154 across the 31 tasks); a task counts as perfect only when every rubric passes, with no partial credit. Each tool's score is its better of two complete 31-task runs, kept whole, no per-task cherry-picking.
One naming note before the numbers: the harness measured chrome-devtools-cli, the CLI route to the same DevTools protocol surface, not the DevTools MCP server this article discusses. Same diagnostic toolkit, different transport; read its row as the closest measured proxy, not the MCP server's own score.
Real-World Bench perfect-completion rate (31 tasks)
Perfect = every binary rubric passes; best of two complete runs per tool, run 2026-08-19
The tasks are not toy fetches. Examples from the set: pull a week of engagement metrics from x.com/OpenAI behind a login, excluding pinned posts and replies; work out a monthly payment estimate for a used Camry on cars.com; play 2048 to the 256 tile without a reset. Rubric scoring on that mix is where the completion gap opens.
Completion rate sets the real bill, because average cost per task counts the failed attempts too. agent-browser averaged $2.76 per task; divide by its 74.2% completion and each completed task cost $3.72. chrome-devtools-cli averaged $4.95, which at 61.3% completion is $8.08 per completed task. ego (lite) averaged $1.92: $1.92 divided by 96.8% completion is $1.98 per completed task.
The turn counts explain the gap better than any engine detail. agent-browser needed 45.6 model turns per task and chrome-devtools-cli 44.9, against ego (lite)'s 30.3: one command per model round trip means many round trips, and every round trip is another chance to misread a snapshot or derail. On rubric average, which credits partial completion, ego (lite) scored 99.3%; chrome-devtools-cli's 82.6% edges agent-browser's 80.6% there, meaning it partially completed more of the tasks it failed. And with the fewest round trips, ego (lite) was also the fastest of the five tools measured, at 518 seconds per task on average against 587 to 693 for the rest.
Where does each one break?
Every tool's failure modes live where its design bet stops paying. In a January 2026 YouTube comparison, developer Cole Medin measured first-try task completion at 95% for agent-browser, 80% for Playwright MCP, and 75% for Chrome DevTools MCP. Note his lineup: two of this article's three tools plus Playwright MCP, not ego (lite). The gap traces to mechanism: agent-browser condenses the site into stable refs the agent clicks directly, while MCP-based tools rely on accessibility-tree searches that can fail when the element isn't found. Real-World Bench's harder 31-task set keeps the same relative ordering (agent-browser 23 of 31 perfect vs the DevTools CLI route's 19 of 31) at much lower absolute rates, which is what multi-rubric, live-site tasks do to first-try numbers. Specifics from public issue trackers and docs:
agent-browser: the login wall. Sessions are isolated on purpose, and users who tried to carry auth state anyway hit real friction: the GitHub tracker has reports of --profile sessions losing the active page and falling back to about:blank, and cross-origin iframes documented as a blocker, which takes out embedded logins like Apple ID and Google SSO flows.
There's also the setup tax of downloading Chrome for Testing before first use. None of this matters for stateless scraping; all of it matters the day your task needs an account.
Chrome DevTools MCP: the shared window. Auto-connect needs Chrome 144+, remote debugging enabled, and a per-session permission dialog, and what you get is an agent operating in the browser you're trying to use. Chrome 136+ also blocks the debug flag on default profiles, so the older port-based route needs a dedicated profile. Excellent trade for debugging sessions; wrong shape for tasks that should run while you work.
ego (lite): the jobs it doesn't do. No performance traces, heap snapshots, or Lighthouse, so diagnosis stays with DevTools MCP. It's a desktop browser, so headless CI containers are out of scope, and assertion-heavy test suites belong to Playwright. And it's closed source, which matters to some teams as policy regardless of features.
Which should you pick for your task?
Three questions sort nearly every case. Answer them in order and stop at the first match.
Is the data public and the work stateless? agent-browser. Scraping docs sites, checking prices, batch screenshots: its native-Rust speed and disposable sessions are exactly right, and login state would be dead weight.
Is the task diagnosing a page? Chrome DevTools MCP. Slow LCP, memory creep, a bug that only reproduces in your logged-in session: nothing else in this trio holds those tools.
Is it daily work behind your logins that shouldn't interrupt you? ego (lite). Dashboard pulls, form filling, list collection on sites where you have accounts, running in parallel Spaces while your own window stays yours. That's the bet it was built on, and it's free.
Plenty of setups keep two of the three: agent-browser or ego (lite) for execution depending on whether logins matter, DevTools MCP enabled for the day something needs a trace. The pairing that rarely makes sense is agent-browser plus ego (lite) for the same task: ego (lite) already keeps agent-browser's script-control model and adds the logins it excludes by design, so the login question answers it in one move.
See the full ego (lite) vs agent-browser comparison, or download ego (lite) for Mac and run one logged-in task next to your current setup.
FAQ
Is agent-browser the same as Browser Use?
No. agent-browser is Vercel Labs' CLI tool: your agent decides each step and the CLI executes it. Browser Use is an autonomous framework running its own LLM loop. Different layer of the stack entirely.
Can agent-browser use my logged-in Chrome?
It can attach to CDP endpoints (agent-browser --cdp 9222), which reaches a Chrome you've opened with a debug port, with the same caveats that route always has: Chrome 136+ profile restrictions, port security, and the agent acting in that browser's real tabs. Its own sessions stay isolated by design.
Why is ego (lite) faster than agent-browser on complex tasks?
Execution model, not engine speed. agent-browser runs one command per model round trip; ego (lite)'s agents write the whole workflow as one JavaScript program that runs to completion in the browser runtime, so a 20-step task is one round trip instead of 20. On Real-World Bench that shows up as 30.3 model turns per task for ego (lite) against agent-browser's 45.6. The separate heredoc-vs-REPL measurement quantifies the same mechanism in isolation: 44% fewer execution rounds, 35.5% fewer tool calls, and 21.6% lower cost versus command-at-a-time execution.
How were the Real-World Bench numbers measured?
31 tasks against live production sites, five tools, same model (gpt-5.6-sol at max effort). Execution and judging are separate stages: an independent judge agent with read-only tools grades each run from the raw session logs, real tool results, and screenshots, and a negative verdict never triggers a re-run. Each task carries up to 6 binary rubrics (154 across the 31 tasks); perfect means every rubric passed. Each tool's score is its better of two complete 31-task runs, kept whole. Results for the three tools here: ego (lite) 30 of 31 perfect (96.8%), agent-browser 23 of 31 (74.2%), and chrome-devtools-cli, measured in place of the DevTools MCP server, 19 of 31 (61.3%). The harness, tasks, and raw verdicts are public in the citrolabs/ego-browser-benchmark-framework repo.
Do all three work with Claude Code, Cursor, and Codex?
Yes, by different mechanisms: agent-browser installs as a CLI any shell-capable agent runs (plus an optional MCP mode), DevTools MCP registers through each client's MCP config, and ego (lite) installs the /ego-browser skill into your agent during onboarding, after which you just tell the agent what you want.
Are all three actually free?
Yes: agent-browser and Chrome DevTools MCP are free open source (Apache-2.0 and Google's project respectively), and ego (lite) is free to download and use, closed source. Your only running cost in all three cases is your agent's model usage.
