Browserbase

Browserbase provides hosted browser infrastructure for web automation. Instead of running your own Playwright or Puppeteer fleet, you create cloud Chromium sessions that agents, scrapers, and QA jobs can control. The platform now spans browser sessions, Search and Fetch APIs, Functions runtime, Identity, Model Gateway, observability, MCP, and open-source layers such as Stagehand.

What Changed Since The Last Refresh

• Pricing did not materially change: Free, Developer at $20/month, Startup at $99/month, and Scale custom remain the headline plans.
• The product framing moved further toward a full browser-agent platform. Browserbase’s June Browser explainer describes a real cloud Chromium browser wrapped with identity, observability, persistence, and live debugging.
• Fetch API is more important than the old page implied: the May changelog says Fetch can return markdown or structured JSON, raised its data cap from 1MB to 5MB, and prices Extract around $4 per 1,000 pages or $7 per 1,000 pages with proxies.
• Session replay streaming became a product surface for embedding HLS-compatible replays in customer products, free on every plan up to 120 sessions per minute.
• Stagehand 3.4 changed agent behavior: ignoreSelectors, agent variables without the experimental requirement, hybrid default agent mode for compatible models, stronger frame handling, and new computer-use model support including GPT-5.5.
• Model Gateway is no longer just a pricing footnote. Browserbase docs say it routes OpenAI, Anthropic, and Google model calls through the Browserbase API key at market-price token billing with no markup.

Where it fits

AI agents often fail not because the model cannot reason, but because browser execution is brittle: sessions expire, CAPTCHAs appear, pages load slowly, and screenshots need to be streamed back to the model. Browserbase abstracts much of that operational burden. The current public site and docs now separate the stack into hosted browsers, Search API, Fetch API, Functions runtime, Identity, Model Gateway, and observability. That matters because interactive browsing, read-only extraction, deployed agents, authenticated sessions, model routing, and replay debugging have different costs and failure modes.

Buyer fit

Browserbase is strongest when browser use is part of your product’s backend, not just a one-off script. Typical fits include AI agents that need to operate websites, QA systems that replay user journeys, enrichment pipelines that need page rendering, and internal tools that need a controlled browser runtime with observability.

The buy-versus-build question is practical. If your automation is small, predictable, and internal, self-hosted Playwright or Puppeteer may be enough. If sessions need isolation, identity handling, runtime controls, stealth behavior, debugging, and production monitoring, managed infrastructure becomes easier to justify. The cost is not just session pricing. It is the engineering time spent keeping browser fleets reliable.

Compare Browserbase with bare browser-hosting providers, Stagehand-style agent abstractions, and in-house Playwright clusters. Do not compare it with Comet or Dia as if all AI browsers solve the same job. Browserbase is for software systems that use the web. Comet and Dia are for humans using the web.

Pricing Notes Verified 2026-06-18

Browserbase lists four plans. Free includes 3 concurrent browsers, 1 browser hour, 1,000 Search calls, 1,000 Fetch calls, 15-minute sessions, 7-day retention, and $5 in model tokens. Developer is $20/mo with 25 concurrent browsers and 100 browser hours, then $0.12/browser-hour, plus 1,000 included Search calls and 1,000 included Fetch calls. Startup is $99/mo with 100 concurrent browsers and 500 browser hours, then $0.10/browser-hour, plus 1,000 Search calls and 10,000 Fetch calls. Scale is custom with 250+ concurrent browsers and enterprise features such as SSO, DPA/BAA options, verified agents, and advanced CAPTCHA solving.

The unit economics depend on workload shape. A short fetch-heavy enrichment task can be cheap, especially if Fetch avoids launching a full browser session. A long-running browser session with login, proxy traffic, screenshots, model calls, replays, and retries can cost more than the headline plan price suggests. Track browser hours, Search calls, Fetch calls, Extract calls, proxy usage, Model Gateway spend, session replay needs, retention requirements, and runtime deployment separately.

Best plan recommendation

Use the free tier only to validate API fit, not production economics. The Developer plan is the practical starting point for solo builders or small teams proving an agent workflow because it gives enough concurrency and browser hours to test real flows without jumping straight to custom sales. Startup becomes the more realistic fit once the workload is part of a product or internal platform and needs higher concurrency, longer debugging windows, and a cleaner cost baseline.

Move to Scale only when the browser layer is a production dependency. At that point, the evaluation should include SSO, security review, data processing terms, verified agents, retention, and escalation support. The platform is easiest to justify when it replaces a fragile internal browser fleet, not when it is used for one script that already runs reliably on a cheap VM.

Practical evaluation

Before standardizing on Browserbase, run a pilot with real failure cases:

• A logged-in workflow with identity and session persistence.
• A JavaScript-heavy site that requires real browser rendering.
• A fetch-only extraction job where Fetch API is cheaper than full browser sessions.
• A QA path that needs screenshots, replay, logs, and alerting.
• A workload that triggers CAPTCHAs, bot checks, or rate limits.
• A batch job large enough to expose concurrency and cost limits.

The goal is to learn whether Browserbase removes operational risk or just moves the complexity into platform configuration.