Jason Lee

Posted on Aug 20

Your AI Agent Doesn't Need a Better Browser. It Needs Someone Else to Fight Cloudflare For It.

#ai #webdev #automation #opensource

If you're building anything that touches a real website with an AI agent right now — a research assistant that has to read a paywalled article, a pricing bot that has to check a competitor's checkout flow, an ops agent that has to file a support ticket through a web form nobody built an API for — you've hit the same wall everyone else building agentic browsing hits in 2026: Playwright and Puppeteer will happily open a browser, but the browser you open on a cloud VM looks nothing like the browser a human opens on their laptop, and increasingly the websites you're targeting are built to notice the difference.

That's created a real, live decision point. Four names keep coming up when developers ask "what do I actually run underneath my browsing agent": Browserbase, Steel, Hyperbrowser, and Browser Use. Most comparison posts throw all four into one table and ask which is "best." That's the wrong question, and answering it that way is why so many teams end up paying for the wrong thing or self-hosting the wrong layer. These four products don't all compete for the same job. Two of them are deciding what to click. Two of them are hosting the browser that gets clicked in. Picking the wrong pair to compare costs you either money or months.

The layer confusion, made concrete

Strip away the marketing and there are two separate problems in "give an AI agent a browser":

The reasoning problem — given a screenshot or a DOM snapshot and a goal ("find the cheapest flight," "fill out this intake form"), decide what to click, type, or scroll next. This is an LLM-driven loop.
The infrastructure problem — actually run a Chromium instance somewhere, keep it alive across a multi-step session, make it look enough like a real browser that the site doesn't block it, capture what happened for debugging, and do all of that at whatever concurrency your product needs.

Browser Use is overwhelmingly a solution to problem 1. It's an open-source Python framework — MIT licensed, and its GitHub repo has crossed 100,000 stars — that wires an LLM (OpenAI, Gemini, Claude, or others) to a browser and lets the model decide the next action step by step. It ranks near the top of independent long-horizon web-task leaderboards, reportedly hitting around 87% average success across 200 multi-step tasks on the Odysseys benchmark, and separate benchmark runs have put it near 89% on WebVoyager. That's the reasoning layer doing its job well.

Browserbase, Steel, and Hyperbrowser are, first and foremost, solutions to problem 2. They don't decide what to click — they give you (or your agent framework) a Chromium instance that survives longer, hides better, and is easier to debug than one you'd spin up yourself on a bare VM.

The part that trips people up: these aren't mutually exclusive. Browser Use ships an optional hosted "cloud agent" that bundles its own reasoning loop with managed infrastructure, effectively competing with Browserbase directly at that tier. And Browserbase's first-party automation SDK, Stagehand, is explicitly built to run on top of Browserbase's own infrastructure — the same "AI decides, code executes" pattern Browser Use popularized, just wrapped around Browserbase's session layer instead of a generic Playwright script. So the realistic architectures people ship are compositions: Browser Use's open-source library pointed at Steel's self-hosted containers; Stagehand running on Browserbase-managed sessions; a homegrown agent loop hitting Hyperbrowser's API for the sessions and doing its own reasoning in-house. Comparing "Browser Use vs. Browserbase" as if you pick one is a category error most of the traffic on this topic doesn't correct.

What each one actually is, and how it's built

Browserbase is a managed cloud-browser platform built around Chromium sessions exposed over the Chrome DevTools Protocol, compatible with Playwright, Puppeteer, and Selenium. What differentiates it architecturally is the stealth layer: Browserbase runs a purpose-built Chromium with fingerprints tuned to be recognized by bot-protection vendors — it calls this "Signed Agents," a mechanism aimed at getting agentic traffic acknowledged rather than silently blocked by services like Cloudflare — plus a "Verified" mode in Stagehand that gives a session a checkable identity for sites that gate bot traffic outright. Sessions persist with full replay, so when an agent run fails at 2am you get a video and a DOM trace instead of a stack trace pointing at a blank page. That observability layer, more than the browser itself, is what teams are actually buying.

