Browser Use vs Agent Browser: Which Runtime Fits Production?

# Browser Use vs Agent Browser: Which Runtime Fits Production?

"Browser use" and "agent browser" get used interchangeably in AI automation circles, but they describe different layers of the same stack. Browser use is the task pattern: an LLM-driven agent reads a page, decides what to click, and iterates until a goal is met. Agent browser is the execution surface: the Chromium instance, CDP endpoint, and session lifecycle that the agent drives. Confusing the two leads to bad architecture decisions — teams pick a library when they actually need a runtime, or they rent a browser when a local script would do. This comparison breaks down where each term applies, how the tooling overlaps, and what to check before you put either into production.

What "Browser Use" Actually Means

Browser use describes a class of AI workload. Instead of writing brittle selectors against a known DOM, you give a model a goal ("find the invoice for order 4412 and download the PDF") and let it navigate. The agent observes the page — usually via accessibility tree, screenshot, or extracted DOM — reasons about the next action, executes it through a browser control layer, and repeats.

The term is also a proper noun. Browser Use is a specific open-source project and hosted service that popularized this pattern, with its own Python library, CLI, and cloud offering. When someone says "browser use free" or "browser use production examples," they usually mean that project specifically.

The pattern itself is broader than any one library. You can build browser-use-style agents on top of Playwright, Puppeteer, Selenium, or a raw CDP client. What defines the category is the loop: observe → reason → act → verify.

Where browser use breaks down

The failure modes are consistent across implementations:

• Non-determinism. The same task can take different paths on different runs. That's fine for exploration, expensive for anything you bill against.
• Token cost per step. Every observation round-trip costs model tokens. Long flows on heavy pages get expensive fast.
• Session fragility. Local Chrome dies when the machine sleeps, the container restarts, or memory pressure kills the process. Mid-task state loss is the most common production complaint.
• Detection. Headless Chromium on a datacenter IP gets flagged by many sites. The agent then reasons about a CAPTCHA or a block page instead of the actual task.

None of these are solved by picking a better agent framework. They're runtime problems.

What "Agent Browser" Actually Means

An agent browser is the browser instance an agent controls. In practice that means three things bundled together:

1. A Chromium process running somewhere — your laptop, a container, or a hosted runtime.
2. A control protocol — almost always CDP (Chrome DevTools Protocol), sometimes wrapped by Playwright or Puppeteer.
3. A session lifecycle — creation, connection, persistence, teardown, and whatever state survives between steps.

The term shows up in tool names too. agent-browser is a CLI from Vercel Labs for driving browsers from AI agents. It's a client. It still needs a browser to connect to.

This is the distinction that matters: browser use is the agent's behavior; agent browser is the infrastructure that behavior runs on. You can swap agent frameworks without touching your browser runtime. You cannot swap runtimes without rethinking session management, proxy config, and connection handling.

Browser Use vs Agent Browser: Side-by-Side

The two columns aren't competitors. They're layers. A production stack has both, and the runtime layer is usually the one that determines whether the agent layer works reliably.

Where the Tools Overlap

The confusion is understandable because several projects span both layers.

Browser Use ships an agent framework *and* a hosted browser service. The library handles reasoning; the hosted service handles the browser. You can use either independently.

agent-browser is a CLI that wraps browser control for agents. It connects to a browser — local or remote — and exposes commands an agent can call. It's the client half of the stack.

Playwright and Puppeteer are browser control libraries. They're not agent frameworks, but most agent frameworks use them under the hood. When you see "browser use Playwright" in a search query, that's the overlap being asked about.

Hosted runtimes like Remote Browser provide the browser itself: a Chromium session reachable over CDP, with profiles, proxies, and a live viewer. The agent framework connects to it the same way it would connect to a local Chrome.

If you're evaluating a stack, ask which layer each component owns. Most integration pain comes from a component silently trying to own two layers.

Production Criteria for the Runtime Layer

If you're moving browser-use agents from a notebook to something that runs on a schedule, these are the criteria that actually matter. They're all runtime concerns.

Session persistence and profiles

Agents that log in, then log in again on the next run, waste steps and trip rate limits. Persistent profiles let cookies, localStorage, and auth state survive across sessions. Check whether your runtime supports named profiles and how long they persist.

Connection stability over CDP

A dropped WebSocket mid-task is worse than a failed start — you've paid for the reasoning steps and lost the state. Look for runtimes that handle reconnection, expose session health, and don't silently recycle browsers under you.

