Ask an engineer to ship an AI agent that books a dentist appointment and the hard part won’t be the model. It’ll be the browser. Chrome has to launch, load a sluggish booking flow, dismiss a cookie banner, find the right field, and stay alive long enough to finish the job. Run that once on a laptop and everything works. Run it five hundred times an hour and you’re watching memory climb, IP addresses get banned, and orphan processes pile up in the background.
Browserbase sells an answer to that specific problem: browsers as a service, spun up on demand and driven with the Playwright or Puppeteer code you already write.
What Browserbase actually is
Strip away the marketing and Browserbase is a thin, well-built control plane over headless Chrome. You send it an HTTP request, it hands back a live session running in an isolated container, and you connect to that browser over the Chrome DevTools Protocol. Sessions can be created, listed, and terminated through an API. There’s no Docker image to maintain, no Chromium to install, and no autoscaling group to tune when traffic spikes on a Tuesday.
What happens when you create a session
The flow is short. You POST to the sessions endpoint with your project ID and API key. The response carries a session ID and a WebSocket connect URL. You feed that URL into chromium.connectOverCDP() and your script runs exactly as it would locally, except the browser is somewhere else. When you’re finished, the session closes, or Browserbase times it out on your behalf so a crashed script doesn’t burn hours of billing.
Around that core, the platform bundles the pieces every serious automation project ends up rebuilding from scratch:
- Isolated browser sessions created in roughly a second, with no shared state between them
- Residential and datacenter proxy rotation across dozens of regions
- Contexts, which persist cookies and localStorage so an agent stays logged in
- Live View for watching a session in real time and taking manual control
- Session replay with console output, network requests, and page state preserved
- Stealth mode that patches the fingerprint signals headless Chrome leaks
- File download capture, so a generated PDF lands somewhere you can fetch it
Why teams move browser workloads off their own machines
A headless Chrome process sits somewhere between 150 MB and 400 MB of RAM depending on the page, and that figure creeps upward the longer a session stays open. Fifty concurrent sessions will make a 16 GB machine uncomfortable. Add the jobs that hang on a spinner forever, the tabs that never close, and the timeouts that leave orphan processes behind, and you’re spending more of the sprint on infrastructure than on the automation itself.
The web pushes back too. Cloudflare, DataDome, and PerimeterX flag datacenter IP ranges within seconds. A browser launched from a fresh cloud IP with a stock user agent looks like a bot because, well, it is one. Fixing that properly means fingerprint management, residential proxies, and tuning that most product teams have neither the time nor the appetite to maintain.
There’s a quieter problem as well: version drift. The Chromium on a developer’s laptop, the one in CI, and the one on the production box are frequently three different builds. A rendering change that breaks one leaves the others fine, and you find out about it at 2am.
Stagehand: natural language where selectors keep breaking
Browserbase maintains Stagehand, an open-source framework layered on top of Playwright. The premise is simple enough. Stop writing CSS selectors for elements that get renamed every other sprint. Stagehand exposes a handful of primitives: act for a single instruction like clicking a sign-in link, extract for pulling structured data off a page without hand-writing a parser, and observe for asking which actions are available before committing to one.
What separates it from a thin LLM wrapper is the escape hatch. You can drop back into ordinary Playwright calls mid-script whenever a step is deterministic and you’d rather not pay for a model round trip to click a known button. That mix matters. Natural language is worth it on messy, shifting DOM; hard-coded selectors are cheaper and faster on the parts of a flow that never change.
Browserbase also ships Director, an interface for assembling and running browser agents without wiring up the orchestration layer by hand. It’s aimed at the moment a prototype needs to become something a non-engineer can adjust.
Stealth mode, proxies, and CAPTCHA handling
Stealth mode is the feature most people sign up for first. It patches the signals that give headless browsers away: the navigator.webdriver flag, empty plugin arrays, inconsistent WebGL vendor strings, and the small mismatches between the user agent and everything else the browser reports.
Proxies come next. You can route a session through a residential IP in a specific country, either rotating per request or sticky for the life of a session. Sticky matters more than people expect, because a checkout flow that switches IP halfway through looks like fraud and gets killed.
CAPTCHAs are the honest grey area here. Browserbase supports integration with solver services and gives you the hooks, but nobody should pretend that makes blocked scraping legitimate. If a site’s terms of service forbid automation, a better fingerprint doesn’t change the legal position. Treat it as an engineering tool, not a permission slip.
Debugging is where the real value hides
An agent that fails one run in two hundred is genuinely horrible to fix. You can’t reproduce it locally, the logs are empty, and the failure never happens when you’re watching.
Live View solves half of that by giving you an interactive window into a running session. You can grab the mouse, finish the task yourself, and see precisely what the agent saw when it stalled. Session replay solves the other half. Console output, network requests, and page snapshots are retained, so you can walk back through a failed run after the fact instead of guessing.
Teams consistently underestimate this. The debugging surface, not the browser, is usually what justifies the invoice.
Contexts: keeping an agent logged in
A Context stores the browser state that normally dies with a session: cookies, localStorage, IndexedDB. Log in once, save the Context, then attach it to every session that follows. For a site with two-factor authentication or a strict login rate limit, this is the difference between authenticating once a day and authenticating once per task. It also preserves carts, filter settings, and language preferences between runs, which quietly cuts a lot of flaky failures.
Where Browserbase gets used in practice
- Web agents completing multi-step tasks: booking, filing, ordering, applying
- Scraping JavaScript-heavy sites that render nothing without a real browser
- QA pipelines and synthetic monitoring across genuine browser builds
- Price and inventory intelligence pulled from competitor storefronts
- Sales research, enriching thousands of company pages with structured data
- RPA migrations, moving brittle desktop automation into the browser
Pricing, and the cost-per-task trap
Billing is mostly by browser hour, with proxy bandwidth and overages metered separately. There’s a free tier covering roughly an hour of session time, which is enough to run a genuine pilot rather than a toy demo.
The trap is comparing vendors on hourly rate alone. What actually matters is cost per completed task. A platform that’s 30 percent cheaper per hour but fails a third of its runs is far more expensive than the one that quietly finishes the job. Factor in engineering time spent debugging, and the gap widens further.
What to test before you commit
Pick the five pages that give your automation the most grief. Run each of them one hundred times through the platform, then count failures rather than eyeballing a demo. Watch peak memory across concurrent sessions, check whether the sites you care about serve you a challenge page, and confirm where session data is stored if you have compliance obligations.
Also weigh whether you need a managed platform at all. At twenty sessions a day, local Playwright plus a decent proxy provider is fine and close to free. Keep your code portable either way. Playwright scripts move between vendors with modest edits; the API wrapper around them doesn’t, so keep that wrapper thin. The moment concurrency, stealth, and debugging hours start eating real engineering time, the arithmetic flips fast, and that’s usually the point where a cloud browser stops looking like a luxury.