TL;DR
The pricing model is hybrid: a monthly plan includes browser hours and API quotas, then overages are metered by browser hour, Search calls, Fetch calls, Extract calls, proxy bandwidth, and model tokens.
As of June 2026, the public plans are Free, Developer at $20 per month, Startup at $99 per month, and custom Scale. The right comparison is not just "plan price vs plan price." You need to model browser hours, proxy GB, and whether your workflow also needs a separate extraction layer.
Browserbase provides browser infrastructure for AI agents and automation workflows. It is useful when your application needs to open real browser sessions, execute JavaScript, keep session state, debug flows, or run Playwright-style actions at scale.
If you are evaluating browserbase pricing, the important question is not "what is the cheapest plan?" The real question is "how many browser hours, proxy GB, API calls, and model tokens will my workflow burn?"
This guide breaks down the plans, explains the meters, shows where costs climb, and compares Browserbase with ScrapeGraphAI when your main job is structured data extraction rather than browser control.
Browserbase Pricing Plans in 2026
Browserbase lists four public plan families on its pricing page:
| Plan | Monthly price | Best for | Main point |
|---|---|---|---|
| Free | $0 | Prototypes and testing | Small browser-hour and API quotas |
| Developer | $20 | Building real workflows | More browser hours and concurrency |
| Startup | $99 | Early production usage | Higher included usage and lower overages |
| Scale | Custom | High-volume teams | Negotiated quotas, compliance, and support |
Browserbase's billing docs also describe overage rates by plan. Developer overages include browser hours around $0.12 per hour, proxy bandwidth around $12 per GB, Fetch API overages around $1 per 1,000 calls without proxies and $4 per 1,000 with proxies, Extract API overages around $4 per 1,000 calls without proxies and $7 per 1,000 with proxies, and Search API overages around $7 per 1,000 searches. Startup generally lowers some rates, including browser-hour and proxy GB overages.
Those numbers can change, so confirm the current rates on Browserbase's pricing and billing docs before committing budget.
How Browserbase Billing Works
Browserbase is not billed like a simple scraper API. It has several meters because it exposes several layers of browser-agent infrastructure.
Browser hours. This is the core meter. If your agent keeps browser sessions alive while it waits, clicks, retries, or watches pages load, you pay in browser time. A workflow that spends 30 seconds per page has a very different cost profile than one that spends 5 minutes per session.
Concurrency. Plans include different browser concurrency limits. If you need many simultaneous sessions, the plan tier may matter more than the base included hours.
Fetch API calls. Browserbase Fetch is a lighter HTTP-style endpoint. It is useful for basic requests, but it does not replace full browser sessions for JavaScript-heavy sites. Calls can be cheaper than browser sessions, but proxy-enabled Fetch costs more.
Search API calls. Search is metered per 1,000 calls after included quota. This matters when the agent discovers targets on the fly instead of receiving a fixed URL list.
Extract API calls. Browserbase includes extraction capabilities, but Extract has its own overage meter. If your workflow extracts structured data from many pages, model this separately from browser hours.
Proxy bandwidth. Proxy GB is one of the easiest lines to underestimate. Heavy pages, images, scripts, and regional targeting can turn a small job into a proxy-heavy job.
Model tokens. Browser-agent workflows often involve LLM calls for decisions, extraction, or reasoning. Browserbase may bundle some model tokens, but serious usage should include model costs in the forecast.
Cost Examples
Here is a simple way to estimate Browserbase costs before building:
- Count how many browser sessions you run per month.
- Estimate average session duration.
- Multiply sessions by duration to get browser hours.
- Estimate proxy bandwidth for pages that require proxy routing.
- Add Search, Fetch, and Extract overages.
- Add LLM model token cost if your agent reasons over page state.
Example: 10,000 Product Pages
Suppose you need data from 10,000 product pages.
If every page needs a browser session and each session takes 30 seconds, that is about 83 browser hours. A Developer plan with 100 included browser hours might cover the browser time, but only if you do not exceed other included quotas.
If the same job needs proxy routing and each page transfers enough assets to create several GB of bandwidth, proxy costs become the important line. If the workflow also calls Extract for each page, you need to add Extract API usage.
If your real need is only "extract product name, price, availability, and reviews from known URLs," you may not need to own the browser session layer at all. An AI extraction API can be simpler to forecast.
Example: 1,000 Agent Research Tasks
Research tasks are different. They involve search, clicking, waiting, reading, and sometimes backtracking. A single task might keep a browser alive for several minutes.
At 1,000 tasks per month with an average 3-minute browser session, you are already at 50 browser hours before retries. If each task also calls Search and Extract, those meters join the bill.
This is the kind of agentic workflow Browserbase is built for. Just do not compare it to a page-level scraper as if both products meter the same thing.
Hidden Cost Drivers
1. Idle browser time
An agent that waits for pages, human approvals, CAPTCHAs, or slow network responses keeps consuming browser time. Browser time is often more important than page count.
2. Proxy bandwidth
Proxy costs are bandwidth-based. Pages with large scripts, images, videos, or analytics payloads consume more than pages with plain HTML. If the target needs proxy routing, measure bandwidth early.
3. Multi-step agent loops
Agents retry. They click the wrong thing. They search again. They inspect pages that turn out irrelevant. That is normal, but every extra loop adds browser time and API calls.
4. Extraction on top of browsing
Getting a page open is not the same as getting clean data. If you still need structured extraction after navigation, include Extract API or external LLM costs.
5. Debug and retention needs
Replay, logs, and session history are valuable for production browser agents. Higher retention and support requirements can push teams toward bigger plans.
How to Keep Browserbase Costs Predictable
Start with a short production-shaped test, not a perfect spreadsheet. Run 100 real sessions against the same sites, countries, and proxy settings you expect in production. Record average session length, p95 session length, proxy GB, failed sessions, and Extract or Search calls per successful result.
Then model the bill from successful outcomes, not attempts. If 100 requested pages produce 82 usable rows after retries, your cost per usable row is higher than the plan table suggests. Put that number next to the engineering cost of maintaining Playwright code, proxy rules, and extraction prompts.
The fastest way to control spend is to shorten sessions. Close browsers as soon as the needed state is captured, block nonessential assets when safe, avoid agent loops for fixed URL lists, and route static pages through lighter fetch or extraction workflows.
Browserbase vs ScrapeGraphAI
Browserbase and ScrapeGraphAI solve adjacent problems.
Choose Browserbase when you need browser control. Choose ScrapeGraphAI when you need structured data from web pages with minimal scraper code.
| Need | Browserbase | ScrapeGraphAI |
|---|---|---|
| Run browser sessions | Yes | Abstracted away |
| Control clicks and form flows | Yes | Not the main interface |
| Debug browser replays | Yes | No |
| Extract structured JSON from a prompt | Available through extraction workflows | Native core workflow |
| Forecast cost by known URL volume | Harder, depends on browser time and bandwidth | Easier, based on credits per call |
| Avoid writing selectors | With agent or extraction layer | Yes |
| Best fit | Browser automation and web agents | Data extraction pipelines |
Use Browserbase when the workflow is interaction-first: login flows, product QA, testing, agent browsing, session replay, or UI automation.
Use ScrapeGraphAI when the workflow is data-first: extract fields from product pages, enrich leads, monitor competitor prices, parse documentation, or convert pages into structured JSON.
Many teams can use both. Browserbase can handle a login or browser-only step, then ScrapeGraphAI can extract the data fields from target pages.
Browserbase Pricing Compared with Alternatives
If Browserbase looks expensive or too browser-centric for your use case, compare it with these alternatives:
ScrapeGraphAI. Best when you do not need direct browser control and want structured JSON or Markdown from URLs. Cost forecasting is based on credits and call volume rather than session time.
Bright Data. Best for enterprise proxy-heavy scraping, web unlocker workflows, and difficult targets. Costs can rise through proxy bandwidth and product-specific meters. Read the Bright Data alternatives guide if you are comparing enterprise scraping platforms.
Apify. Best for scheduled scraping, marketplace Actors, and broad automation. Cost depends on compute units, proxies, storage, and sometimes actor rental fees. See the Apify pricing breakdown.
ScrapingBee or ScraperAPI. Best when you want rendered HTML and proxy rotation through a simple API. You still need your own parsing and extraction layer. For raw HTML economics, compare ScraperAPI pricing.
Self-hosted Playwright. Best if you have DevOps capacity and want full control. It trades vendor cost for engineering, monitoring, proxy, and scaling work.
When Browserbase Is Worth It
The spend makes sense when browser control is the product requirement.
Choose Browserbase when:
- You need real browser sessions, not just page content
- Your workflow includes clicks, forms, logins, or multi-step navigation
- You need session replay and debugging for production agents
- You want managed browser infrastructure instead of self-hosted Playwright
- Browser time is predictable enough to forecast
The fit is weaker when:
- You only need structured data from known URLs
- You do not care about browser session control
- Proxy bandwidth is unpredictable
- Your team wants a simple per-call extraction cost
- You already know the fields you need from each page
FAQ
How much does Browserbase cost?
As of June 2026, Browserbase lists a Free plan, Developer at $20 per month, Startup at $99 per month, and custom Scale pricing. Usage overages can include browser hours, proxy GB, Fetch calls, Search calls, Extract calls, and model tokens. Check the official Browserbase pricing page before purchasing.
What is a Browserbase browser hour?
A browser hour measures how long Browserbase browser sessions run. A 30-minute session consumes 0.5 browser hours. A thousand 30-second sessions consume about 8.3 browser hours.
Why can Browserbase pricing be hard to forecast?
Browserbase has multiple meters. Browser time, proxy bandwidth, Search calls, Fetch calls, Extract calls, and model tokens can all matter. Agentic workflows also retry and branch, which makes usage less predictable than a fixed URL extraction job.
Is Browserbase cheaper than ScrapeGraphAI?
It depends on the job. Browserbase is the better fit when you need browser automation. ScrapeGraphAI is usually easier to forecast when you need structured data extraction from known URLs, because the cost maps to API call volume rather than browser session time.