Steel takes the opposite architectural bet: it's an open-source (Apache 2.0) browser API — steel-dev/steel-browser on GitHub, sitting around 7,500 stars — built on Puppeteer and CDP, and it's designed to be self-hosted as easily as docker run -p 3000:3000 ghcr.io/steel-dev/steel-browser. It gives you session/cookie persistence, proxy-chain management, extension support, request logging, stealth plugins, and built-in page-to-markdown/PDF/screenshot extraction — essentially the same feature list as Browserbase, minus the proprietary anti-bot fingerprint work, plus the option to run it on your own infrastructure or on Railway/Render instead of paying per session.

Hyperbrowser sits closer to Browserbase on the managed-infrastructure side but leans harder into bundling its own hosted agent runtimes on top of raw sessions, plus built-in CAPTCHA solving and stealth-by-default rather than stealth as a higher-tier add-on. It's positioned for teams doing high-volume scraping and crawling workloads where a per-session model with volume discounts matters more than deep session-replay tooling.

Browser Use, again, is a different kind of artifact entirely: a Python library you pip install that wraps an LLM call in a perception-action loop against whatever browser you point it at — your local Chrome, a Steel container, a Browserbase session, or its own hosted cloud agent, which adds proxy rotation, CAPTCHA solving, "1000+ integrations," and persistent memory across runs for teams that don't want to run the open-source loop themselves.

What changed to make this a live decision now

Two years ago, "browser automation for AI" mostly meant a script calling Playwright directly, with maybe a rotating-proxy service bolted on, and a human writing brittle CSS selectors by hand. That approach is quietly breaking down for three reasons developers are running into in 2026.

First, bot-detection has gotten materially better at fingerprinting headless Chromium specifically — TLS handshake ordering, canvas rendering quirks, WebGL fingerprints, and CDP-detectable automation flags are all things major sites now check, which is why "stealth" stopped being a script flag (--disable-blink-features=AutomationControlled and hope) and became a product category with its own pricing tier. A configuration that reliably passed as a real browser eighteen months ago can get silently flagged today because the detection vendor on the other end shipped an update — this is genuinely an arms race, not a one-time integration.

Second, LLM-driven browsing agents changed the traffic pattern. Instead of one scraper hitting the same three pages a million times on a predictable schedule, you now have thousands of short-lived, unpredictable multi-step sessions where the agent doesn't know in advance how many pages it'll visit or how long a task will take. That's a different infrastructure problem — session lifecycle management, mid-run replay for debugging, cost-per-session rather than cost-per-request — than classic scraping infrastructure was built to optimize for, which is a large part of why "browser infrastructure for AI agents" emerged as its own category distinct from older scraping-proxy services.

Third, benchmark culture arrived. WebVoyager, Odysseys, and similar long-horizon web-task leaderboards gave the market a way to argue about agent quality with numbers instead of vibes, which is part of why Browser Use's benchmark placement gets cited as often as its GitHub star count. It also means the reasoning layer and the infrastructure layer now get evaluated on different axes entirely — one on task success rate, the other on uptime, latency, and stealth durability — which is further evidence they're not really the same purchase decision.

Performance numbers, with the caveat they deserve

One comparison of Browserbase, Steel, and Hyperbrowser reported Steel starting new browser sessions in around 894 milliseconds at the median (p95 around 1,090ms), with Steel, Hyperbrowser, and a fourth infra vendor called Kernel completing 100% of test sessions in that run, against roughly 99.96% for Browserbase. Numbers like this are worth having in your head, but treat them the way you'd treat any single-run synthetic benchmark: startup latency and completion rate both depend heavily on which regions you're testing from, what target sites you're hitting, and how the test defines a "completed" session. A 0.04-percentage-point completion gap is close enough to noise that it shouldn't be your deciding factor; what's more informative is that all four infra vendors are now converging on sub-second session starts and 99%+ completion as table stakes, which tells you the differentiation between them has moved to stealth durability and developer experience rather than raw uptime.

