Browser automation APIs

The category has split into three products that share a name. Agent infrastructure (Browserbase, Steel, Hyperbrowser, Anchor, Kernel, Airtop) sells you a browser with a live view, persistent profiles and an MCP server, priced by the browser-hour. Unblocking infrastructure (Bright Data, ZenRows, ScrapingBee) sells you a residential IP pool with a browser bolted on, priced by the gigabyte or the request. Platform infrastructure (Apify, Cloudflare) sells you somewhere to run code that happens to include Chromium. Buying the wrong one is the most common mistake here: teams pick a per-hour agent host, point it at a DataDome-protected site, and conclude that "browser APIs don't work".

For agents, Browserbase is still the one to beat. Not because the browsers are faster — nobody has shown that they are — but because the surface area is finished: contexts that survive a session, an embeddable live view you can hand a human, extension loading, downloads that land somewhere you can fetch them, and Stagehand as a genuinely useful SDK rather than a demo. Anchor Browser is the sharpest alternative if your agent's real problem is logging in: authenticated profiles and human takeover are the whole pitch rather than a feature row. Airtop goes furthest in the other direction, giving you a natural-language extraction API so you never touch a selector, which is excellent until you need to touch a selector. Kernel and Hyperbrowser are both credible and cheaper-feeling, with less track record.

For unblocking, ignore the agent features entirely and buy IP quality. Bright Data's Browser API is expensive per gigabyte and worth it, because CDP-over-residential-proxy with automatic challenge handling is a genuinely hard thing to operate. ZenRows is the value pick and has closed most of the gap. ScrapingBee is not a browser API at all — it is an HTML endpoint with JavaScript rendering, no CDP, no session — and it is priced and documented honestly as such, which makes it a fine choice for one-shot fetches and a terrible one for multi-step flows.

Two structural things are worth watching. First, MCP servers went from differentiator to table stakes in about nine months; by mid-2026 a vendor without one looks abandoned, and the servers themselves are thin wrappers that tell you nothing about the underlying browser. Second, the pricing units are drifting apart on purpose. Per-hour, per-session, per-request, per-gigabyte and per-credit cannot be compared without knowing your traffic shape, and every vendor picks the unit that flatters it. Run a week of your own workload against two providers before signing anything annual.

The honest position on the numbers: nobody in this category will tell you their real block rate, us included — yet. The success-rate column on this page is empty because we have not run the panel, not because the vendors declined to comment. Everything else here is a checkable capability; treat the anti-bot marketing as unfalsifiable until somebody publishes logs.

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.