Browser Use 82: What the Score Means for Production Agents

# Browser Use 82: What the Score Means for Production Agents

Browser Use 82 is a benchmark figure — 82% task success on an internal hard-task suite — and it tells you something narrow but useful: a specific agent stack, running against a specific set of protected sites, solved roughly four out of five tasks. It does not tell you your agent will hit 82% on your workload. This post breaks down what a number like Browser Use 82 actually measures, why the runtime underneath the agent matters more than the headline, and how to wire browser-use agents to hosted Chromium so the score you get in testing resembles the score you get in production.

If you are evaluating browser-use as a framework, the benchmark is a starting point. If you are shipping it, the runtime is the thing you will spend your time debugging.

What "Browser Use 82" Actually Refers To

The number comes from browser-use's own reporting: 82% on an internal hard benchmark, at a stated cost per solved task and per browser hour. Read that sentence carefully, because every clause constrains the others.

• Internal benchmark. The task suite is theirs, not a public leaderboard. That is normal — most agent vendors run private evals — but it means the tasks were chosen by the same team reporting the score.
• Hard tasks. Usually this means multi-step flows on sites with anti-bot measures, dynamic content, or auth walls. Hard suites are where naive automation falls over.
• Per solved task cost. This bundles browser time, network traffic, and model tokens. It is a blended number, so it moves when your model choice or retry rate moves.
• Per browser hour. This is the infrastructure slice. It is the part you can actually control by changing where the browser runs.

The distinction matters because people search for "browser use 82" expecting a capability claim. What they get is a cost-and-reliability claim under specific conditions. Both are useful. Only one is portable to your stack.

Why benchmark numbers do not transfer cleanly

Three variables dominate whether you reproduce a score like 82%:

1. Site mix. A suite weighted toward well-behaved sites will score higher than one weighted toward sites with aggressive bot detection.
2. Model. Agent success is model-sensitive. Swap the LLM and the same browser runtime produces different results.
3. Runtime stability. If sessions drop, pages render inconsistently, or the browser is missing a real profile, the agent burns steps recovering instead of completing the task.

You control the third variable directly. The first two are workload and model choices. That is why production teams spend disproportionate effort on the runtime layer — it is the lever with the clearest return.

The Runtime Is the Part You Debug

Browser-use is an agent framework. It decides what to click, type, and read. It does not decide where the browser lives, whether it has a persistent profile, what IP it egresses from, or whether the session survives a worker restart.

Those are runtime concerns, and they are where most "browser use reached 82% in my tests but 40% in prod" stories originate. Common failure modes:

• Cold profiles. Every run starts as a fresh browser with no cookies, no local storage, no history. Sites that expect returning users treat the agent as suspicious.
• Datacenter IPs. Many protected sites score datacenter ranges differently from residential ones. This is a network property, not a framework property.
• Session loss. A local Chromium tied to a single process dies when that process dies. Long-horizon agents need sessions that outlive the worker.
• No observability. When a task fails at step 14, you need to see what the page looked like. Without a live viewer or session recording, you are guessing.

A hosted runtime addresses all four. That is the actual argument for moving browser-use agents off local Chrome — not raw speed, but the elimination of a class of failures that have nothing to do with your agent logic.

Hosted Chromium vs Local Chrome for Browser-Use Agents

The table is not an argument that local Chrome is bad. It is an argument that local Chrome optimizes for a different problem. If you are iterating on prompts, local is fine. If you are running agents against protected sites on a schedule, the runtime is the product.

Connecting Browser-Use to a Remote Browser

Remote Browser exposes CDP endpoints, so anything that speaks the Chrome DevTools Protocol can attach — including browser-use, Playwright, Puppeteer, and Selenium. The connection pattern is the same across all of them: get a session, get its WebSocket endpoint, connect.

Here is a Playwright-over-CDP example in TypeScript that mirrors how a browser-use agent would attach:

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

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

async function createSession(): Promise<SessionInfo> {
  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({
      // Persistent profile so cookies and storage survive across runs
      profile: "checkout-agent",
      // Configurable browser settings: proxy region, locale, timezone
      proxy: { country: "us" },
      viewport: { width: 1280, height: 800 },
    }),
  });

  if (!res.ok) {
    throw new Error(`Session create failed: ${res.status} ${await res.text()}`);
  }

  return (await res.json()) as SessionInfo;
}

