Agent-Browser Cloud Browser: Runtime Choices Compared

# Agent-Browser Cloud Browser: Runtime Choices Compared

An agent-browser cloud browser is the pairing of a CLI-driven agent harness with a hosted Chromium instance that runs somewhere other than your laptop or CI runner. The CLI decides what to do; the cloud browser executes it over the Chrome DevTools Protocol (CDP). Getting that split right is the difference between an agent that finishes tasks and one that stalls on a login wall, a memory leak, or a session that died mid-run.

This guide covers what the agent-browser pattern actually is, how hosted runtimes differ, and the production criteria that matter when you pick one. If you want the runtime layer explained first, start with remote browsers for AI agents.

What "agent-browser" means in practice

The term covers two things that are often conflated:

1. The agent-browser CLI — a command-line harness (the Vercel Labs agent-browser project is the common reference) that exposes browser actions as commands an LLM can call: navigate, click, type, extract, screenshot.
2. The browser it drives — a real Chromium instance. Locally that's a process on your machine. In production it's usually a hosted session reachable over a WebSocket CDP endpoint.

The CLI is stateless logic. The browser is stateful infrastructure. Most production failures come from the second half: sessions that time out, profiles that don't persist cookies, or a single machine trying to hold dozens of Chromium processes.

A cloud browser separates those concerns. The agent sends CDP commands; the provider handles process isolation, networking, and lifecycle. You get a wss:// endpoint instead of a local --remote-debugging-port.

How the connection works

Every hosted runtime in this space speaks CDP. Playwright's `connectOverCDP` and Puppeteer's connect({ browserWSEndpoint }) both accept a remote endpoint. The agent-browser CLI does the same under the hood.

import { chromium } from "playwright";

// Endpoint and token come from your runtime's session API.
const wsEndpoint = process.env.BROWSER_WS_ENDPOINT!;

const browser = await chromium.connectOverCDP(wsEndpoint, {
  timeout: 30_000,
});

// Reuse the default context so persistent profile state is respected.
const context = browser.contexts()[0] ?? (await browser.newContext());
const page = context.pages()[0] ?? (await context.newPage());

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

// Agent loop would inspect the page and decide the next action here.
const title = await page.title();
console.log({ title });

// Close the connection, not the remote browser, unless you own its lifecycle.
await browser.close();

Two details trip people up. First, browser.close() on a CDP connection detaches your client; whether it terminates the remote session depends on the provider's API. Second, if you create a new context instead of reusing the default one, you may bypass the persistent profile the runtime provisioned. Check both against your provider's docs before you build retry logic around them.

What a hosted runtime actually provides

A cloud browser is more than a remote Chrome binary. The pieces that matter in production:

• Session isolation — each agent run gets its own browser process and storage, so cookies and local storage don't leak between tenants or tasks.
• Persistent profiles — saved logins and cookies survive across sessions, which is what makes authenticated workflows repeatable.
• Live viewer — a real-time view of the session for debugging. When an agent loops on a selector, you want to see the page, not read a stack trace.
• Proxy and network settings — configurable egress, including residential options where the provider supports them. IP quality affects success rates on sites with bot detection.
• Usage controls — concurrency limits and metering so a runaway agent loop doesn't burn your budget overnight.

Remote Browser exposes these as part of its runtime: hosted Chromium sessions, CDP access, Playwright/Puppeteer/Selenium compatibility, a live viewer, persistent profiles, configurable browser settings, and per-session isolation. Current limits and pricing live on the pricing page.

Comparing runtime options

The market splits into three buckets: hosted commercial runtimes, self-hosted open-source servers, and local Chromium. Each is correct for a different stage.

The comparison that matters for most teams is hosted versus self-hosted. Self-hosting Browserless or Steel is a reasonable choice if you already run Kubernetes, have a platform team, and your volume justifies the fixed cost. It stops being reasonable when you're spending engineering weeks on session cleanup, zombie Chromium processes, and managing outbound IPs instead of on the agent itself.

For a deeper look at the hosted side, see remote browser online and remote web browser.

