Browserbase

Browserbase provides hosted Chromium infrastructure for web agents, scraping, QA, and automation. Instead of running your own Playwright, Puppeteer, or Selenium fleet, teams create cloud browser sessions and pair them with Search, Fetch, Functions runtime, Identity, Model Gateway, observability, MCP, and Stagehand.

What Changed Since The Last Refresh

• Pricing stayed stable on June 26: Free, Developer at $20/month, Startup at $99/month, and Scale custom remain the headline plans.
• Browserbase’s June 16 explainer frames the product as a real cloud Chromium browser for agents, with identity, observability, persistence, live debugging, Search, Fetch, Functions, Model Gateway, and Stagehand around it.
• Fetch now matters more for cost planning. Browserbase’s May update added markdown and JSON output, raised the cap to 5MB, and prices Extract at $4 per 1,000 pages or $7 per 1,000 pages with proxies.
• The June pricing table exposes more usage math: Developer Fetch overage is $1 per 1,000 standard calls, while Startup is $0.50 per 1,000 standard calls. Proxy Fetch and Extract stay higher.
• Stagehand and replay improved in May, but those are implementation details. The buyer issue is whether your workload needs full browser sessions or cheaper Search and Fetch pre-filtering.

Which API to use

Browserbase is easiest to price when you split the job before launching browsers:

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, CAPTCHA handling, replay, 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-26

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. Developer Fetch overage is $1 per 1,000 standard calls or $4 per 1,000 with proxies. 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. Startup Fetch overage is $0.50 per 1,000 standard calls or $4 per 1,000 with proxies. Extract is $4 per 1,000 pages standard or $7 per 1,000 with proxies. 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. Track browser hours, Fetch and Search calls, Extract usage, proxy bandwidth, Model Gateway token spend, replay needs, retention requirements, and runner costs separately.