Is Browserbase Free? What You Actually Get

# Is Browserbase Free? What You Actually Get

"Is Browserbase free" is a question with a short answer and a long tail. The short answer: Browserbase offers a free tier, but like most hosted browser infrastructure, it's a trial allowance rather than a production plan. The long tail is where it gets interesting, because the real question behind the search is usually "can I run my agent on Browserbase without paying, and if not, what should I use instead?"

This post answers the direct question first, then walks through what free tiers in this category actually include, where they break down for production workloads, and how to evaluate any hosted browser runtime — including Remote Browser — on criteria that matter once you're past the prototype stage.

The Short Answer

Browserbase has a free tier. It gives you a limited number of browser hours and concurrent sessions so you can build and test. It is not designed to run production agent workloads indefinitely at no cost. If your question is "can I evaluate Browserbase for free," the answer is yes. If your question is "can I ship a production agent on Browserbase for free," the answer is no — and that's true of every serious hosted browser provider, not just Browserbase.

For current numbers, check Browserbase's own pricing page. Free-tier limits change, and any figure quoted in a blog post (including this one) goes stale. What doesn't go stale is the structure of the trade-off, which is what the rest of this post covers.

What "Free" Means in Hosted Browser Infrastructure

Hosted browser runtimes are not free to operate. Every session you open consumes a real Chromium process, CPU, memory, network egress, and often a proxy IP. A provider offering a free tier is subsidizing your evaluation in exchange for the chance to convert you into a paying customer. That shapes what free tiers include and what they deliberately exclude.

Typical free-tier structure across providers:

• A capped pool of browser hours. Usually enough for tens to a few dozen sessions, depending on session length.
• Low concurrency. Often one or two simultaneous sessions. This is the binding constraint for most agent workloads, more than total hours.
• Shared or datacenter IPs. Residential and mobile proxies are almost always paid.
• Short session timeouts. Free sessions often get killed after a few minutes of idle time.
• No persistent profiles or limited retention. State that survives across sessions is usually a paid feature.
• No SLA, no support commitment. Fine for evaluation, disqualifying for production.

None of this is a criticism. It's the economics of running someone else's Chrome for them.

Where Free Tiers Stop Being Enough

The transition point from "free is fine" to "I need to pay" is rarely about total hours. It's usually one of these:

Concurrency. An agent that processes a queue of tasks needs to run several sessions in parallel. Free tiers cap you at one or two. You can work around this with a queue and serial execution, but your throughput collapses and your wall-clock time explodes.

Session duration. Long-running agent tasks — multi-step form flows, authenticated dashboards, anything with human-in-the-loop pauses — need sessions that stay alive for minutes or hours. Free-tier timeouts kill them.

Persistent state. If your agent needs to stay logged in across runs, you need persistent profiles. That's typically a paid feature because it means the provider is storing your cookies and storage state on disk.

IP quality. The moment you hit a site that blocks datacenter IPs, you need residential or mobile proxies. Free tiers don't include them.

Reliability guarantees. Free tiers have no SLA. If your production agent depends on a browser session being available, you need a contract, not a free tier.

If you're still in the evaluation phase and none of these apply, a free tier is genuinely useful. If any of them apply, you're shopping for a paid plan and the question becomes "which one, and at what cost structure."

How Hosted Browser Pricing Actually Works

Most providers in this space meter on some combination of browser hours, sessions, and proxy traffic. The differences that matter:

The single most important line item for agent workloads is usually idle time. An agent that thinks for 30 seconds between actions is still holding a browser process. If you're billed for that, your effective cost per task is much higher than the headline rate suggests. Ask any provider how they handle idle sessions before you commit.

Remote Browser meters browser time and exposes usage controls so you can see where time is going. Current rates and free-tier details are on /pricing.

Evaluating a Hosted Runtime Beyond Price

Price is the easiest thing to compare and the least predictive of whether a runtime will work for you. Here's what actually determines fit:

CDP compatibility. If the runtime speaks the Chrome DevTools Protocol, you can drive it with Playwright, Puppeteer, or Selenium without a proprietary SDK. That's the difference between a runtime you can swap out and one you're locked into. See the Chrome DevTools Protocol documentation for the underlying interface.

Session isolation. Each agent task should get its own browser context. Shared state between tasks is a correctness bug waiting to happen.

Live viewer. Being able to watch a session in real time is the difference between debugging in five minutes and debugging for an hour. This matters more than most teams expect.

Persistent profiles. If your agent logs in, you need profile persistence. If it doesn't, you don't, and you shouldn't pay for it.

Configurable browser settings. User agent, viewport, timezone, locale, and proxy configuration should be settable per session. Be skeptical of vague claims about "stealth" — what matters is whether the specific settings you need are exposed.

Usage controls. You want to see browser-hours consumed per session and per project, and you want the ability to cap spend before it becomes a surprise.

