Browser automation APIs compared (2026) Pricing Compared

A browser-hour at ten cents sounds like nothing. A single agent session that idles while an LLM thinks can burn twenty minutes of wall clock to do ninety seconds of work, so the real unit is not the hour, it is the hour times your model latency. Teams routinely find that the browser costs less than the tokens and more than they budgeted, at the same time.

The bigger surprise is traffic. Every agent-oriented provider prices residential proxy bandwidth separately, usually in the same range Bright Data charges directly, because most of them resell the same pools. A scraping workload that pulls images and fonts can move a gigabyte in an afternoon. Once you are paying for proxy gigabytes anyway, the honest comparison is not "Browserbase versus Bright Data", it is "Browserbase plus proxy gigabytes versus Bright Data all-in", and that comparison is much closer than the sticker prices suggest.

Watch for the concurrency cliff too. Several vendors gate concurrency by plan tier, so the constraint that forces an upgrade is not usage but parallelism — three sessions on the entry plan is fine for development and useless for a crawl. Check the concurrency number before the hourly rate.

Bot detection vendors ship changes weekly. A provider that passes Kasada in March can fail it in April because a signal moved, and neither party will announce it. This is why the success-rate figures on vendor sites — "99% success rate", "unblockable" — are unfalsifiable: no date, no target list, no sample size, no definition of success.

It also means a single number is the wrong shape for the truth. Pass rates vary by detection vendor, by target site's configuration of that vendor, by geography, and by whether the session is cold or reusing cookies. A provider can be excellent against Cloudflare and hopeless against DataDome. Our panel reports per-site rates alongside the headline so you can weight the row that matches your target.

Practical advice while the column is empty: shortlist on capability, then run your own two-week bake-off against your actual targets, log every failure with the challenge type, and re-run it quarterly. Nobody's benchmark, ours included, substitutes for testing against the specific site paying your bills.

Start with the target. If it is a site you control, an internal tool, or a documentation crawl, use Cloudflare Browser Rendering or self-hosted Playwright and stop reading — you are buying screenshots and PDFs, not evasion, and the agent features are dead weight.

If it is an authenticated third-party site your agent has to log into and stay logged into, buy persistence and takeover: Anchor Browser or Browserbase, with a human-in-the-loop path for the 2FA prompt that will eventually appear. The failure mode here is not blocking, it is a session dying at 2am and nobody being able to see why, which is why session replay should carry as much weight as pass rate.

If it is a protected commercial site you do not control and never will, buy the network: Bright Data or ZenRows, priced per gigabyte, and design for retries rather than perfection. Do not put an agent framework on top until the fetch layer is reliable.

And if you are unsure, connect over raw CDP with Playwright from day one. That single decision keeps every option on this table open for the price of an environment variable.

Capability fields were read off vendor documentation and marked vendor-claimed with the doc URL where the docs are unambiguous, inferred where a feature exists but the docs hedge, and unknown where we could not establish it without an account. Pricing uses the cheapest paid self-serve tier. Where a product is not billed by time — Bright Data by the gigabyte, Apify by compute unit, ScrapingBee by credit — the per-browser-hour column is null rather than converted, because the conversion depends entirely on how heavy your pages are.

The killer field, anti-bot pass rate, is deliberately empty. The planned panel is ten publicly reachable sites, one behind each of Cloudflare managed challenge, Akamai Bot Manager, DataDome, HUMAN/PerimeterX, Imperva, Kasada, F5 Shape and reCAPTCHA Enterprise, plus two commodity storefronts as a control. Fifty attempts per provider per site, cold sessions, no cookie reuse, each provider's own default stealth configuration and nothing hand-tuned, from three geographies. Success means reaching a named DOM assertion within 30 seconds; a challenge that resolves itself counts, a challenge that stalls does not. We publish the pass rate with a 95% confidence interval, the raw logs, and the exact commit of the harness, and rerun monthly. Until that runs, every cell reads unknown. We will not print vendor-claimed success rates in the meantime — that number is marketing everywhere it appears, and laundering it through a comparison table would be worse than an empty column.