Browser-Use Product: What to Evaluate Before You Ship

# Browser-Use Product: What to Evaluate Before You Ship

A browser-use product is two things sold as one: an agent layer that turns a model's intent into browser actions, and a runtime layer that actually hosts the Chromium instance those actions run against. Most teams evaluate the first and discover the second only after their first production incident. This guide separates the two, explains what each layer must provide, and gives you a checklist for comparing options — including hosted runtimes like Remote Browser that you connect to over CDP rather than adopt wholesale.

The short version: the agent library is swappable. The runtime is where reliability, cost, and compliance live. Evaluate the runtime first.

What a browser-use product actually contains

The name comes from the open-source browser-use project, which pairs an LLM with a browser automation driver so an agent can click, type, scroll, and extract without hand-written selectors. That project is the agent layer. It needs a browser to drive, and that browser can be local, self-hosted, or hosted.

A complete browser-use product typically ships:

• An agent loop — prompt → observation → action → new observation, with DOM or accessibility-tree extraction feeding the model.
• A browser driver — usually Playwright or Puppeteer underneath, speaking CDP to Chromium.
• A hosted runtime — cloud Chromium sessions, often with stealth settings, proxies, and persistent profiles.
• Operational tooling — a live viewer, session recordings, logs, and usage metering.

Vendors bundle these differently. Some sell the agent and the browser together as a single managed service. Others sell only the runtime and expect you to bring your own agent code. Both are legitimate; they fail in different ways.

The bundling trade-off

A tightly bundled product is fast to start. You install one SDK, pass an API key, and a task runs end to end. The cost is coupling: when the agent's prompting strategy doesn't fit your domain, or when you need a specific model, you're constrained by what the vendor exposes.

A runtime-only product is more work up front — you write the agent loop yourself or use an open-source one — but you keep control of the model, the prompts, the retry logic, and the evaluation harness. For teams that already have an agent framework, this is usually the better fit. Remote Browser sits in this category: hosted Chromium, CDP access, Playwright/Puppeteer/Selenium compatibility, and a live viewer, with the agent layer left to you.

The runtime criteria that decide production success

Agent quality gets all the attention, but most production failures trace back to the browser environment. Here is what to check.

Session isolation and lifecycle

Every agent task should get its own browser context. If two tasks share cookies or localStorage, one agent's login can corrupt another's cart, and debugging becomes guesswork. Confirm that sessions are isolated by default and that you can explicitly opt into shared state via persistent profiles when you need it.

Lifecycle matters too. You need deterministic session creation, a way to detect a dead session, and a clean teardown that doesn't leak browser-hours. Ask how the runtime handles a session that hangs mid-task — does it time out, and who pays for the idle time?

CDP access and driver compatibility

If the runtime exposes a CDP endpoint, you can drive it with Playwright, Puppeteer, or Selenium without a proprietary SDK. That portability is worth a lot: it means your test suite, your local dev loop, and your production runtime all speak the same protocol.

If the runtime only exposes a custom API, you're locked in. That may be fine, but price the exit before you commit.

Persistent profiles and authentication

Real tasks involve logged-in sessions. A runtime needs a way to save and restore browser state — cookies, localStorage, IndexedDB — so an agent doesn't re-authenticate on every run. Check whether profiles are scoped per user, per task, or per tenant, and how you revoke them.

Network and browser settings

Proxies, geolocation, timezone, locale, and user-agent are all configurable browser settings that affect whether a site treats your agent as a normal visitor. Be precise about what you need. "Stealth" is a marketing word; the concrete questions are: can I set a residential proxy per session, can I pin the timezone and locale, and can I control the user agent string?

Observability

A live viewer is table stakes. You also want session recordings or logs you can replay after a failure, and enough metadata to correlate a failed task with the exact browser session that produced it. Without this, agent debugging is archaeology.

Comparing browser-use product shapes

The table below compares the three common shapes you'll encounter. It is a framework, not a ranking — the right choice depends on your team and workload.

