Browserbase Pricing Explained 2026: Practical Cost Guide

Why Browserbase Pricing Needs a Closer Look (Refreshed 2026)

Browser automation platforms look similar on the surface: managed headless browsers, concurrency controls, and optional proxies. The real differences show up in how they meter time, sessions, and network.

Browserbase pricing uses a mix of plan tiers and metered browser hours. That makes it flexible, but also easy to under‑ or over‑buy if you don’t map your workloads to their pricing model.

This guide walks through:

• How plans, browser hours, and concurrency typically interact
• Where per‑session pricing shines vs pure pay‑as‑you‑go
• How three common workloads price out on Browserbase vs Human Browser and one other provider
• How to think about free tiers, overage, and proxy add‑ons for real‑world agent workloads

Where exact public numbers aren’t available, this article focuses on structure and trade‑offs, not guesses.

If you’re building agents as described in the Browserbase docs — “agents that browse and interact with the web like humans” — you should also read the cluster piece on AI agent browser automation for broader architecture choices.

---

How Browserbase Prices Workloads Conceptually

The published numbers, as shown on browserbase.com/pricing when this guide was checked on 15 September 2026:

• Free — $0/mo, 1 browser hour, 3 concurrent browsers, no proxy included.
• Developer — $20/mo, 100 browser hours included, then $0.12 per browser hour; 25 concurrent browsers; proxies $12/GB.
• Startup — $99/mo, 500 browser hours included, then $0.10 per browser hour; 100 concurrent browsers; proxies $10/GB.
• Scale — custom pricing, 500+ hours and 250+ concurrent browsers, usage-based proxies.

Prices change; treat the table above as a snapshot and the worked examples below as the method, not the invoice.

Browserbase describes itself as “the complete platform to build and deploy agents that browse and interact with the web like humans” with:

• Fleets of headless browsers at scale
• Agent Identity to get past anti‑bot systems and auth walls
• Functions running code next to the browser
• Model Gateway and Stagehand for AI‑native agents

Pricing for that stack is typically structured around three levers:

1. Plan tier (Free / Developer / Startup / Scale)
2. Browser time (hours or minutes of headless sessions)
3. Concurrency (how many browsers you can run at once)

Even without their public price grid in front of you, those three dimensions drive your bill.

Plan Tiers: Free, Hobby, Startup, Scale

Most users will enter through one of these tiers:

• Free – small monthly cap on browser time and concurrency. Useful for experiments and POCs.
• Developer – more browser time, a bit more concurrency. Good for lightweight side‑projects.
• Startup – higher caps and better concurrency. Targets smaller teams running real workloads.
• Scale – significantly higher concurrency and browser time pools, often with negotiated terms.

Across tiers, you typically get:

• Included browser hours (pooled quota)
• A maximum concurrency value (hard or soft limit)
• Access to the same core APIs (Browsers, Functions, Model Gateway, etc.)

The key trade‑off is:

> Higher tier = more included browser time and concurrency, but you pay even if you don’t fully use it.

A small workload can be cheaper on a lower tier, even if your per‑hour rate is slightly higher, as long as you don’t hit concurrency walls.

Browser Time: The Real Meter

Every time your agent opens a headless browser via Browserbase, you’re spending browser time.

Simplified mental model:

• Start a session → meter begins
• Interact / navigate / fetch → time keeps running
• Close or timeout → meter stops

For cost planning, think in minutes per task:

• A simple scrape (load page, extract HTML/JSON, close) might be 15–60 seconds
• A JS‑heavy login sequence or checkout flow can be several minutes
• A full‑day monitoring job can be hours on a single session

On pre‑paid plans, these minutes are consumed from your included quota. Beyond the quota you typically pay overage per browser hour at a published rate.

Concurrency: Headroom vs. Cost

Concurrency caps how many browsers you can run simultaneously. You can still run many more total sessions per day as long as you respect the cap.

Example mental picture:

