Browser Use 90: What a 90 Score Means for Production

# Browser Use 90: What a 90 Score Means for Production

A browser use 90 is a benchmark score, not a deployment. It means an agent completed roughly 90% of tasks in a defined evaluation set — usually WebVoyager, WebArena, or an internal suite — under fixed conditions. That number tells you the model-plus-harness combination can reason about web pages. It does not tell you whether the same agent will hold up when it runs 10,000 times a day against sites that change, rate-limit, and fingerprint. This post covers what a browser use 90 actually measures, where the missing 10 points come from, and how to run browser use workloads on a hosted Chromium runtime instead of a laptop.

If you want the runtime layer first, start with Remote Browser for AI agents. The rest of this page is about interpreting the browser use 90 score and closing the gap.

What "Browser Use 90" Actually Measures

Browser use benchmarks score task success. A task is something like "find the cheapest direct flight from SFO to JFK next Tuesday and report the price." The harness gives the agent a browser, a goal, and a step budget. Success is judged by an LLM evaluator or a deterministic check against the final page state.

Three properties of that setup matter more than the headline number:

• The task set is fixed. Benchmarks reuse the same URLs and goals. A browser use 90 on a public suite means the agent handles those pages, not the long tail of the open web.
• The environment is controlled. Most runs use a clean browser profile, a datacenter IP, and no bot mitigation. Production traffic hits all three.
• The metric is binary per task. A task that fails on step 40 after 39 correct actions scores zero, same as a task that fails immediately. The score hides partial progress.

So a browser use 90 is best read as an upper bound on capability, measured in favorable conditions. It is a useful signal for model selection. It is a weak signal for infrastructure planning.

Why the Number Moves Between Runs

If you re-run the same agent against the same suite and get 88 one day and 91 the next, nothing is broken. Sources of variance:

• Sampling temperature. Non-zero temperature changes action sequences. Some paths through a page succeed, others dead-end.
• Page drift. Sites change markup, A/B tests, and copy. A benchmark frozen six months ago no longer matches the live site.
• Evaluator noise. LLM-as-judge scoring is not deterministic. Borderline tasks flip.
• Timeout and step budgets. A tighter budget converts slow-but-correct runs into failures.

Treat any single browser use 90 as a sample, not a constant. If you are comparing two agents, run both against the same suite on the same day with the same budget.

Where the Last 10 Points Go

The gap between a benchmark 90 and production reliability is almost never the model. It is the environment. Here is the breakdown I see most often when teams move from local scripts to real traffic.

Notice that six of the seven rows are infrastructure. That is the honest answer to "why is my agent at 90 in the demo and 60 in prod." The model is fine. The runtime is not.

Benchmark Score vs. Production Runtime

The two things get conflated because both are called "browser use." They are different layers.

The agent layer decides what to do: read the page, pick an action, evaluate the result. This is where a browser use 90 lives. It is model-bound and improves with better reasoning, better tool schemas, and better observation formats.

The runtime layer decides whether the action can happen at all: is there a browser, is it alive, does it have a clean profile, does it have a usable IP, can you see what it is doing. This is where production reliability lives. It is infrastructure-bound and improves with hosted sessions, proxies, and observability.

You can have a browser use 90-scoring agent on a broken runtime and get 40% task success. You can have a 70-scoring agent on a solid runtime and get 70% task success with predictable failure modes you can actually fix. The second is easier to operate.

Running Browser Use Workloads on Hosted Chromium

Remote Browser provides hosted Chromium sessions you drive over CDP. That means the same agent code that runs against a local Chrome runs against a remote browser with a connection string change. Playwright, Puppeteer, and Selenium all work because they all speak CDP.

The practical shape:

1. Request a session from the runtime. You get a CDP WebSocket endpoint.
2. Connect your agent's browser client to that endpoint.
3. Run the task. The session has its own profile, its own network identity, and its own lifecycle.
4. Watch it live if you need to. The viewer shows the actual rendered page, not a screenshot stream.
5. Tear down or persist the profile depending on whether the task needs continuity.

Here is a minimal Playwright connection over CDP. This is the same pattern whether the endpoint is local or hosted.

import { chromium } from 'playwright';

// The runtime returns a CDP endpoint for a freshly allocated session.
// Treat this like any other connectOverCDP target.
const cdpEndpoint = process.env.REMOTE_BROWSER_CDP_URL!;

const browser = await chromium.connectOverCDP(cdpEndpoint);

// Reuse the default context so the session's profile and cookies apply.
const context = browser.contexts()[0] ?? await browser.newContext();
const page = context.pages()[0] ?? await context.newPage();

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

// Your agent's observation/action loop goes here.
// Keep steps idempotent: a retry should not double-submit a form.
await page.fill('#email', process.env.TEST_EMAIL!);
await page.fill('#password', process.env.TEST_PASSWORD!);
await page.click('button[type="submit"]');

await page.waitForLoadState('networkidle');

// Do not close the browser if you want the profile to persist for the next task.
// await browser.close();

Two details that matter in production:

• `connectOverCDP` reuses the existing browser. You are not launching a new one. That is the point — the runtime already launched it, configured it, and gave it a network identity.
• Session teardown is explicit. If you close the browser, the session ends. If you leave it open, it keeps burning browser-hours. Decide which you want per task class.

