Cloud Browser Session

A cloud browser session is a single isolated browser instance provisioned on a vendor's infrastructure and driven remotely over the Chrome DevTools Protocol, with its own fingerprint, cookie and local storage state, proxy assignment, and lifetime. It is the unit that browser-infrastructure vendors provision, meter, and bill on, which is why concurrent session count rather than request count is what caps throughput on these plans.

Mechanically, your code connects a normal Playwright or Puppeteer client to a remote WebSocket endpoint instead of launching a local Chromium, and everything after that looks like ordinary automation. What the vendor adds around that connection is the product. Session persistence lets you save the cookie and storage state under an identifier and resume it hours later, so an agent that logged into a site once does not have to solve the login again on every run. Live view exposes the running session as an embeddable stream, and takeover lets a human interrupt and drive it directly, which is how teams handle the cases an agent cannot legitimately clear on its own: an MFA code, a payment confirmation, a consent screen. Sessions also have timeouts and idle limits, and a session that is left open because a script crashed is still billing.

Pricing follows two dials, and buyers routinely model only the first. Browserbase's published plans as of July 2026 are $20 per month for the Developer tier with 100 browser hours included and $0.12 per hour after, and $99 per month for the Startup tier with 500 hours included and $0.10 per hour after. The second dial is concurrency: 3 concurrent browsers on the free tier, 25 on Developer, 100 on Startup, with higher limits on the custom Scale tier. Browserbase's own guidance is that a typical scrape finishes in under two minutes and that 100 browser hours is roughly 3,000 page-level tasks. Read those two dials together. An agent product with bursty traffic will hit the concurrency ceiling long before it exhausts its hours, because 200 users arriving at once need 200 simultaneous sessions regardless of how briefly each one runs.

That makes session reuse the main cost and reliability lever. Keeping one authenticated session alive across a multi-step task is cheaper and far more reliable than launching a fresh browser per step, because each cold launch pays the startup cost, re-triggers bot detection, and discards the trust the previous session accumulated. The vendors differ mainly in what they wrap around that session: Browserbase pairs its infrastructure with the Stagehand SDK, Steel.dev is open source and self-hostable if you would rather own the runtime, Hyperbrowser sells fast launches and natural-language control, and Anchor Browser operates as a verified Cloudflare bot, which matters if the sites you need are behind Cloudflare and you would rather be recognized than evade.