Browserbase Plans: What Each Tier Includes and How to Choose

# Browserbase Plans: What Each Tier Includes and How to Choose

Browserbase plans are tiered subscriptions that bundle a concurrency ceiling, a monthly pool of browser-hours, and a per-hour overage rate. The free tier exists to prove a prototype; the paid tiers exist to raise concurrency. If you are evaluating Browserbase plans for a production agent, the number that matters most is not the monthly price — it is the concurrency limit, because that is what caps how many agents can run at once. This guide breaks down what each tier actually buys, where the cost curve bends, and how to decide whether a subscription model fits your workload or whether metered per-hour billing is a better match.

What a Browserbase plan actually contains

Every Browserbase tier is built from the same three variables. Understanding them separately makes the plan comparison much clearer than a price table alone.

• Concurrency. The maximum number of simultaneous browser sessions your account can run. This is a hard ceiling, not a soft target. If your agent fleet needs 40 parallel sessions and your plan allows 25, the extra 15 wait.
• Included browser-hours. A monthly allowance of session time. One browser-hour is one session running for one hour; ten sessions running for six minutes each is also one browser-hour.
• Overage rate. The per-hour price once you exceed the included allowance. This is where the effective cost of a plan diverges from its sticker price.

There is also a fourth variable that rarely appears in the headline table but matters in production: what happens when you hit the concurrency limit. Some platforms queue the request, some return an error, and some let you burst. Check this before you design a retry strategy around it.

The published tiers, as of late 2026, look roughly like this:

Treat those numbers as a snapshot. Vendors adjust tiers, and the only authoritative source is the vendor's own pricing page. The structural point is what matters: price scales with concurrency, and overage scales with usage. A plan is cheap if your concurrency need is low and your hours are high; it is expensive if you need many parallel sessions for short bursts.

The concurrency-to-hours ratio is the real decision

Most teams pick a plan by looking at the monthly price and the included hours. That is the wrong order. Start with concurrency, because it determines whether the plan can run your workload at all.

Consider two workloads that both consume 400 browser-hours a month:

Workload A — batch scraping. 200 short sessions, each running about 6 minutes, spread across a few hours each night. Peak concurrency might be 20. This fits comfortably inside the Developer tier's 25-session ceiling, and 400 hours exceeds the 100-hour allowance, so you pay roughly 300 hours of overage.

Workload B — a live agent fleet. 50 agents running continuously during business hours. Peak concurrency is 50, which exceeds Developer's 25 and requires Startup. Total hours might be lower than Workload A, but the concurrency requirement forces the higher tier.

Same hours, different plans, because concurrency is the binding constraint. Before you compare prices, measure your peak concurrent sessions over a representative week. If you do not have that number yet, instrument your session creation calls and log timestamps — you cannot size a plan without it.

Where subscription pricing helps and where it hurts

The subscription model has a genuine advantage: predictable billing. If your workload is steady, a fixed monthly cost plus a known overage rate is easy to budget and easy to forecast. Finance teams like it, and so do engineering managers who need a number for the quarterly plan.

The disadvantage appears when your workload is spiky or early-stage. Three patterns are worth calling out:

Prototype-to-production gap. The free tier's 3 concurrent sessions and 1 browser-hour are enough to validate that your agent can drive a browser. They are not enough to run a load test, and they are nowhere near enough to benchmark task success across a few hundred sites. You will hit the paid tier quickly, and the jump from 3 to 25 concurrent sessions is a real cost step.

Idle concurrency. If you pay for 100 concurrent sessions but average 15, you are paying for headroom you do not use most of the month. That is fine if the spikes are business-critical and unpredictable. It is wasteful if the spikes are a twice-a-month batch job you could schedule differently.

Overage surprises. Included hours run out. When they do, the overage rate applies, and a runaway agent loop that leaves sessions open can burn through hours fast. Session timeouts and explicit session termination in your code are not optional at this stage.

Metered billing as an alternative shape

A different model exists: pay per browser-hour with no subscription and no concurrency tier. Remote Browser runs on this model — you create sessions, you are billed for the time they run, and the current rates and limits live on the pricing page. The trade-off is straightforward.

Metered billing wins when your workload is variable, when you are still discovering your concurrency profile, or when you want cost to track usage exactly rather than approximately. It loses when you need a hard concurrency guarantee written into a contract, or when your finance team insists on a flat monthly line item.

Neither model is universally better. The question is whether your peak concurrency is predictable enough to buy in advance. If it is, a subscription can be cheaper per hour at high volume. If it is not, metered billing removes the risk of paying for idle capacity.

What to verify beyond the price table

Plan comparison pages tend to list price, concurrency, and hours. Production teams need to check a longer list before committing. These are the items that cause migrations six months in:

