Browserbase Kernel: Hosted Browser Runtimes Compared

# Browserbase Kernel: Hosted Browser Runtimes Compared

"Browserbase Kernel" is a search phrase that mixes two different products: Browserbase, a hosted browser platform for AI agents, and Kernel, a separate browser-infrastructure company that also runs cloud Chromium. People type it when they are trying to work out whether these are the same thing, which one to use, or how either fits next to a self-managed runtime. This post answers that directly, then walks through the production criteria that actually decide the choice: CDP compatibility, session lifecycle, profiles, proxies, observability, and cost model. If you are wiring an agent to a remote browser, the label on the vendor matters less than whether the runtime exposes a clean CDP endpoint and keeps sessions stable under load.

Browserbase and Kernel are not the same product

Browserbase is a managed browser API aimed at AI agents and automation teams. You create a session through an API, get back a CDP WebSocket URL, and drive it with Playwright, Puppeteer, or a framework like browser-use. It ships with a session viewer, persistent contexts, proxy options, and a hosted MCP server so agent frameworks can call browser tools without writing connection code.

Kernel is a separate company that provides cloud browser infrastructure, generally positioned around fast session startup and developer-facing APIs for running headless browsers at scale. It is not a Browserbase feature, module, or internal component. There is no "Browserbase Kernel" product you can install. The phrase is a conflation, and the practical question behind it is: *which hosted browser runtime should my agent talk to?*

That question has a real answer, but it depends on your stack rather than on brand preference. The rest of this post treats Browserbase, Kernel, and Remote Browser as peers in the same category — hosted Chromium behind CDP — and compares them on the things that break in production.

What a hosted browser runtime actually provides

Every product in this category sells the same core primitive: a real Chromium process on someone else's machine, reachable over the Chrome DevTools Protocol. The Chrome DevTools Protocol is the contract. If a runtime gives you a valid CDP WebSocket endpoint, Playwright's connectOverCDP and Puppeteer's connect work against it without vendor-specific SDKs.

What differs is everything around that endpoint:

• Session lifecycle. How sessions are created, how long they live, what happens on timeout, and whether you can reconnect to a running session after a worker restart.
• Profiles and state. Whether cookies, localStorage, and logged-in state persist across sessions, and whether profiles are isolated per tenant.
• Network controls. Proxy configuration, geographic targeting, and configurable browser settings that affect how the browser presents itself.
• Observability. Live viewer, session recordings, console and network logs, and the ability to attach a debugger mid-run.
• Concurrency and quotas. How many parallel browsers you can run and how that is metered.
• Egress and compliance. Where traffic originates, data retention, and whether the vendor offers SOC 2 or a DPA.

A runtime that is fast to start but drops sessions under load is worse than one that starts in two seconds and stays up. For agent workloads, session stability dominates raw startup latency because a failed mid-task session costs a full retry, not a few hundred milliseconds.

Comparing Browserbase, Kernel, and Remote Browser

The table below compares the three on dimensions that show up in production reviews. Specific prices and limits change frequently, so treat the pricing row as a pointer rather than a quote.

Two things are worth calling out. First, all three speak CDP, so migration between them is mostly a matter of swapping a connection URL and re-testing session semantics — not a rewrite. Second, none of them is a drop-in replacement for a self-hosted Playwright grid if you need full control over the Chromium build; if that is your requirement, look at self-hosted options instead.

If you want the broader category context before choosing, the remote browser guide for AI agents covers the runtime layer in more depth, and Remote Browser online explains what "running Chromium without local Chrome" actually means in practice.

Connecting an agent over CDP

The connection pattern is identical across vendors, which is the point. Here is a TypeScript example using Playwright against a hosted endpoint. The wsEndpoint is whatever your runtime returns from its session-creation call.

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

interface SessionInfo {
  wsEndpoint: string;
  sessionId: string;
}

async function runTask(session: SessionInfo): Promise<void> {
  let browser: Browser | undefined;
  try {
    // connectOverCDP attaches to an already-running Chromium.
    // No local browser download, no launch flags to manage.
    browser = await chromium.connectOverCDP(session.wsEndpoint, {
      timeout: 30_000,
    });

    // Hosted runtimes usually expose one default context per session.
    const contexts: BrowserContext[] = browser.contexts();
    const context =
      contexts.length > 0 ? contexts[0] : await browser.newContext();

    const page: Page = context.pages()[0] ?? (await context.newPage());

    await page.goto("https://example.com", {
      waitUntil: "domcontentloaded",
      timeout: 45_000,
    });

    const title = await page.title();
    console.log(`[${session.sessionId}] title=${title}`);

    // Keep the session alive only as long as the task needs it.
    await page.waitForTimeout(500);
  } catch (err) {
    console.error(`session ${session.sessionId} failed`, err);
    throw err;
  } finally {
    // Closing the CDP connection does not always terminate the remote
    // session; call the vendor's stop endpoint as well.
    await browser?.close();
  }
}