For a deeper look at how these map to agent workloads, see Remote Browser for AI agents.

Connecting to a Hosted Browser with Playwright

The practical test of any hosted runtime is how much code it takes to connect. If it's CDP-compatible, it's a few lines. Here's a TypeScript example using Playwright's connectOverCDP:

import { chromium, Browser, BrowserContext, Page } from 'playwright';

interface SessionConfig {
  cdpUrl: string;
  userAgent?: string;
  viewport?: { width: number; height: number };
  timezone?: string;
}

async function runAgentTask(config: SessionConfig): Promise<string> {
  const browser: Browser = await chromium.connectOverCDP(config.cdpUrl);

  // Each task gets its own isolated context.
  const context: BrowserContext = await browser.newContext({
    userAgent: config.userAgent,
    viewport: config.viewport ?? { width: 1280, height: 800 },
    timezoneId: config.timezone,
  });

  const page: Page = await context.newPage();

  try {
    await page.goto('https://example.com/dashboard', {
      waitUntil: 'domcontentloaded',
      timeout: 30_000,
    });

    // Agent logic goes here: extract, click, fill, verify.
    const title = await page.title();

    return title;
  } finally {
    // Close the context, not the browser, if the session is reused.
    await context.close();
    await browser.close();
  }
}

runAgentTask({
  cdpUrl: process.env.REMOTE_BROWSER_CDP_URL!,
  viewport: { width: 1440, height: 900 },
  timezone: 'America/New_York',
}).catch(console.error);

Two things to note. First, connectOverCDP works against any CDP-compatible endpoint, which is why it's the right integration point — you're not writing provider-specific code. Second, closing the context rather than the browser matters if you're reusing sessions across tasks. Getting that wrong is a common source of leaked browser-hours.

If you're using Puppeteer instead, the equivalent is puppeteer.connect({ browserWSEndpoint }). Selenium connects via the remote WebDriver endpoint. The pattern is the same: point at a URL, get a browser.

Free Tier vs. Production: A Decision Framework

Use this to decide whether a free tier is sufficient for your current stage:

Stay on free if:

• You're evaluating whether hosted browsers solve your problem at all.
• You're running fewer than a few dozen sessions total.
• You don't need persistent login state.
• You can tolerate sessions being killed mid-task.
• You're not depending on it for anything a user sees.

Move to paid if:

• You need more than one or two concurrent sessions.
• Your tasks run longer than the free-tier timeout.
• You need persistent profiles or proxy IPs.
• You're running anything on a schedule or in response to user requests.
• You need to know your session will be there tomorrow.

The honest framing: free tiers are for answering "does this work." Paid plans are for answering "does this work reliably, at volume, without me babysitting it." Those are different questions and they have different price tags.

What to Do If Browserbase's Free Tier Isn't Enough

If you've hit the ceiling on Browserbase's free tier, you have three options:

1. Upgrade to a paid Browserbase plan. Reasonable if you're already invested in their SDK and tooling.
2. Move to a different hosted runtime. Worth doing if you want CDP-native integration, different pricing structure, or specific features Browserbase doesn't offer.
3. Self-host Playwright or Puppeteer. Cheapest on paper, most expensive in practice once you account for the infrastructure work — container orchestration, session cleanup, proxy management, and the on-call rotation when sessions leak.

Option 3 deserves a caveat. Self-hosting looks free because the compute is cheap. It stops looking free when you spend a week building session lifecycle management that a hosted runtime gives you out of the box. For a comparison of these paths, see Remote Browser online.

If you're evaluating Remote Browser specifically, the documentation covers CDP connection, session configuration, persistent profiles, and the live viewer. Pricing and any current free allowance are on /pricing — check there rather than trusting a number in a blog post.

Common Misconceptions

"Free tier means no limits for small projects." No. Free tiers have concurrency caps that bind long before total hours do.

"If it's free, it's not production-grade." Also no. Free tiers are usually the same infrastructure with tighter limits. The question is whether the limits fit your workload.

"I'll just self-host, it's basically free." The compute is cheap. The engineering time isn't. Price your own hours before deciding.

"Browserbase is the only option." It's one of several. The category includes Browserless, Steel, Hyperbrowser, and Remote Browser, among others. They differ on pricing model, CDP support, proxy options, and profile persistence. Compare on those axes, not on brand recognition.

Summary

Browserbase is free to start and not free to run in production. That's the normal shape of hosted browser infrastructure, and it's not a knock on Browserbase — it's how the economics work when every session is a real Chromium process consuming real resources.

The useful question isn't "is Browserbase free." It's "what does my workload actually need, and which runtime delivers it at a cost I can predict." Answer that, and the free-tier question answers itself.

If you want to test a CDP-compatible hosted runtime with Playwright or Puppeteer, start with the Remote Browser documentation and check /pricing for current limits.