Stagehand: where the two layers actually meet

If you want to see the framework/infrastructure split collapse into a single product, look at Stagehand, Browserbase's first-party automation SDK. It plays a similar role to Browser Use — you give it natural-language instructions like "click the login button" or "extract the price," and it uses an LLM to resolve that into concrete Playwright actions — but it's explicitly designed to run against Browserbase's managed sessions rather than being backend-agnostic, and it also works with plain Playwright, Puppeteer, or Selenium if you point it elsewhere. That makes it the cleanest illustration of the point this whole piece is making: Browserbase isn't just selling you a browser, it's selling you a browser plus a reasoning layer that assumes that browser, bundled as one product. Whether that bundling is a convenience or a lock-in depends entirely on whether you'd have picked their infrastructure anyway.

Why this actually matters to you, concretely

Cost model. Browserbase bills browser-hours plus API calls plus model tokens, with published tiers at Free, Developer ($20/month), Startup ($99/month), and a custom Scale tier; its Fetch API is metered separately at roughly $1 per 1,000 calls for raw HTML up to $7 per 1,000 for JSON extraction through proxies. Steel's cloud offering starts free and its self-hosted path can run on a few-euro-a-month VPS if you're willing to operate Docker yourself — reports put long-running self-hosted browser-hours around $0.05–$0.10/hour equivalent, which is a different order of cost at real scale, but you're now on the hook for the ops. Browser Use's hosted cloud agent starts around $30/month; the open-source library itself is free but only as free as the compute and proxies you provide it. None of these numbers are apples-to-apples because they're metering different things — sessions, hours, API calls, tokens — so the actual comparison you need to run is against your own traffic shape, not the sticker price.

Lock-in. This is the sharpest line between Steel and the rest. Because Steel is Apache-2.0 and genuinely self-hostable, you can start on their cloud and move to your own infrastructure later without a rewrite — that's a real hedge against a pricing change or a company being acquired. Browserbase and Hyperbrowser are API-only; there's no "just run it yourself" escape hatch if their pricing moves or your volume outgrows their tier structure. That's a fair trade for their stealth engineering, but it is a trade, not a free lunch.

Security and custody. A managed browser session is, functionally, something that holds your users' or your service accounts' cookies, auth tokens, and sometimes payment flows mid-session. Handing that to a third party is a real attack-surface and compliance decision, not a footnote — if you're automating anything behind a login for a regulated customer, "where do the session credentials live and who can replay that session" deserves the same scrutiny you'd give a secrets manager, and self-hosting (Steel) versus trusting a vendor's isolation guarantees (Browserbase, Hyperbrowser) is a genuinely different risk posture, not just a cost one.

Maintainability. Anti-bot fingerprinting is an arms race, not a solved problem — a stealth configuration that works against a given site's bot-detection today can silently stop working after that site's vendor ships an update, with no error message, just agent runs that quietly start failing. That's the ongoing maintenance tax you're paying a managed vendor to absorb; if you self-host on Steel, that tax comes back to your team, and it's a genuinely different kind of work than most backend teams are staffed for — closer to security-research cat-and-mouse than routine ops.

Concurrency and scaling behavior. This is where the pricing-page numbers get misleading if you don't do the arithmetic for your own workload. A team running ten concurrent agent sessions of a few minutes each looks completely different, cost-wise, than a team running one long-lived session that stays open for hours polling a dashboard. Browserbase and Hyperbrowser both cap concurrent sessions by plan tier, so an agent product that suddenly goes viral can hit a hard concurrency wall before it hits a cost wall — worth load-testing against your actual plan limit, not just the advertised price. Steel's self-hosted path sidesteps the concurrency cap entirely, but replaces it with "how many Chromium instances can this VPS's RAM actually hold," which is its own ceiling you have to model yourself instead of reading off a pricing page.

