[ COMPARISON ]

Stealthly vs agent browsers: one shared backend instead of one browser per session

There are a lot of ways to give an agent a browser, and they differ less in what the agent can do than in what one session costs. This page compares on that axis, with this project's own measurements stated with their conditions, and every statement about another tool taken from that tool's own documentation and re-checked on 2026-09-12.

[ THE PROBLEM ]

One browser per session is fine until it is not

The usual MCP browser server runs one server process and one Chrome per client session. That is fine for one session and ruinous for fifty: every session pays for a whole browser before it has done anything. If you have a single agent doing a single job, the difference is invisible and you should ignore this page. If you keep a lot of agent sessions open — the way people actually use coding agents, with several projects and several terminals live at once — it is the dominant cost.

Stealthly is shaped differently. A session runs only a thin stdio proxy. The browsers live in one shared backend per desktop, and a Chrome exists only where a session asked for one. An idle session holds a proxy, not a browser.

[ MEASURED ]

62 sessions on one Windows 11 workstation

These are the project's own figures, measured on a Windows 11 workstation on 2026-09-11 with 62 agent sessions attached at once. They are reproduced here with their conditions because a benchmark without its conditions is a slogan.

Measured
Agent sessions attached to the shared backends62
Resident memory per session (its stdio proxy process tree)about 60 MB, about 3.7 GB across all 62
The same 62 sessions if each ran its own Chrome (about 750 MB per browser)about 46 GB
Backends on the machine3 — one per desktop context, plus headless
Live Chrome instances5 — only the ones sessions had spawned
Cold start: 50 sessions at once, every one usable (initialize + tools/list)7.3 s (tests/test_startup_herd.py)
A 51st session joining the warm backend1.0 s
The caveat the project states about its own numbers, reproduced because leaving it out would be the dishonest version: the per-session and per-browser figures are the ones to plan capacity around. The backend's own footprint depends on what the sessions do with it — captured network bodies, stored element clones, live tabs — so it is deliberately not quoted as a constant.
[ CONSEQUENCES ]

What the shape buys a fleet

  • Memory scales with the browsers you use, not the sessions you open. Sixty sessions with five browsers between them pay for five browsers and sixty proxies.
  • One cold start per backend. The first session boots the backend under a file lock; every other session converges on it and is usable in seconds. A session arriving later joins in about a second.
  • Nothing is left behind. Orphaned Chrome processes are reaped without killing live ones — each tracked browser records which backend started it, so two backends running side by side never reap each other's — and a spawn that fails after Chrome launched cleans up its own browser.
  • Startup is not a package-resolution storm. With a pinned executable, fifty sessions starting together do not re-resolve the package fifty times. The install page explains why that rules out uvx in a client config.
[ THE OTHER AXIS ]

Stealth, which is a separate question

Concurrency and detection are independent properties and it is worth not conflating them. On the detection axis, Stealthly's position is: it drives the real Chrome, Chromium or Edge already installed on the machine, strips the launch flags that mark a session as automated before the browser starts, and starts from a profile carrying real cookies and logins rather than a blank one. The published challenge demos are Cloudflare's and Turnstile's. How bot detection works covers the mechanics.

[ THE OTHERS ]

What each alternative says about itself, checked 2026-09-12

Each row below is what that project's own documentation states, read on 2026-09-12. Nothing here is an inference about a competitor's behaviour, nothing is from memory, and where a claim could not be verified on the day it was left out rather than hedged. These projects change; re-read their docs before making a decision on this table alone.

ToolWhat its own docs sayWhere it sits
BrowserbaseA hosted platform: one API key gives an agent cloud browsers, search, fetch and model access. CAPTCHA solving is enabled by default on all sessions, can take up to 30 seconds depending on challenge type, improves with proxies, and is turned off with solveCaptchas: false. Sessions are driven with Playwright, Puppeteer or Selenium.Cloud execution, billed per usage. You do not run the browser.
browser-useAn MIT-licensed Python library (Python 3.11+) that runs an agent loop against a local or cloud browser, offered as a hosted cloud, a CLI and a library. Its README states that stealth browsers and proxies designed to reduce bot detection and CAPTCHA challenges are a Browser Use Cloud feature, enabled from the library with Browser(use_cloud=True).An agent framework. The stealth story is attached to their cloud.
LightpandaA headless browser written from scratch in Zig — explicitly not a Chromium fork and not a WebKit patch. Its published benchmark (933 real pages on an AWS EC2 m5.large) reports 123 MB peak memory over 100 pages against 2 GB for headless Chrome, and 5 s against 46 s. It exposes a CDP server and WebDriver BiDi, so Puppeteer can drive it. Its README makes no anti-detection claim.A different engine, optimised for crawl throughput.
PlaywrightAn end-to-end test framework that bundles a runner, assertions, isolation and parallelisation, supporting Chromium, WebKit and Firefox on Windows, Linux and macOS, headless or headed, and downloading its own browser binaries.A test framework you write scripts in, not a server an agent calls.
PuppeteerA JavaScript library with a high-level API controlling Chrome or Firefox over the DevTools Protocol or WebDriver BiDi, headless by default, downloading a compatible Chrome on install.A driver library. Same layer as Playwright, narrower browser set.
Stealthly (stealth-chrome-devtools-mcp)A Python MCP server, AGPL-3.0, driving the Chrome, Chromium or Edge already installed. One shared backend per desktop; the measured table above. Install with uv tool install stealth-chrome-devtools-mcp==2.1.14.A server your agent calls, running on your machine.
[ HONESTY ]

When one of the others is the better fit

A comparison that concludes with itself winning every row is not a comparison. Several of these are better answers than Stealthly to questions people genuinely have.

  • You want someone else to run the browsers. Stealthly runs on your machine and expects a real Chrome installed on it. If you want browsers as a hosted service with no local footprint, a cloud platform is the category you want, not this one.
  • You need a non-Chromium target. This drives Chrome, Chromium and Edge. Firefox and WebKit coverage is a reason to reach for Playwright.
  • You are writing a test suite, not driving an agent. An MCP tool surface is the right shape when a model is choosing the calls. When your code is choosing the calls, a driver library is simpler and you do not need a protocol in between.
  • You are crawling at volume and do not need to look like a desktop user. A purpose-built lightweight engine will beat a real Chrome on pages per second and memory, because it is not carrying a real Chrome.
  • Your stack is not Python. This ships as a Python package. That is irrelevant if you only ever talk to it over MCP, and decisive if you want to embed it.