• CDP access. Can you connect Playwright, Puppeteer, or Selenium directly over the Chrome DevTools Protocol? If the platform only exposes a proprietary SDK, you are locked into their abstraction. Remote Browser exposes standard CDP endpoints, so existing Playwright and CDP code works without a rewrite.
• Persistent profiles. Does the plan include saved browser state — cookies, localStorage, logged-in sessions — that survives across sessions? This is often gated by tier.
• Proxy and network settings. Proxy configuration, geographic routing, and per-session network settings are frequently tier-dependent or billed separately.
• Live viewing and debugging. Can you watch a session in real time and inspect it when an agent fails? This matters more than it sounds; debugging a failed agent run without a viewer is slow.
• Session isolation. Are sessions isolated from each other at the process or container level? Shared state between sessions is a correctness bug waiting to happen.
• Data retention. What happens to session recordings, logs, and profile data, and for how long?
• Compliance. SOC 2, HIPAA, DPAs, and zero-data-retention options are usually enterprise-tier features. If you need them, the self-serve tiers will not carry you.

If you are comparing Browserbase against other hosted runtimes, the remote browser overview covers the runtime-level differences that pricing pages omit.

Wiring an agent to a hosted session

Regardless of which plan you choose, the integration pattern is the same: request a session, get a CDP WebSocket endpoint, connect your automation library, run the task, close the session. The closing step is where money leaks, so make it explicit.

import { chromium } from "playwright";

interface SessionResponse {
  id: string;
  cdpUrl: string;
}

async function runTask(url: string) {
  // Create a session via your provider's API.
  const res = await fetch(`${process.env.BROWSER_API_URL}/sessions`, {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.BROWSER_API_KEY}`,
    },
    body: JSON.stringify({ timeoutSeconds: 300 }),
  });
  if (!res.ok) throw new Error(`session create failed: ${res.status}`);

  const session: SessionResponse = await res.json();
  const browser = await chromium.connectOverCDP(session.cdpUrl);

  try {
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page = await context.newPage();
    await page.goto(url, { waitUntil: "domcontentloaded" });
    // ... agent logic ...
    return await page.title();
  } finally {
    // Always close the browser connection and the remote session.
    await browser.close();
    await fetch(`${process.env.BROWSER_API_URL}/sessions/${session.id}`, {
      method: "DELETE",
      headers: { Authorization: `Bearer ${process.env.BROWSER_API_KEY}` },
    });
  }
}

Two details in that snippet are worth emphasizing. First, connectOverCDP is the standard Playwright entry point for remote Chromium — see the Playwright CDP documentation for the full option set. Second, the finally block closes both the browser connection and the remote session. Closing the connection alone does not always terminate the remote session on every provider; check your provider's semantics and make the explicit delete call if it is required. A leaked session is a billed session.

For teams that need to drive sessions interactively during development, a remote control browser workflow — attaching to a live session from your local machine — shortens the debug loop considerably.

A practical decision sequence

If you are choosing between Browserbase plans or between Browserbase and a metered alternative, work through these steps in order:

1. Measure peak concurrency. Log session start and end timestamps for a representative week of real or simulated traffic. Take the 95th percentile, not the average.
2. Measure total browser-hours. Multiply sessions by average duration. Add a 20–30% buffer for retries and failed runs.
3. Check the concurrency ceiling against step 1. If your peak exceeds the tier, move up or reconsider the model.
4. Compute effective cost. For a subscription, that is monthly price plus overage on hours beyond the allowance. For metered billing, it is hours times the per-hour rate. Compare the two at your measured numbers, not at the vendor's example numbers.
5. Verify the production features. CDP access, persistent profiles, proxies, live viewer, isolation, retention. A cheaper plan that lacks persistent profiles will cost you more in engineering time than it saves in billing.
6. Revisit quarterly. Agent workloads change shape as you add tasks. A plan that fit at launch may not fit three months later.

The most common mistake is choosing a plan by monthly price and discovering the concurrency ceiling during a load test. The second most common is ignoring overage until the first invoice with a runaway session on it. Both are avoidable with a week of measurement and a session timeout.

Summary

Browserbase plans trade a fixed monthly fee for a concurrency ceiling and a browser-hour allowance, with overage billed per hour beyond that. The free tier validates a prototype; the paid tiers buy concurrency, and concurrency is the constraint that decides whether a plan can run your workload at all. Subscription pricing rewards steady, predictable demand and penalizes spiky or early-stage usage. Metered per-hour billing — the model Remote Browser uses, with current rates on the pricing page — removes the idle-capacity risk and tracks cost to actual usage.

Whichever model you pick, the engineering checklist is the same: measure peak concurrency before you buy, confirm CDP access and persistent profiles are included at your tier, and make session termination explicit in code. Those three habits will save more money than any plan comparison table.