Migration cost, if you guess wrong. Because Browserbase, Steel, and Hyperbrowser all expose a CDP-compatible endpoint that Playwright, Puppeteer, and Selenium can connect to, swapping the underlying infrastructure vendor is usually a config change — a different wsEndpoint — rather than a rewrite, as long as your code didn't hardcode vendor-specific features like Browserbase's Signed Agents or Hyperbrowser's built-in CAPTCHA solver. The actual switching cost lives in whichever proprietary stealth or convenience feature you leaned on hardest; the more of those you use, the more a later migration looks like a rewrite instead of a config change, which is worth keeping in mind before you build deep integration with any one vendor's exclusive feature.

Practical use cases

Browserbase fits teams shipping a customer-facing agent feature where a failed run needs to be debuggable by a human in minutes — the session replay and observability are the point, and the Scale-tier stealth is worth it against sites that actively fight automation (ticketing sites, e-commerce checkouts, anything behind Cloudflare's more aggressive tiers). It's also the pragmatic default for a small team that doesn't want to own a second infrastructure surface on top of everything else they're already operating.
Steel fits teams with steady, high-volume, cost-sensitive workloads (large-scale scraping, internal tooling, data pipelines) where DevOps capacity exists to run and patch a Docker container, and where vendor lock-in is a board-level concern — think a data platform team that already runs a Kubernetes cluster and would rather add one more container type than add one more SaaS invoice.
Hyperbrowser fits volume scraping/crawling operations that want CAPTCHA-solving and stealth included by default without configuring a separate tier, and are optimizing for throughput over deep debugging tooling — a good fit for a lead-generation or price-monitoring pipeline where individual session failures matter less than aggregate completion rate.
Browser Use fits the reasoning layer of almost any of the above — it's the thing you'd pick to decide what the agent does, whether it's running against your own Chrome instance, a Steel container, or (via its hosted cloud agent) skipping infrastructure decisions entirely for a flat monthly fee. It's also the natural choice for research and prototyping, since you can validate whether an agent can even complete your target task before committing to any infrastructure spend at all.

Team size is a useful proxy here even though none of the vendors frame it that way. A solo developer or small startup validating a product idea is almost always better served starting with Browser Use's free library against a local browser, because the entire point at that stage is learning whether the agent can do the task at all, not optimizing session cost. A mid-size team with a live product and real users tends to land on Browserbase or Hyperbrowser, because the cost of an engineer's time spent debugging a mystery stealth failure usually exceeds the price difference between a managed plan and self-hosting. A platform or data-infrastructure team with existing ops capacity is the group most likely to get genuine, durable savings from Steel's self-hosted path, because they're already paying the ops tax on other systems and the marginal cost of one more container is close to zero.

What the marketing pages don't say

Vendor pricing pages for all three infrastructure providers foreground the free tier and undersell how fast browser-hours and per-call fees compound once an agent is doing multi-step tasks — a single agentic run that reads five pages and retries twice isn't one billing unit, it's several, and that adds up differently than a simple scraper hitting one URL per call. "Stealth" claims across all three vendors are inherently unverifiable from outside: none publish ongoing, third-party-audited success rates against specific bot-detection vendors over time, only point-in-time benchmarks that go stale as detection systems update — treat any specific stealth percentage you read (including the reliability numbers cited above) as a snapshot, not a guarantee. And Browser Use's leaderboard placement, like most agent benchmarks, measures success on a fixed task set chosen by the benchmark's authors; a framework optimized for Odysseys or WebVoyager tasks isn't automatically the best choice for your specific website, especially if it's one with unusual UI patterns the benchmark doesn't cover.

Comparison table

Dimension	Browserbase	Steel	Hyperbrowser	Browser Use
Primary layer	Managed infrastructure	Infrastructure (open source, self-hostable)	Managed infrastructure	Reasoning/agent framework
License / model	Proprietary SaaS	Apache 2.0	Proprietary SaaS	MIT (core library)
Self-hosting	No	Yes (Docker, one command)	No	Yes (it's a local library)
Entry pricing	Free tier; $20/mo Developer; $99/mo Startup	Free tier; self-host from ~€9/mo VPS	Usage-based, volume-oriented	Free (OSS); hosted cloud agent from ~$30/mo
Stealth/anti-bot	Purpose-built Chromium, "Signed Agents," Verified mode (top tier)	Stealth plugins, proxy-chain management, DIY-tunable	Built-in CAPTCHA solving, stealth-by-default	Delegated to whatever browser backend it's pointed at
Session observability	Strong — replay, DOM trace, session UI	Present — request logging, debugging UI	Present, less emphasized	None natively — it's not hosting the session
First-party agent SDK	Stagehand	None (BYO agent)	Hosted agent runtimes	Is the agent framework
Best fit	Debuggable, customer-facing agents against hard-to-scrape sites	Cost-sensitive, high-volume, lock-in-averse teams with ops capacity	High-throughput scraping/crawling	Any team choosing the decision layer, independent of infra vendor

An independent read

None of these four are lying about what they do, but the framing of "which browser tool should I use" obscures that you're very likely choosing two things, not one: a reasoning layer and a hosting layer. Browser Use's open-source pull is real and the star count reflects genuine adoption, but its own hosted cloud agent is a tacit admission that plenty of teams don't want to run infrastructure at all — at which point you're back to comparing it against Browserbase and Hyperbrowser on infrastructure terms, not agent-quality terms.

Steel's Apache license is the most substantive differentiator in this whole category, not a footnote — "you can leave" is worth more than most feature comparisons, especially in a market this young where the infrastructure vendors are venture-funded startups whose pricing and priorities can shift fast as they chase profitability. A team that self-hosts Steel today isn't just saving money; it's opting out of the risk that a vendor's Series B runs out and the pricing model changes overnight, which is a real thing that has happened across the API-infrastructure space more broadly, not a hypothetical.

Browserbase's stealth engineering looks like the most defensible moat in the group, precisely because it's the hardest thing to replicate and the thing self-hosting doesn't solve for you — Steel gives you the tools to build stealth (proxy rotation, fingerprint plugins) but not the ongoing research investment Browserbase is putting into being recognized by bot-detection vendors specifically. That's a genuinely different kind of product even though the feature lists on both marketing pages look similar at a glance.

The one claim worth being skeptical of across all three infrastructure vendors is any specific, unqualified success-rate number for "getting past bot detection" — none of them publish an ongoing, third-party-audited number for this, for the same reason no security vendor publishes a live scorecard of which of their defenses currently work: the moment you publish it, it becomes a target and a stale one within weeks.

Which reader should pick which option

If you're prototyping an agent and don't yet know your traffic shape, start with Browser Use's open-source library against a local or Steel-hosted browser — it's free, it's the fastest path to something working, and it doesn't lock you into an infrastructure bill before you know if the product works. If you're shipping a customer-facing feature against sites that actively fight bots and you need to debug failures without SSHing into a container, Browserbase's replay tooling and stealth tier are worth the higher price. If you're running steady, high-volume internal automation and have the ops capacity to run a container, Steel's self-hosting option will very likely be materially cheaper over a year and removes vendor risk entirely. If your workload is closer to bulk scraping/crawling than interactive agent sessions, Hyperbrowser's throughput-and-CAPTCHA-first positioning fits better than either of the other two managed options. None of these are permanent choices — because Playwright/CDP/Puppeteer compatibility is the norm across all three infra vendors, and Browser Use is backend-agnostic by design, switching later is a config change, not a rewrite, which is exactly why it's worth picking the cheapest reasonable option now rather than over-optimizing this decision up front.

What's your experience been with anti-bot detection breaking agent runs in production — have you found a stealth layer that actually holds up over months rather than weeks, or does every managed vendor's fingerprint eventually get caught by the sites you're targeting?

Sources:

DEV Community