Browser Use vs Hosted Runtimes: What Actually Differs

# Browser Use vs Hosted Runtimes: What Actually Differs

"Browser use vs" is usually shorthand for one question: should an AI agent drive a browser through a library like browser-use, or through a hosted browser runtime that exposes Chromium over CDP? The honest answer is that these are not the same category of thing. Browser-use is an agent framework — it decides what to click and why. A hosted runtime is infrastructure — it decides where the browser lives, how long it survives, and who can watch it. Most production stacks need both, and the real decision is where the boundary sits. This guide breaks down the trade-offs, the lifecycle questions that decide whether an agent works at scale, and the criteria worth checking before you commit.

What "browser use" actually refers to

The term gets used three ways, and conflating them causes bad architecture decisions:

1. The browser-use library — an open-source Python project that wraps Playwright and gives an LLM a structured action space (click, type, scroll, extract). It is the *agent logic* layer.
2. Browser Use Cloud — the hosted offering from the same team, which sells managed browsers plus an agent API. It is a *runtime* layer with an opinionated agent on top.
3. "Browser use" as a verb — any agent that operates a real browser, regardless of framework.

When someone searches "browser use vs Browserbase" or "browser use vs hosted Chromium," they are usually comparing layer 1 against layer 2 or 3. That comparison only makes sense if you separate the framework from the runtime.

The framework's job: translate a task into a sequence of browser actions, handle model calls, manage retries and observation. The runtime's job: launch Chromium, keep it alive, isolate it, route its traffic, expose a debugging endpoint, and bill for the time it exists.

You can run the browser-use library against a local Chrome. You can also run it against a remote browser over CDP. The library does not care. That is the key insight.

The lifecycle question that decides everything

The single most useful lens for browser use vs hosted runtimes is session lifecycle. Ask these questions in order:

• Who launches the browser? In local browser-use, your process spawns Chrome. In a hosted runtime, an API call provisions a session and returns a connection URL.
• How long does it live? A local Chrome dies with your script. A hosted session has an explicit lifetime you control — you can keep it open across multiple agent turns, or tear it down immediately.
• What survives a crash? If your agent process OOMs mid-task, a local browser is gone. A hosted session can outlive the worker that created it, so a replacement worker can reconnect and continue.
• Who can observe it? Local Chrome is invisible unless you attach a debugger. Hosted runtimes typically ship a live viewer, which matters enormously when an agent gets stuck on step 14 of 20.
• How is it isolated? Two concurrent local Chromes on one machine share a filesystem, a network namespace, and often a profile directory. Hosted sessions are isolated per session by design.

These are not abstract concerns. They are the difference between a demo and a system that runs unattended. If your agent only ever runs one task at a time on your laptop, local browser-use is fine. The moment you need concurrency, retries, or human inspection, lifecycle becomes the dominant cost.

Comparison: local browser-use vs hosted runtime

The table is deliberately not a scorecard. Local browser-use wins on latency-to-first-action and on cost when you already have idle hardware. Hosted runtimes win on everything that becomes a problem after the first week.

Where the framework boundary should sit

A common mistake is treating the hosted runtime as a replacement for the agent framework. It is not. The runtime gives you a browser; something still has to decide what to do with it.

Two clean architectures:

Framework-owned loop. The browser-use library (or your own loop) runs in your worker, connects to a hosted browser over CDP, and drives it. You keep full control of prompting, tool definitions, and retry logic. The runtime is a dumb, reliable browser.

Runtime-owned agent. You call a hosted agent API with a natural-language task and get a result back. You trade control for less code. This is convenient but couples your product to someone else's agent loop, model choices, and failure semantics.

For most teams building a product, the first architecture ages better. You can swap models, change the action space, and add domain-specific tools without renegotiating your infrastructure. The runtime stays a commodity; the agent logic stays yours.

If you want the longer argument for why the runtime layer deserves to be separate, see Remote browsers for AI agents.

Connecting browser-use to a hosted browser