• Concurrency = 5
• Each session = 2 minutes
• You can process ~150 sessions/hour (5 at a time × 30 batches per hour), assuming continuous work

Concurrency is not billable time by itself, but it heavily determines whether a lower tier works for you:

• Low concurrency, modest hours – fine for bursty or low‑volume tasks
• High concurrency, similar hours – needed when you want low latency (finish many tasks quickly)

If your process isn’t latency‑sensitive, you can often stay on a smaller tier and just queue work.

---

Where Browserbase’s Per‑Session Model Wins

Browserbase’s platform focus (agents, identity, model gateway, functions) means you’re mostly paying for managed complexity, not just raw browser minutes.

Scenarios where that model is attractive:

1. You need Agent Identity and anti‑bot partnerships baked in.

• Getting past Cloudflare, Fingerprint‑style device checks, and auth walls is non‑trivial to DIY.

1. You want observability and replay built in.

• Live view and step‑by‑step logs make debugging agents much faster than tailing Playwright logs.

1. You’re using Stagehand or the Model Gateway.

• If your agents rely on natural‑language selectors and a single model endpoint, the platform benefits can outweigh any pure browser‑minute savings elsewhere.

1. You prefer predictable, pooled browser hours.

• Pre‑allocated browser time on a startup/scale plan can be easier to budget than purely metered per‑minute billing.

When comparing to more bare‑bones browser APIs, mentally assign value to:

• Integrated anti‑bot capabilities
• A unified API and bill across browsers, functions, and models
• Tooling that reduces your engineering hours spent debugging agents

If those save you significant developer time, a slightly higher nominal cost per browser hour can still be a net win.

---

Human Browser: Pure Pay‑As‑You‑Go Alternative

Human Browser — pay as you go, no subscription is a thinner, more focused product:

• Pay‑as‑you‑go at $0.10/hr of browser time
• $4/GB for residential proxy traffic
• $0.005 per CAPTCHA
• Agent steps at $0.02, AI included (median AI cost $0.006 per customer task in production, Sep 2026)
• No subscriptions, no expiry on unused balance
• 75 selectable residential countries

You can install it into your stack via npm or API:

npm install humanbrowser

More details are at /install.

Compared to Browserbase’s plan structure, Human Browser is straightforward:

• No tiers or included quotas
• No plan tiers for concurrency: up to 10 concurrent sessions per paid token, more on request
• You pay exactly for agent steps, browser time, GBs, and CAPTCHAs consumed

That model is attractive when:

• You have spiky workloads (e.g., occasional heavy scrapes)
• You don’t want any monthly minimum commit
• You want to experiment across many small projects without negotiating a plan change each time

---

Another Reference Point: Pricing Structure on a Similar Provider

To keep this realistic, it’s useful to benchmark one more player (e.g., Browserless or Steel‑style provider). Their pricing generally falls into one of these molds:

• Request‑based – fixed price per browser run or per thousand runs
• Time‑based – charge per second or minute of execution
• Hybrid – small base fee plus time or request overage

Most will also:

• Offer a free or very cheap developer tier
• Cap concurrency per plan
• Sell additional residential proxy bandwidth or rely on your proxies

The important point: the structural trade‑offs are the same. You’re still balancing:

• Fixed plan cost vs. variable usage
• Concurrency vs. latency
• Integrated features vs. owning more of the stack yourself

---

Worked Example 1: 100 Simple Scrapes/Day

Assumptions:

• Each scrape:
• 1 page load
• 30 seconds of browser time
• No CAPTCHA, minimal JS
• 100 scrapes per day → ~50 minutes/day, ~25 browser hours/month
• Concurrency needs are low (<= 3)

On Browserbase

This is the sort of workload a hobby or startup tier can usually handle:

• Plan with ~25–50 included browser hours/month
• Concurrency limit of 3–5 browsers

If you stay under the included hours, your effective cost is just the plan fee. Even if per‑hour overage exists, you’ll rarely hit it.

Design implications:

• Batch your scrapes to stay within concurrency limits
• Use timeouts and early exits to avoid idle browser time