Three implementation notes that matter more than they look:

1. `connectOverCDP` does not launch a browser. It attaches. If the remote session has already timed out, you get a connection error, not a fresh browser. Always create the session immediately before connecting and keep the create-connect gap small.
2. `browser.close()` is not a guaranteed session kill. Most hosted runtimes meter by wall-clock session time, so explicitly stop the session through the API in your finally block. Otherwise you pay for idle browsers.
3. Contexts are pre-created. Calling newContext() on a CDP-attached browser can behave differently than on a launched browser. Prefer the existing context unless you have a reason to isolate.

The same pattern works for Puppeteer via puppeteer.connect({ browserWSEndpoint }). If you are comparing connection strategies, remote control of a browser covers the debugging and attach workflows in detail.

Production criteria that decide the choice

Brand comparisons are less useful than a checklist. Score each candidate against these before committing.

Session lifecycle and reconnection

Agents fail mid-task. The question is whether you can resume. Look for a runtime that lets you reconnect to a live session by ID after a worker crash, and that separates "connection closed" from "session terminated." If reconnection is not supported, design your agent to be idempotent at the task level, because every disconnect becomes a full retry.

Profile persistence and isolation

Persistent profiles are how agents stay logged in across runs. Two requirements: profiles must survive session termination, and they must be scoped so one tenant's cookies never leak into another's. Ask specifically whether profile storage is per-project and whether you can delete a profile on demand for compliance.

Network and browser configuration

Proxy support is table stakes. Beyond that, check whether the runtime lets you set a consistent user agent, locale, timezone, and viewport per session, and whether those settings persist across reconnects. "Configurable browser settings" is the honest framing here — treat any claim of automatic per-session identity changes with skepticism unless the vendor documents exactly what changes per session.

Observability

A live viewer is the difference between debugging an agent in five minutes and five hours. You want to watch the session in real time, pull console logs, and inspect network requests. Session recordings are useful for post-mortems and for regression suites that replay agent traces.

Concurrency and cost model

Concurrency limits determine whether your agent fleet can scale horizontally. Cost models split into subscription-plus-overage and pure usage-based. Neither is inherently better; subscription models reward predictable load, usage-based models reward spiky or experimental workloads. Run your expected browser-hours per month through both and compare — the crossover is usually obvious. Current Remote Browser rates are on the /pricing page.

Compliance and data handling

If you handle user data, you need to know where sessions run, how long logs are retained, and whether the vendor will sign a DPA. This is a procurement question, not a technical one, but it eliminates options early.

Where the "kernel" and "browserbase" keywords come from

Searches like *kernel browserbase*, *anchor browserbase*, and *browserbase fastest* reflect a real pattern: developers evaluating hosted browser vendors read comparison posts, see multiple names, and start conflating them. The honest answer is that these are competing products with overlapping primitives and different operational trade-offs.

A few related terms you will encounter while evaluating:

• Browserbase MCP and Hyperbrowser MCP refer to MCP servers that expose browser tools to agent frameworks. If your agent speaks MCP, check whether the runtime ships a maintained server and what tools it exposes — navigation, clicking, extraction, screenshots.
• Hyperbrowser price and Browserbase price are the two most common cost queries. Both vendors publish tiered pricing; compare effective cost per browser-hour at your actual concurrency, not at the entry tier.
• Self-host browserless refers to running Browserless or Steel yourself. That is a legitimate path if you have the ops capacity, but it moves session management, scaling, and Chromium patching onto your team.
• Open-source browser-use is the agent framework, not the runtime. It needs a browser to drive; hosted runtimes are one way to supply it.

The remote web browser overview ties these threads together if you want the full picture before shortlisting vendors.

A practical decision path

If you are choosing today, work through this sequence:

1. Confirm CDP compatibility. If the runtime does not expose a standard CDP WebSocket endpoint, cross it off. Vendor SDK lock-in is a migration tax you do not need.
2. Test session stability under your real load. Run a batch of your actual agent tasks at target concurrency for an hour. Measure session failures, not just latency.
3. Verify profile and proxy behavior against your hardest site. Logged-in flows and geo-restricted content expose gaps that synthetic benchmarks miss.
4. Check the viewer and logs. Open a session, break it deliberately, and see how long it takes to diagnose.
5. Model cost at your volume. Use published rates and your measured browser-hours per task.
6. Read the docs end to end. The /documentation page is a fair proxy for how much operational detail a vendor is willing to publish.

If you want a runtime that exposes CDP directly, supports Playwright, Puppeteer, and Selenium, and gives you a live viewer plus persistent profiles without a proprietary SDK, Remote Browser is built for exactly that workflow. Start with the documentation to see the session API and connection examples, then check /pricing for current rates and limits.

The short version: "Browserbase Kernel" is not a product. It is a sign that you are comparing hosted browser runtimes — and the right way to compare them is by CDP compatibility, session semantics, and measured stability on your own tasks, not by which name you saw first.