Five Cloud Browser Runtimes Compared for AI Agents

# Five Cloud Browser Runtimes Compared for AI Agents

A five cloud browser shortlist usually starts with the same names: Browserbase, Kernel, Hyperbrowser, Anchor, and whatever you can self-host. The problem is that these products are not interchangeable. They differ in how you connect (CDP endpoint vs. SDK), what you pay for (browser-hours vs. sessions vs. seats), and how much of the runtime you still have to operate yourself.

This guide compares five cloud browser options on the criteria that actually decide production outcomes: connection model, session lifecycle, pricing shape, and operational burden. It also covers where a hosted runtime like Remote Browser fits, and how to wire one up over CDP with Playwright in a few lines of TypeScript.

What a cloud browser actually is

A cloud browser is a real Chromium instance running on someone else's servers, exposed to your code through an API and a remote debugging endpoint. You create a session, connect over the Chrome DevTools Protocol, drive it with Playwright, Puppeteer, Selenium, or an agent framework, and tear it down when the task finishes.

That definition matters because it separates two categories that get conflated in marketing:

• Browser infrastructure — you bring your own agent or script; the provider supplies Chromium, networking, and session management.
• Agent products — the provider supplies the agent loop as well as the browser, and you configure tasks rather than code.

Most teams evaluating a five cloud browser list are in the first category. They already have a Playwright script or a browser-use agent and need somewhere reliable to run it.

The five options at a glance

Two caveats before you read too much into the table. First, pricing changes; check each vendor's page and /pricing rather than trusting a comparison table from any blog, including this one. Second, "self-host" is a spectrum — Browserless and Steel are the usual picks if you want to run Chromium yourself, and that decision is covered separately below.

Criterion 1: How you connect

Every serious cloud browser exposes CDP. The differences are in the details.

Browserbase gives you a session ID and a connect URL; you call chromium.connectOverCDP() or use their SDK. It also ships an MCP server, so agent frameworks that speak MCP can drive sessions without custom glue code.

Kernel exposes CDP endpoints and a REST API for session management. It is often cited for fast session startup, which matters if your workload creates and destroys browsers per task rather than holding long-lived sessions.

Hyperbrowser follows the same pattern — CDP plus an SDK — with additional higher-level endpoints for scraping and structured extraction. If you want the provider to do more than host Chromium, that is the trade-off.

Anchor is the stealth-focused option in this list. Its pitch centers on residential IP quality and getting through bot detection, which is a real production concern for agents that hit consumer sites.

Remote Browser keeps the surface deliberately thin: create a session, get a CDP WebSocket endpoint, connect with the library you already use. There is no proprietary agent layer to learn. Sessions include a live viewer for debugging, persistent profiles for logged-in state, and configurable browser settings for proxy and stealth-related behavior.

The practical test: can you point your existing connectOverCDP call at the provider's endpoint and have it work without rewriting your automation? If not, the SDK is doing more than hosting a browser, and you should decide whether that is a feature or lock-in.

Criterion 2: Session lifecycle and state

Production agents fail in boring ways: a session dies mid-task, a login is lost between runs, or two workers collide on the same profile. How a provider handles session state is more important than raw speed.

Questions to ask each vendor:

• Can sessions persist across worker restarts? If your agent runs on serverless functions with short timeouts, you need to reconnect to the same browser rather than start over.
• Are profiles persistent? Logged-in state, cookies, and local storage are what make multi-step workflows viable. Without persistent profiles, every run pays the login tax.
• Is there a live view? When an agent gets stuck on a CAPTCHA or an unexpected modal, a live viewer turns a 40-minute log-reading session into a 40-second look.
• How is isolation enforced? Sessions should not share cookies or storage unless you explicitly want them to.

Remote Browser's model is one isolated Chromium session per task, with optional persistent profiles when you need continuity. The live viewer is available per session, which is the single biggest debugging accelerator in agent work — see /blog/remote-browser-for-ai-agents for how that plays out in agent loops.

Criterion 3: Pricing shape

Cloud browser pricing falls into three shapes, and they are not comparable at face value:

1. Subscription with included hours. A monthly fee buys concurrency and a browser-hour allowance, with overage billed per hour. Browserbase's published plans follow this pattern. The trap is paying for concurrency you do not use during off-peak hours.
2. Pure usage-based. You pay per browser-hour, no commitment. This favors bursty workloads and early-stage products where volume is unpredictable.
3. Per-seat or per-task. Less common for infrastructure, but appears in agent products where the unit of value is a completed task rather than a browser.

Two things to check regardless of shape:

• What counts as a browser-hour? Idle sessions that stay open while your agent thinks still bill. Session timeouts and explicit teardown matter.
• What happens at concurrency limits? A queue that silently drops requests is worse than a clear 429.