The middle column is where most production teams land once they've outgrown a prototype. You keep your agent code, and you rent the part that's genuinely hard to operate well: a fleet of isolated Chromium instances with proxies, profiles, and a viewer.

Connecting a browser-use workflow to a hosted runtime

The integration is a CDP connection. If you're using Playwright, you call connectOverCDP with the WebSocket endpoint the runtime hands you. The Playwright CDP documentation covers the API surface; the important production detail is that you're attaching to an existing browser, not launching one.

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

interface SessionInfo {
  cdpUrl: string; // wss://... from the runtime's session-create call
  sessionId: string;
}

async function runTask(session: SessionInfo, task: (page: Page) => Promise<void>) {
  let browser: Browser | undefined;

  try {
    browser = await chromium.connectOverCDP(session.cdpUrl, {
      timeout: 30_000,
    });

    // A hosted session usually starts with one context; reuse it so
    // cookies and storage from the profile are available to the agent.
    const context = browser.contexts()[0] ?? (await browser.newContext());
    const page = context.pages()[0] ?? (await context.newPage());

    page.setDefaultTimeout(20_000);
    await task(page);
  } catch (err) {
    // Log the session ID so you can pull the recording or live viewer.
    console.error(`task failed in session ${session.sessionId}`, err);
    throw err;
  } finally {
    // Disconnect without closing the remote browser unless you own its lifecycle.
    await browser?.close();
  }
}

Two things to get right. First, browser.close() on a CDP connection disconnects your client; whether it also terminates the remote session depends on the runtime, so check the docs and make teardown explicit. Second, set timeouts at the page level and at the session level — an agent that waits forever on a selector burns browser-hours.

If you're wiring this up for the first time, the remote browser for AI agents walkthrough covers the session-create call and endpoint handling in more detail.

Where browser-use products break in production

The failure modes are predictable. Watch for these.

Unbounded retries. An agent that retries a failed click five times, each with a fresh page load, can consume an order of magnitude more browser time than a successful run. Cap retries and treat repeated failures as a signal to escalate, not to loop.

Shared state across tenants. If profiles aren't scoped correctly, one customer's session can leak into another's. This is a security issue, not just a bug.

Silent session death. A session that dies mid-task without a clear error leaves your orchestrator waiting. Use heartbeats or a session-status endpoint.

Cost drift. Browser-hours accumulate quietly. Metering per session and per task, with alerts, is the only way to keep spend predictable. See /pricing for how Remote Browser meters usage.

Model-driven flakiness. The same task can succeed or fail depending on the model's interpretation of the page. Build an evaluation set of real tasks and run it against every prompt or model change.

A practical evaluation checklist

Before you commit to any browser-use product, run this list against it:

• Can I drive the browser over CDP with Playwright or Puppeteer, or am I locked into a proprietary SDK?
• Are sessions isolated by default, and can I opt into persistent profiles deliberately?
• Can I configure proxies, timezone, locale, and user agent per session?
• Is there a live viewer, and can I replay a failed session?
• How is usage metered, and can I set spend limits?
• What happens to a session that hangs — timeout, billing, and cleanup?
• Can I export my agent code and move to another runtime without a rewrite?

If the answer to the first and last questions is yes, you've preserved your exit. That matters more than any single feature.

Choosing between a bundled product and a runtime

Pick a bundled agent-plus-runtime product when you're validating a use case and the vendor's agent loop fits your domain. The speed is real, and you can migrate later if the CDP endpoint is exposed.

Pick a runtime-only product when you already have agent code, when you need a specific model or prompting strategy, or when compliance requires you to control the browser environment precisely. Remote Browser is built for this case: hosted Chromium sessions with CDP access, Playwright/Puppeteer/Selenium compatibility, a live viewer, persistent profiles, configurable browser settings, session isolation, and usage controls. The documentation covers session creation and connection; the remote browser online guide is a good starting point if you want to see a session running before you write code.

Whichever shape you choose, evaluate the runtime first. The agent layer is code you can change. The runtime is infrastructure you'll live with.