The mechanics are unglamorous: you get a WebSocket debugger URL and pass it to Playwright's connectOverCDP. The browser-use library sits on top of Playwright, so the same connection works.

import { chromium } from "playwright";

// Your runtime returns a CDP endpoint for a freshly provisioned session.
const cdpEndpoint = process.env.BROWSER_CDP_URL!;

const browser = await chromium.connectOverCDP(cdpEndpoint);

// Reuse the existing context so cookies and storage from the session persist.
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" });

// Hand `page` to your agent loop. Each action is a normal Playwright call.
await page.getByRole("button", { name: "Export" }).click();

// Do not close the browser here if the session should outlive this worker.
// Disconnect and let the runtime manage teardown.
await browser.close();

Two details matter in production. First, browser.close() on a CDP connection disconnects your client; whether it terminates the remote session depends on the runtime, so read the docs before relying on it. Second, reconnect logic should be idempotent — a worker that restarts should be able to reattach to the same session rather than starting a new task from scratch.

The Playwright documentation on connecting over CDP covers the connection semantics, including the Chromium-only constraint.

Production criteria worth checking

When you evaluate a hosted runtime — whether it is browser-use's cloud, Browserbase, Browserless, Steel, Kernel, Hyperbrowser, or Anchor — these are the questions that separate usable from painful:

• CDP fidelity. Can you use the full Playwright and Puppeteer surface, or only a subset? Some runtimes proxy a limited command set.
• Session reconnection. Can a second worker attach to a live session? This is what makes long-running agents survivable.
• Profile persistence. Do cookies and local storage survive across sessions when you need them to, and are they scoped per tenant?
• Network controls. Are proxies, geolocation, and timezone configurable per session? "Configurable browser settings" is the honest phrasing; be skeptical of any claim you cannot verify in the docs.
• Observability. Is there a live viewer and a way to inspect the DOM and console of a running session?
• Teardown guarantees. What happens to a session when the client disconnects? Orphaned sessions are a silent cost.
• Pricing model. Per browser-hour, per task, or per credit — and whether idle time is billed. Check /pricing for current terms rather than trusting a blog post, including this one.

The lifecycle questions from earlier map directly onto this list. A runtime that cannot reconnect is a runtime that cannot run long tasks. A runtime without a viewer is a runtime where debugging means guessing.

When local browser-use is the right call

Be fair to the local path. It is genuinely better when:

• You are prototyping and want zero network latency between agent and browser.
• Your workload is a single task on a machine you already own.
• You need to inspect the browser interactively with devtools attached.
• You are running offline or in an air-gapped environment.

The failure mode is not that local browser-use is bad. It is that teams scale it by adding more machines and more Chrome installs, then discover they have built a browser fleet without the tooling a browser fleet needs — no viewer, no reconnection, no isolation guarantees, no usage accounting.

A pragmatic migration path

If you are on local browser-use today and expect to grow, the lowest-risk path is:

1. Keep your agent loop exactly as it is.
2. Replace chromium.launch() with chromium.connectOverCDP(endpoint).
3. Move session creation and teardown into a small service that calls the runtime API.
4. Add a reconnection path keyed by session ID so workers are stateless.
5. Wire the live viewer into your internal tooling before you need it at 2 a.m.

Step 2 is a one-line change. Steps 3 and 4 are where the real work lives, and they are the same work you would do for any hosted runtime. The framework choice — browser-use, a custom loop, or something else — stays orthogonal.

For a walkthrough of running Chromium without local setup, see Remote browser online. For the control-plane side — driving sessions from anywhere — see Remote control browser.

Bottom line

Browser use vs hosted runtimes is a false binary. Browser-use is how your agent decides; a hosted runtime is where the browser lives. The decision that actually matters is where you draw the lifecycle boundary: who launches the browser, how long it survives, who can watch it, and what happens when a worker dies. Draw that boundary deliberately, keep the agent loop yours, and treat the runtime as replaceable infrastructure. The full API surface, including CDP access, persistent profiles, and session controls, is documented at /documentation.