All four of these services sell the same thing at the API boundary — a real Chrome you drive over CDP or Playwright — so the SDK comparison everyone opens with decides almost nothing. What you are actually choosing is who holds the logged-in session: the cookies, the stored profile, the credentials that recreate it when it expires, and the exit IP whose reputation your account inherits. That is the decision you cannot cheaply reverse, and it is the one the feature tables leave out.
At a glance
Four providers, four different answers to "what is the hard part of running a browser for an agent".
| Provider | Licence & hosting | Leans hardest on | Buy it when |
|---|---|---|---|
| Browserbase | Proprietary cloud; its framework Stagehand is MIT. | Developer experience — session replay, stable CDP surface, native Stagehand integration. | You want the shortest path from prototype to something debuggable. |
| Steel | steel-dev/steel-browser under Apache 2.0; self-host or use their cloud. |
Openness — the same server runs on your infrastructure or theirs. | Exit cost or data residency is the constraint, or you want to run it yourself. |
| Hyperbrowser | Proprietary cloud. | Getting through — stealth by default, captcha solving, proxy rotation. | The target sites fight back and volume is high. |
| Anchor Browser | Proprietary cloud, with BYOC and on-premise at enterprise tiers. | Authenticated work — secret injection, stored login state that re-authenticates, per-session isolation. | The agent logs in as a real user and procurement has questions. |
Why the API is not the decision
Every one of these speaks the Chrome DevTools Protocol, which means the code that clicks and types is portable between them in an afternoon. Teams discover this after choosing, and conclude that switching is easy. It is not, and the reason is that the portable part is the part that was never expensive.
What does not move is the state. A month into production, a working browser agent has accumulated logged-in profiles for a dozen services, a set of proxy egress IPs the target sites have come to tolerate, and — if it does anything useful — credentials sitting somewhere in the provider's boundary. Migrating means re-authenticating every profile, warming a new IP reputation, and moving secrets. The API is a weekend; the identity is a quarter.
So evaluate on the state, not on the client library. Three questions get you most of the way: where do stored logins live and can you export them, does the model ever see a credential, and whose IP is the target site actually blocking when things go wrong.
Credentials are the axis nobody scores
The default is worse than teams assume
The naive implementation puts the password in the prompt. The agent is asked to log in, the credential is in its context, and it is now in your traces, in your provider's logs, and reachable by any injection that lands in the page the agent just read. This is the browser-agent version of the data-exfiltration problem, and it is common precisely because it is the first thing that works.
The three answers on offer
Anchor's pitch is aimed squarely here: secrets are injected into the session by the platform rather than passed through the model, stored login state re-authenticates itself when it expires without custom logic, and end users can connect their own accounts without the application handling credentials. Browserbase and Steel both offer managed profiles, which solves the recurring-login problem — the session persists, so you log in once — without solving the first-login problem, since something still has to supply the password. Hyperbrowser's centre of gravity is elsewhere; if your workload is authenticated rather than adversarial, it is not the one optimised for you.
What to require regardless of provider
Credentials never enter model context. Profiles are scoped per tenant, not shared across customers. Session state is exportable, because a profile store you cannot export is the exit cost. And the session terminates on a schedule you set — a browser holding a live authenticated session is a standing capability, and the reason scoped credentials argues for short lifetimes applies here with more force, not less.
The latency you feel is control plane, not browser
The only public benchmark in this space is steel-dev/browserbench, and it is published by Steel — one of the four. Take the ranking with the obvious grain of salt, then note two things: it is open source, so you can run it against your own workload, and the effect it measures is large enough that the ordering is unlikely to be an artifact of who wrote it.
On those figures Steel's control plane creates a session in roughly 229 ms, about 1.6× faster than Browserbase, 12.8× faster than Hyperbrowser and 28.6× faster than Anchor. For Hyperbrowser and Anchor the control plane is around 80% of total session latency; for Browserbase it is about 22%. Full create-to-release lifecycle comes out at about 0.89 s average and 1.09 s at p95 for Steel, against roughly 1.68 s and 1.87 s for Browserbase.
Whether that matters is a workload question, and the answer flips cleanly. An agent that opens one session and works inside it for four minutes will never notice a two-second startup. A workload that creates a fresh isolated session per task — which is what you do when tasks touch different tenants — pays it on every task, and at that point a multi-second control plane is the dominant cost in the run. Measure your own session-to-work ratio before letting a benchmark decide anything.
Stealth is a liability transfer, not a capability
Fingerprint spoofing, residential proxy rotation and captcha solving are sold as features, and functionally they are. They are also the part of this stack where the vendor is doing something on your behalf that your legal and security teams would want to know about, and the product page is not where that conversation happens.
- The arms race does not converge. A detection vendor ships an update, your success rate drops, and you are waiting on your provider. Buying stealth means buying a dependency whose reliability is set by a third party actively working against it — so treat success rate against your specific targets as an ongoing metric, not an onboarding check.
- Shared IP pools mean shared reputation. On a residential proxy pool you inherit the behaviour of everyone else using it. A target that blocks the range blocks you for something you did not do, and you have no visibility into why.
- Solving a captcha is a statement about consent. A site that deployed one has expressed a preference. Whether working around it is acceptable depends on your terms of use, your jurisdiction and what you are doing — and it is a question worth answering before the volume gets large, not after.
- Authenticated workloads mostly do not need it. If the agent is logging into an account your user owns, the site is not trying to stop you. Buying evasion for that workload adds a fingerprint-spoofing layer that can itself trip fraud detection on a legitimate login.
When to pick which
| Situation | Pick | Because |
|---|---|---|
| Prototyping, or you want replay and good ergonomics first | Browserbase | Best-in-class debugging surface and native Stagehand integration; middle of the pack on everything else, which is fine when you are still learning the shape of the problem. |
| Data residency, air-gap, or you refuse to be locked in | Steel | Apache-2.0 server you can run yourself, and the same server in their cloud — so the exit is a deployment change rather than a rewrite. Fastest control plane in the one public benchmark. |
| High-volume scraping against sites that fight back | Hyperbrowser | Stealth, proxy rotation and captcha handling are the product rather than an add-on, and the economics are built for sustained volume. |
| The agent logs in as a real user, and procurement is involved | Anchor Browser | Secret injection keeps credentials away from the model, stored logins re-authenticate on expiry, per-session VM isolation and audited tiers with BYOC and on-premise options answer the questions procurement will ask. |
| Short tasks, thousands of fresh sessions per hour | Steel or Browserbase | Session creation is the dominant cost at that ratio, and the two slower control planes turn it into most of your wall clock. |
The uncomfortable answer for many teams is that they need two: one provider for authenticated work against systems their users own, and another for open-web retrieval. Those are genuinely different problems with different risk profiles, and forcing them onto one vendor is how you end up buying evasion features for a login flow.
FAQ
Can I switch providers later?
The automation code, yes — all four speak CDP, so the driving layer moves in a day. The state does not: stored logins, warmed IP reputation and any credentials held by the provider all have to be recreated. Ask about profile export before you sign, not after.
Which one is open source?
Steel publishes its browser server as steel-dev/steel-browser under Apache 2.0 and it is fully self-hostable. Browserbase's framework Stagehand is MIT, but the cloud service itself is proprietary — those are different claims and they are frequently conflated.
Is the latency benchmark trustworthy?
It is published by Steel, who come first in it, so read the ranking sceptically. It is also open source and re-runnable, and the gaps it reports are large — more than 12× between the fastest and third-placed control plane — so the ordering is probably real even if the margins are flattering. Run it on your own workload if the number matters.
Do I need residential proxies?
Only if your targets are actively blocking datacentre traffic. For authenticated work against accounts your users own, residential exit is usually unnecessary and occasionally harmful, since an unexpected IP is itself a fraud signal on a legitimate login.
How do I keep credentials out of the model's context?
Use a provider that injects secrets into the session itself, or handle the login outside the agent loop and hand it a session that is already authenticated. If the password ever appears in a prompt it is in your traces and reachable by prompt injection — see prompt injection.
Is this the same choice as picking a browser-automation framework?
No, and conflating them is the common error. Browser-use, Stagehand, Skyvern and Playwright MCP decide how the agent perceives and acts on a page; these four decide where the browser runs and who holds its identity. You need one of each.
Further reading
On this wiki:
- Browser agents — the playbook for building on top of any of these.
- Browser Agent Failure Modes — what goes wrong once it is running.
- Computer Use & GUI Agents — the wider category, from cold.
- Egress Control for Agents — why a hosted browser is an egress path you do not operate.
- Scoped Credentials for Agents — the standard to hold a provider to.
- Browser-use vs Stagehand vs Skyvern vs Playwright MCP — the framework layer above this one.