Remote Browser bills on usage; current rates and limits are on /pricing. Do not budget from blog posts — including this one — because every vendor in this space has changed pricing at least once.

Criterion 4: Operational burden

The hidden cost of any cloud browser is the code you write around it: retry logic, session cleanup, IP management, and monitoring. Compare providers on how much of that they absorb.

• Managed session APIs handle creation and teardown, but you still own retries.
• Built-in stealth and proxies reduce the amount of detection-handling code you write, at the cost of less control over IP selection.
• Recordings and logs determine how fast you can debug a failed run at 2 a.m.

If you want to own all of this, self-hosting Browserless or Steel is a legitimate choice. The trade-off is real: you get full control over Chromium flags and networking, and you take on patching, scaling, and the on-call rotation. For teams without dedicated infrastructure engineers, that cost usually exceeds the per-hour savings.

Connecting to a cloud browser with Playwright and CDP

The connection code is nearly identical across providers, which is the point. Here is the pattern using Playwright's connectOverCDP against a Remote Browser session endpoint:

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

interface SessionResponse {
  id: string;
  cdpUrl: string; // wss://... provided by the runtime
}

async function runTask(): Promise<void> {
  // 1. Create a session via the runtime's API.
  const res = await fetch("https://api.remote-browser.dev/v1/sessions", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      Authorization: `Bearer ${process.env.REMOTE_BROWSER_API_KEY}`,
    },
    body: JSON.stringify({
      // Optional: reuse a persistent profile for logged-in state.
      profileId: process.env.PROFILE_ID,
      // Optional: configurable browser settings for proxy/stealth behavior.
      proxy: { country: "us" },
    }),
  });

  if (!res.ok) throw new Error(`Session create failed: ${res.status}`);
  const session: SessionResponse = await res.json();

  let browser: Browser | undefined;
  try {
    // 2. Attach over CDP. No local Chromium download required.
    browser = await chromium.connectOverCDP(session.cdpUrl);
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page: Page = context.pages()[0] ?? (await context.newPage());

    await page.goto("https://example.com", { waitUntil: "domcontentloaded" });
    const title = await page.title();
    console.log("Page title:", title);

    // 3. Your agent or automation logic goes here.
  } finally {
    // 4. Always release the session; idle browsers still bill.
    await browser?.close();
    await fetch(`https://api.remote-browser.dev/v1/sessions/${session.id}`, {
      method: "DELETE",
      headers: { Authorization: `Bearer ${process.env.REMOTE_BROWSER_API_KEY}` },
    });
  }
}

runTask().catch((err) => {
  console.error(err);
  process.exit(1);
});

Three details worth noting. connectOverCDP returns a browser whose existing context you should reuse rather than creating a new one — the runtime may have already configured it. The finally block is not optional; orphaned sessions are the most common source of surprise bills. And the endpoint shape above is illustrative — check /documentation for the exact request and response fields your account uses.

The same pattern works with Puppeteer's puppeteer.connect({ browserWSEndpoint }) and with Selenium's remote WebDriver if you are migrating an older test suite. The CDP endpoint is the stable contract; the SDK is convenience.

Where Remote Browser fits

Remote Browser is not trying to be an agent product. It is a hosted Chromium runtime with a CDP endpoint, a live viewer, persistent profiles, session isolation, and usage controls. That positioning is deliberate: if you already run browser-use, Stagehand, Playwright, or a custom agent loop, you want the browser to be boring infrastructure, not another framework to learn.

It is a reasonable fit when:

• Your automation already speaks CDP and you want to stop managing Chromium fleets.
• You need to debug agent runs visually rather than through logs.
• You want persistent profiles for logged-in workflows without building your own storage layer.
• You want usage-based billing without a monthly concurrency commitment.

It is a weaker fit when you need the provider to supply the agent itself, or when you have infrastructure engineers who want to tune Chromium at the flag level and are happy to own the pager.

How to run the evaluation

Do not pick from a comparison table. Run the same workload against two or three providers:

1. Pick a representative task — one that logs in, navigates three or four pages, and extracts structured data.
2. Measure session startup and teardown separately from task time. Startup dominates short tasks.
3. Break something on purpose. Kill a session mid-run and see how fast you can diagnose it with the provider's tooling.
4. Run it for a week and look at the bill. Idle sessions and retries show up there, not in benchmarks.
5. Read the connection docs, not the landing page. If the CDP setup is buried or SDK-only, that tells you something about the product's center of gravity.

For background on the runtime layer itself, /blog/remote-web-browser and /blog/remote-control-browser cover the architecture and control model in more depth.

The five cloud browser options above are all viable. The right one is the one whose connection model matches your existing code, whose pricing shape matches your traffic, and whose debugging tools match how your team actually works.