async function runTask(session: SessionInfo): Promise<void> {
  const browser: Browser = await chromium.connectOverCDP(session.cdpUrl);
  const context: BrowserContext = browser.contexts()[0];
  const page: Page = context.pages()[0] ?? (await context.newPage());

  try {
    await page.goto("https://example.com/login", { waitUntil: "domcontentloaded" });
    await page.fill("#email", process.env.AGENT_EMAIL!);
    await page.fill("#password", process.env.AGENT_PASSWORD!);
    await page.click("button[type=submit]");
    await page.waitForURL("**/dashboard", { timeout: 30_000 });

    // Hand off to your browser-use agent loop here, or drive directly.
    const title = await page.title();
    console.log("Landed on:", title);
  } finally {
    // Detach without killing the remote session; the runtime owns its lifecycle.
    await browser.close();
  }
}

(async () => {
  const session = await createSession();
  try {
    await runTask(session);
  } finally {
    await fetch(`https://api.remote-browser.dev/v1/sessions/${session.id}`, {
      method: "DELETE",
      headers: { Authorization: `Bearer ${process.env.REMOTE_BROWSER_API_KEY}` },
    });
  }
})();

Two details worth calling out. First, browser.close() on a CDP connection detaches your client; it does not necessarily terminate the remote browser. That is deliberate — it lets you reconnect from a different worker if the first one dies. Second, the profile field is what makes the second run of this agent look like a returning user rather than a stranger.

For the full session lifecycle, including reconnect and viewer URLs, see the /documentation.

Wiring browser-use specifically

Browser-use accepts a CDP URL in its browser configuration. The practical pattern is:

1. Provision a session through the runtime API.
2. Pass the returned cdpUrl into browser-use's browser config.
3. Let the agent run its observe-decide-act loop.
4. Close the session when the task completes or the retry budget is exhausted.

If you want a deeper walkthrough of the agent-side wiring, /blog/remote-browser-for-ai-agents covers the runtime layer in more detail, and /blog/remote-control-browser covers the control-plane side.

What to Measure Instead of Chasing 82

A vendor benchmark is a directional signal. Your own numbers are the ones that matter. Track these four:

• Task success rate by site class. Split your workload into "well-behaved," "moderately protected," and "aggressively protected." A single blended number hides where you are actually failing.
• Steps per task. If your agent takes 40 steps where a human takes 8, you have a perception problem, not a browser problem — but the browser runtime affects how many steps are wasted on retries.
• Cost per solved task. This is the number that shows up in your budget. It combines browser hours, proxy traffic, and model tokens. Browser hours are the slice you can shrink by tuning session lifetime and avoiding idle sessions.
• Session failure rate. How often does a session die mid-task? This is a pure runtime metric and should be near zero on a hosted runtime.

If you are comparing runtimes, /blog/remote-browser-online walks through the evaluation criteria in more depth. The short version: measure your own workload, on your own sites, with your own model.

Stealth, Proxies, and the Parts People Skip

The phrase "browser use stealth" shows up in a lot of search queries, usually from people whose agents are getting blocked. It is worth being precise about what a runtime can and cannot do.

A hosted runtime can provide:

• Configurable browser settings — viewport, locale, timezone, user agent, and related launch parameters.
• Proxy routing — sessions egress from a chosen region or provider, which changes how sites score the traffic.
• Persistent profiles — cookies, local storage, and cache that survive across sessions, so the agent accumulates legitimate session state.
• Session isolation — one agent's cookies do not leak into another's.

A hosted runtime cannot guarantee you will never be detected. Detection is adversarial and site-specific. What a good runtime does is remove the *avoidable* signals — fresh profiles, mismatched locale and IP, headless fingerprints that do not match the declared user agent — so that the remaining detection surface is the site's actual policy rather than your infrastructure's sloppiness.

Treat stealth as a configuration surface, not a feature that flips a switch. If a site's terms prohibit automation, no runtime setting changes that.

When Browser Use 82 Is the Right Number to Care About

The benchmark is useful in exactly one scenario: you are choosing a framework and want a rough sense of whether it can handle multi-step tasks on protected sites. In that scenario, 82% on a hard suite is a reasonable signal that the framework is not naive.

It is not useful for:

• Predicting your own success rate
• Comparing runtimes (the framework and the runtime are different layers)
• Deciding whether to move to hosted infrastructure (that decision is about session lifetime, profiles, and observability)

If you are past framework selection and into production, stop reading benchmark posts and start instrumenting your own runs. The runtime you choose will move your numbers more than the framework version you pin.

Getting Started

The path from a local browser-use script to a production agent is short:

1. Read the /documentation for session creation, CDP endpoints, and profile management.
2. Provision a session and connect with chromium.connectOverCDP() as shown above.
3. Point browser-use at the CDP URL.
4. Add a live viewer to your debugging loop so failures are visible.
5. Check /pricing for current rates before you size your workload.

For background on the Chrome DevTools Protocol itself, the official CDP documentation is the authoritative reference for the domains your agent will exercise.

Browser Use 82 is a useful data point about a framework. Your production success rate is a function of the runtime you put underneath it.