Proxy and network configuration

IP reputation determines whether your agent sees the real page or a block page. Configurable proxy settings — including residential egress where appropriate — are a runtime feature, not an agent feature. Be specific about what your runtime actually offers rather than assuming.

Isolation between sessions

Two agents sharing a browser context will leak state: cookies, storage, sometimes even tabs. Session isolation should be the default, not a configuration flag you remember to set.

Observability

When an agent fails at step 14 of 20, you need to see what it saw. A live viewer, session recording, and CDP access for manual inspection turn a two-hour debugging session into a five-minute one. See how live sessions work for what this looks like in practice.

Usage controls

Browser-hours add up. Metering, per-session limits, and clear cost attribution matter once you're running more than a handful of tasks. Current rates are on the pricing page.

Connecting an Agent to a Hosted Browser

The integration is smaller than most teams expect. If your agent already drives Playwright, you change the connection call and nothing else.

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

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

// Your runtime provider returns a CDP endpoint for a fresh session.
async function createSession(): Promise<SessionInfo> {
  const res = await fetch('https://api.remote-browser.dev/sessions', {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${process.env.REMOTE_BROWSER_KEY}`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({
      profile: 'checkout-agent',
      proxy: { country: 'us' },
    }),
  });
  if (!res.ok) throw new Error(`session create failed: ${res.status}`);
  return res.json();
}

async function runAgentTask(goal: string): Promise<void> {
  const { cdpUrl, sessionId } = await createSession();

  const browser: Browser = await chromium.connectOverCDP(cdpUrl);
  const context = browser.contexts()[0];
  const page: Page = context.pages()[0] ?? (await context.newPage());

  try {
    await page.goto('https://example.com/orders', {
      waitUntil: 'domcontentloaded',
    });

    // Your agent loop goes here: observe page state, decide action,
    // execute via page.click / page.fill / page.evaluate, repeat.
    // The browser is remote; the reasoning is local.
    await agentLoop(page, goal);
  } finally {
    // Close the CDP connection but let the session persist if needed.
    await browser.close();
  }
}

async function agentLoop(page: Page, goal: string): Promise<void> {
  // Placeholder for your observe/reason/act implementation.
  throw new Error('wire up your agent loop');
}

Two things to note. First, connectOverCDP is the same call you'd use against a local Chrome started with --remote-debugging-port. The agent code doesn't know or care that the browser is remote. Second, closing the Playwright Browser object disconnects the client — it doesn't necessarily terminate the remote session. That distinction is what lets you reconnect after a client crash.

For the protocol details, the Chrome DevTools Protocol documentation is the authoritative reference, and Playwright's CDP connection guide covers the client side.

Common Failure Patterns and Fixes

"Hermes remote browser not working." This usually means the CDP endpoint is reachable but the WebSocket upgrade is failing — often a proxy or firewall stripping the Upgrade header. Test with a raw WebSocket client before blaming the agent. If you're wiring Hermes specifically, the connection setup is covered in Hermes agent browser install.

Agent loops on the same element. The observation format is probably lossy — the model can't tell it already clicked. Switch from screenshot-only to accessibility tree plus screenshot, or add explicit action history to the prompt.

Session dies mid-task. Check whether your runtime has an idle timeout shorter than your task duration. Long-running agents need sessions that stay alive without activity.

Everything works locally, fails in CI. Local Chrome has your cookies and your residential IP. CI has neither. This is the single most common reason teams move to a hosted runtime — see remote browser online for the setup path.

Which Should You Actually Adopt?

They're not alternatives, so the question is really about order of operations.

Start with the agent pattern if you're prototyping, the task is exploratory, and you can tolerate non-determinism. Run it against local Chrome. Learn what your agent gets wrong.

Move to a hosted runtime when any of these become true: tasks run on a schedule, sessions need to survive restarts, you need consistent egress IPs, you're running more than a few concurrent tasks, or you need to debug failures after the fact.

Adopt both deliberately. Pick your agent framework for reasoning quality and your runtime for reliability. Keep them decoupled — the connection is one function call, and you should be able to swap either side without rewriting the other.

The teams that struggle are the ones that treat the browser as an implementation detail of the agent. It isn't. It's the layer that determines whether the agent's reasoning ever gets a chance to matter.

If you want to see what a hosted runtime looks like end to end, start with the documentation, then run one of your existing Playwright scripts against a remote session before touching your agent code. The connection change is small; the reliability difference is not.