For the full connection surface, see the documentation. For how sessions are metered, see pricing.

Persistent Profiles and Session Continuity

Many browser use tasks are stateful: log in once, then run twenty actions across sessions. Hosted runtimes handle this with persistent profiles. The profile carries cookies, local storage, and session tokens across sessions, so the agent does not re-authenticate every run.

The trade-off is isolation. A persistent profile is a shared identity. If two concurrent tasks use the same profile, they can stomp on each other's state. The usual pattern is one profile per account, with a queue in front of it so only one task touches a profile at a time. Session isolation is the default; persistence is opt-in.

Proxies and Configurable Browser Settings

Bot detection is the single largest source of production failures for browser use agents, and it is invisible in benchmarks. The mitigation is not a magic flag. It is a combination:

• Managed proxy pools so the request originates from an IP that looks like a real user.
• Consistent browser settings so the fingerprint does not contradict the IP — a datacenter IP with a consumer browser profile is a mismatch.
• Realistic timing so the agent does not fire twelve requests in 200ms.

Remote Browser exposes configurable browser settings and proxy configuration at the session level. I would avoid claiming any specific anti-detection technique works universally; sites update their detection continuously. What you want from a runtime is the ability to configure these knobs per session and change them without redeploying your agent.

Production Criteria for a Browser Use Runtime

If you are evaluating runtimes to run browser use workloads, score them on these, not on benchmark numbers.

Connection model. Does it give you a CDP endpoint you can hand to Playwright, Puppeteer, or Selenium? If it requires a proprietary SDK for basic operation, you are locked in.

Session lifecycle. Can you create, inspect, persist, and destroy sessions programmatically? Can you attach to a running session to debug it?

Observability. Is there a live viewer? Can you record a session and replay it? When a task fails at step 40, can you see what the page looked like?

Network identity. Can you configure proxies per session? Can you pin a session to a stable identity for tasks that need continuity?

Isolation. Are sessions isolated by default? Can you opt into persistence without leaking state between unrelated tasks?

Metering. Is usage measured in browser-hours or some other unit you can reason about? Can you set caps so a runaway agent does not burn your budget? See pricing for how Remote Browser meters this.

Failure behavior. What happens when a browser crashes mid-task? Does the runtime detect it and give you a clean session, or does your agent hang?

A runtime that scores well on these will make your browser use 90-scoring agent behave like a 90-scoring agent in production. A runtime that scores poorly will make it behave like a 60 no matter how good the model is.

Common Misreadings of "Browser Use 90"

A few patterns worth naming, because they cause bad decisions.

"90 means it works 90% of the time." No. It means it completed 90% of a fixed task set under benchmark conditions. Production success rate is a different number and is usually lower until the runtime is fixed.

"Higher score means better agent for my use case." Only if your use case resembles the benchmark. If your tasks are all behind a login on a site with aggressive bot detection, a general benchmark score tells you very little.

"I should pick the runtime that scores highest on browser use benchmarks." Runtimes are not scored on browser use benchmarks; agents are. Runtimes are scored on uptime, latency, session reliability, and observability. Compare them on those.

"The score is the product." The score is a marketing artifact. The product is whether your agent completes tasks on the sites you care about, at the volume you need, at a cost you can predict.

A Practical Path from Demo to Production

If you have a browser use agent scoring in the 80s or 90s on a benchmark and you want it to work in production, the sequence that works:

1. Move the browser off your laptop. Run the agent against a hosted Chromium session over CDP. This alone eliminates a class of failures around local resource contention and environment drift.
2. Add observability before you add scale. Turn on the live viewer and session recording. You cannot fix failures you cannot see.
3. Instrument task success, not step success. Log whether the task completed, not whether each action returned 200. The gap between those two numbers is your real failure rate.
4. Classify failures. Split them into model failures (wrong action), page failures (site changed), and infrastructure failures (session died, blocked, timed out). Fix them in that order of volume.
5. Add proxies and configurable browser settings only where needed. Not every task needs a managed proxy. Applying them everywhere raises cost and latency for no benefit.
6. Set usage caps. A runaway agent loop is a billing incident. Meter in browser-hours and cap per task class.

Steps 1, 2, and 6 are runtime concerns. If your runtime does not support them, that is the constraint to fix first.

Where Remote Browser Fits

Remote Browser is the runtime layer, not the agent layer. It gives you hosted Chromium sessions with CDP access, Playwright/Puppeteer/Selenium compatibility, a live viewer, persistent profiles, configurable proxy and browser settings, session isolation, and usage controls. It does not try to be your agent framework, and it does not claim a benchmark score, because runtimes are not what benchmarks measure.

If you are running browser use workloads and the browser use 90 score is not translating to production, the runtime is the place to look. Start with the documentation to get a CDP endpoint, then check pricing to understand how sessions are metered. If you want the conceptual background on why hosted Chromium changes task success, read Remote Browser for AI agents.

The score is a starting point. The runtime is what you ship.

For the underlying protocol details, the Chrome DevTools Protocol documentation is the authoritative reference for what CDP exposes and what your client can rely on.