Production criteria to evaluate

Ignore headline benchmark scores until you've checked these. They determine whether a runtime survives contact with real workloads.

1. Session lifecycle and timeouts

How long can a session live? What happens at the limit — graceful close, or a hard kill mid-action? Can you extend a session? Agents that wait on slow third-party flows need predictable answers here. Ask for the default idle timeout and the maximum session duration, and test both.

2. Profile persistence semantics

Does the profile persist cookies, localStorage, and IndexedDB? Is it keyed per agent, per user, or per session? Can two concurrent sessions share a profile safely, or does that cause lock contention? If your agent logs into a customer's account, this is the most important question on the list.

3. Concurrency and queueing

What happens when you request more sessions than your plan allows — immediate error, or queue? How is concurrency counted: per account, per project, per API key? This shapes your retry and backoff design. Don't assume there's no ceiling on parallelism; design for a limit and read the current numbers on /pricing.

4. Network and proxy controls

Can you set a proxy per session? Which regions are available? Is traffic logged, and for how long? For regulated workloads, zero-retention options and a signed DPA matter more than latency.

5. Observability

Live viewer, session recordings, and CDP-level logs. When an agent fails at step 14 of 20, you need the DOM state at that moment. A runtime without a viewer turns every failure into a reproduction exercise.

6. Compatibility surface

Does it work with the libraries you already use — Playwright, Puppeteer, Selenium, Stagehand, or a browser-use agent? CDP is the common denominator, but session creation, profile attachment, and teardown differ per provider. Budget a day to wire your framework against the real API before committing.

Where the agent-browser CLI fits

The CLI is the part you control. Keep it thin: it should translate model output into CDP actions and return structured observations (accessibility tree, screenshot, extracted text). Keep the browser remote and the CLI stateless so you can run it in a Lambda, a container, or a queue worker without changes.

A practical pattern:

• One session per task. Don't multiplex unrelated tasks into one browser; isolation is cheaper than debugging cross-contamination.
• Persistent profile per user or account. Reuse it across tasks so logins survive.
• Explicit teardown. Close the session when the task ends, including on error paths. Orphaned sessions are the most common source of surprise bills.
• Viewer link in logs. Log the live viewer URL alongside the session ID so failures are one click from diagnosis.

For the CLI and runtime split in more depth, see remote control browser and the documentation.

Common failure modes and fixes

Agent loops on a selector. Usually a page that renders differently for the session's IP or user agent. Check the viewer, then check proxy settings.

Login doesn't persist. The agent created a fresh context instead of reusing the provisioned one, or the profile wasn't attached to the session. Verify with a cookie dump after goto.

Session dies mid-run. Idle timeout or max duration hit. Add keepalives if the provider supports them, or split long tasks into shorter sessions with profile handoff.

Costs spike. Parallel agents retrying failed steps. Cap retries, close sessions in finally blocks, and monitor session count, not just task count.

Different results locally vs. in the cloud. Headless rendering, viewport size, fonts, and timezone all differ. Pin viewport and locale in your context options.

Choosing between hosted and self-hosted

Pick hosted if: you're shipping an agent product in weeks, you don't have a platform team, you need profiles and a viewer out of the box, or your volume is variable.

Pick self-hosted if: you have strict data-residency requirements you can satisfy in your own VPC, your volume is high and steady enough to justify fixed infrastructure, or you need to customize the Chromium build.

Pick local if: you're prototyping, running a handful of tests, or debugging a single flow.

Most teams end up hosted for production and local for development, with the same CDP-based code path in both. That's the point of standardizing on CDP: the runtime becomes swappable.

Getting started

1. Read the documentation for session creation and CDP endpoint format.
2. Wire your agent-browser CLI or Playwright script to connectOverCDP.
3. Run one authenticated workflow end to end with the viewer open.
4. Add teardown, retry caps, and session logging.
5. Check pricing against your expected browser-hours before scaling concurrency.

The runtime is infrastructure. Treat it like infrastructure: measure it, cap it, and keep the agent logic portable so you can change providers without rewriting the agent.