On Human Browser

At $0.10/hr:

• 25 hours × $0.10 = $2.50 of browser time (sessions under 30 seconds are not billed at all)
• The agent decides each step at $0.02, AI included: at about 2 steps per scrape, 3,000 scrapes a month is about $120

If you use residential proxies for all traffic at $4/GB, you’d add whatever your pages consume in total GBs (often modest for simple HTML pages).

You skip plan fees, but most of that bill is agent steps. For a stable, scripted scrape like this you do not need an agent deciding each step, so a Browserbase tier driven by your own code is cheaper.

On a Third Provider

With a request‑based provider, assume:

• Price per 1000 runs
• Light usage of 3000 runs/month (100/day × 30)

Your monthly bill is straightforward as long as you don’t exceed concurrency caps. This can be cheaper than time‑based pricing when each task is very short.

Summary: 100 Scrapes/Day

---

Worked Example 2: 20 Agent Sessions/Day

Assumptions:

• Each session is an AI agent driving the browser
• 10 minutes of continuous interaction on average
• 20 sessions/day → ~200 min/day → ~100 hours/month
• Occasional CAPTCHAs and logged‑in flows

This is closer to the type of workload Browserbase is designed for.

On Browserbase

A startup or scale tier is a likely match:

• Included browser hours in the 100+ range
• Concurrency knobs to match how many agents you run in parallel
• Direct integration with Stagehand and Model Gateway if you use them

You also benefit from:

• Agent Identity for anti‑bot systems
• Functions with low latency to run your agent logic near the browser
• Observability and replays for debugging agent behavior

If your monthly usage is reasonably stable, this can be very cost‑effective compared to raw per‑minute metering.

On Human Browser

At $0.10/hr:

• 100 hours × $0.10 = $10 for browser time
• Agent steps at $0.02, AI included: our median customer task is about 8 steps for 4.5 minutes, so a 10‑minute session is roughly 15–20 steps, and 600 sessions a month is about $180–240

Add:

• CAPTCHAs at $0.005 each
• Residential proxy traffic at $4/GB as needed

You’re paying precisely for what you consume. For projects that ramp up and down, or if you’re still tuning how long each agent runs, this can be safer than committing to a higher tier elsewhere.

On a Third Provider

Time‑based, per‑second pricing can also work here, but you’ll need to build more yourself:

• Anti‑bot handling via your own proxy/residential stack
• Observability via your own logging and tracing
• AI integration through separate model providers

Your raw browser time might cost less or more depending on their rate, but engineering complexity will be higher.

Summary: 20 Agent Sessions/Day

---

Worked Example 3: One 8‑Hour Monitoring Session

Assumptions:

• A single browser session runs for 8 hours continuously
• It monitors a dashboard or runs a spider with long polling
• Minimal concurrency (1–2)
• No heavy residential proxy bandwidth

On Browserbase

This single job consumes 8 browser hours from your plan’s quota.

Key points:

• If you’re already on a tier with ample included hours, the marginal cost is near‑zero.
• Continuous sessions benefit from Browserbase’s observability and replays if anything breaks mid‑run.

You mostly care that your plan’s concurrency is at least 1–2, which all but the smallest tiers cover.

On Human Browser

At $0.10/hr:

• 8 hours × $0.10 = $0.80 of browser time
• Plus $0.02 for each agent step; a monitor that only acts when something changes takes few steps

If this is a one‑off monitoring task, no plan, no negotiation — you just run it.

This is exactly the sort of spiky, low‑frequency workload where pay‑as‑you‑go tends to win on simplicity.

On a Third Provider

For a pure time‑metered provider:

• You pay for 8 hours at their per‑second or per‑minute rate
• No special benefits beyond whatever observability they provide

If they charge per request, and your monitoring does frequent refreshes, a time‑based provider or Browserbase‑style plan is usually simpler to reason about.

Summary: One 8‑Hour Session

---

Mapping Your Workload to a Pricing Model

When deciding between Browserbase, Human Browser, and a similar provider, focus on four questions:

1. Is your workload spiky or steady?

• Spiky, unpredictable jobs → pay‑as‑you‑go (Human Browser or similar) is easier to stomach.
• Steady, predictable workloads → tiered plans with included browser hours can be cheaper.

1. How many minutes of browser time per month?

• Do a quick back‑of‑the‑envelope:
• sessions_per_day × minutes_per_session × 30 → total minutes
• Compare that against any published browser‑hour quotas and per‑minute rates.

1. How much concurrency do you actually need?

• Latency‑sensitive scraping (e.g., needing 1000 pages in < 5 minutes) demands higher concurrency.
• Overnight or background tasks can often run at low concurrency and still finish on time.

1. Do you need identity, AI agents, and observability in one place?

• If yes, a platform like Browserbase with Agent Identity and Stagehand reduces glue code.
• If no, and you already have your own anti‑bot/proxy stack, a thinner Browser API plus Human Browser‑style metering can be more cost‑efficient.

For deeper design guidance on AI agents running browsers, including when and how to introduce a dedicated browser platform, see the cluster article on AI agent browser automation.

---

Practical Tips to Keep Bills Predictable

Some low‑effort engineering changes dramatically affect cost regardless of provider.

1. Cap Session Duration in Code

Don’t rely on platform‑side timeouts; enforce your own.

// Example: Node.js pseudo-code using a generic browser client
async function runScrapeWithTimeout(client, maxMinutes = 2) {
  const controller = new AbortController();
  const timeout = setTimeout(() => controller.abort(), maxMinutes * 60_000);

  try {
    const session = await client.startSession({ signal: controller.signal });
    await session.goto('https://target.example');
    const data = await session.evaluate(() => {
      // scrape page contents
      return {
        title: document.title,
        items: Array.from(document.querySelectorAll('.item')).map(e => e.textContent?.trim()),
      };
    });
    return data;
  } finally {
    clearTimeout(timeout);
    await client.closeSession().catch(() => {});
  }
}

This pattern ensures you don’t accidentally leave sessions open and burn hours.

2. Normalize Workloads Before Comparing Providers

When doing cost comparisons, fix the following:

• Same number of sessions
• Same average minutes per session
• Same proxy type (residential vs. datacenter)
• Similar retry / backoff strategies

This avoids “cheaper” numbers that quietly assume fewer retries or weaker anti‑bot handling.

3. Use Concurrency Wisely

• If you’re I/O bound, increasing concurrency can reduce total browser time by completing jobs faster.
• If your target site rate‑limits aggressively, too much concurrency leads to bans, retries, and higher effective costs.

Start with conservative concurrency, observe behavior, then scale up until you hit either:

• Platform concurrency ceilings, or
• Unacceptable error/ban rates

4. Log Browser Time Per Task

Instrument your system to track:

• started_at / ended_at timestamps per session
• Number of navigation steps
• CAPTCHAs solved

Then compute real cost per job under each provider’s model. This is the only reliable way to choose between per‑session, per‑minute, and request‑based pricing.

---

When to Choose Which Provider in 2026

A concise decision rule of thumb for 2026:

• Choose Browserbase when:
• You want an integrated agent platform: browsers, identity, functions, model gateway, and Stagehand
• You value built‑in observability and replay for every agent step
• You’re comfortable with a plan‑tier model and your workloads are relatively stable

• Choose Human Browser when:
• You want pure pay‑as‑you‑go with no subscription and no expiry on balance
• You have varying workloads and don’t want to manage plan upgrades/downgrades
• You already have opinions about models, orchestration frameworks, and don’t need an all‑in‑one agent platform

• Choose a third provider when:
• You have extremely predictable, templated jobs where request‑based pricing shines
• You’re fine piecing together anti‑bot and AI integrations from separate tools

Browser automation costs scale faster than most teams expect. Getting clear on minutes, concurrency, and features per workload matters more than small differences in list price.