LISTEN TO THIS ARTICLE

Evidence base: source trail below.

The browser-use agents computer-use benchmarks gap is not a story about browsers replacing full desktop control; it is a story about narrowing the action surface, as shown by the score split between OSWorld and browser-only benchmarks in OpenAI's 2025 CUA report (OpenAI CUA). OSWorld tested 369 real computer tasks and reported 12.24% success for the best AI model against 72.36% for humans in April 2024, mostly exposing GUI grounding and operational-knowledge failures (OSWorld). OpenAI's 2025 Computer-Using Agent then reported 38.1% on OSWorld, 58.1% on WebArena, and 87.0% on WebVoyager, which is a useful split because the same model looked far stronger when the world was only a browser (OpenAI CUA).

Key takeaways

  • Browser-use agents are not a softer version of computer-use agents: OpenAI reported 87.0% on WebVoyager but 38.1% on OSWorld, so the interface boundary changes the score (OpenAI CUA).
  • Web benchmarks are moving from toy pages towards harder environments: WebArena reported 14.41% for its best GPT-4-based agent against 78.24% human performance on realistic web tasks (WebArena).
  • Vendor benchmarks can be useful, but they need a discount: Browser Use reported 78.0% on 100 hard browser tasks and 87% judge agreement with human labels, while also saying impossible tasks were removed (Browser Use benchmark).
  • The production question is not whether the agent can click. It is whether it can recover from login state, layout drift, failed tools, and ambiguous user intent without making work for the operator.

In the earlier computer-use signal, the headline was the 12-to-72 problem: higher task completion still did not prove efficient operation.

Browser-use agents computer-use benchmarks: the split

Computer-use benchmarks punish generality because OSWorld tests real desktop tasks across apps rather than a single web flow (OSWorld). A desktop agent has to read pixels, infer app state, switch contexts, operate menus, wait through latency, and remember prior screenshots, which matches the perception-reasoning-action loop OpenAI describes for CUA (OpenAI CUA). Anthropic described Claude 3.5 Sonnet's computer use beta in October 2024 as experimental, reported 14.9% in OSWorld's screenshot-only category, and reported 22.0% with more steps (Anthropic computer use).

Browser-use agents cut away part of that mess. The browser still has pop-ups, auth walls, iframes, sticky banners, broken selectors, and hostile anti-automation systems. But it also has a DOM, URL state, structured network traffic, browser storage, and Playwright-style control.

This is why the benchmark spread matters for the models-frontiers reading path. In the earlier computer-use signal, the headline was the 12-to-72 problem: higher task completion still did not prove efficient operation. For browser agents, the same warning survives in a narrower form. A browser score can be higher when the task surface is cleaner, as OpenAI reported 87.0% on WebVoyager and 38.1% on OSWorld for the same CUA system (OpenAI CUA).

The browser is still a hostile test bed

WebArena was built because simplified web tasks were too forgiving, and its paper reported 14.41% end-to-end success for the best GPT-4-based baseline compared with 78.24% for humans (WebArena). WebVoyager pushed in a different direction by using live websites, compiling tasks from 15 popular sites, and reporting 59.1% task success for its multimodal WebVoyager agent (WebVoyager).

Those numbers make the browser look measurable. They do not make it stable. In its March 2024 paper, WorkArena focused on enterprise browser tasks in ServiceNow and introduced 33 tasks for knowledge-worker software (WorkArena). BrowserGym then tried to clean up the evaluation layer itself, arguing in December 2024 that web-agent benchmarks were fragmented and hard to compare, and running a multi-benchmark experiment across six state-of-the-art LLMs (BrowserGym).

The inference is blunt: browser-use agents are becoming easier to test, but not easy to trust. My June 2026 operating concern is that fixed browser courses still leave layout changes, auth changes, rate limits, and slow partial loads outside many published scores, which echoes BrowserGym's warning about fragmented web-agent evaluation (BrowserGym). This is the same problem covered in why most AI agent benchmarks are broken, just with a sharper commercial edge.

Those benchmark choices narrow the claim because the task set excludes impossible tasks by design (Browser Use benchmark).

What browser-use agents computer-use benchmarks don't prove

Browser Use treats browser automation as an agent harness, not just a model prompt. Its March 2026 benchmark post says BU Bench V1 contains 100 hand-selected browser tasks drawn from five sources, and reported 78.0% for Browser Use Cloud, 63.3% for an open-source setup using its cloud model, and 62.0% for Claude Opus 4.6 in its open-source agent configuration (Browser Use benchmark).

That is useful evidence, not a verdict. The same Browser Use post says its BU Bench V1 removed tasks that were majority-voted impossible and never completed, and says the binary LLM judge agreed with human labels 87% of the time (Browser Use benchmark). Those benchmark choices narrow the claim because the task set excludes impossible tasks by design (Browser Use benchmark). The score says something about hard-but-possible tasks under a selected harness because Browser Use describes BU Bench V1 as 100 hand-selected tasks with a shared judge and repeated model runs (Browser Use benchmark). It does not say an agent can safely operate arbitrary logged-in business software all afternoon.

The stronger local analogy is coding-agent benchmarks hitting the generalisation wall. Public scores are screening signals. BrowserGym's December 2024 paper argues that web-agent benchmarks need consistent observation spaces, action spaces, evaluation, and experiment management before comparisons become reliable, which is why I would pair browser-use agents with private evals, rollback gates, review cost tracking, and failure logs (BrowserGym).

Operator takeaway

Use browser-use agents where the browser is the least bad interface, not where the browser is merely available. My operating rule is to prefer reversible actions, bounded accounts, approved domains, replayable traces, and a clean escalation path. Treat payments, legal submissions, regulated records, account recovery, social posting, and one-shot irreversible updates as human-approval workflows, matching OpenAI's note that CUA seeks user confirmation for sensitive actions and Anthropic's warning that computer use can create spam, misinformation, or fraud vectors (OpenAI CUA, Anthropic computer use).

The near-term stack should look boring: browser agent, allowlisted domains, scoped credentials, deterministic tool fallbacks, trace capture, task-specific evals, and a human checkpoint before sensitive writes.

For Swarm Signal readers following agent benchmarks that won't sit still, browser-use is another place where static evaluation can understate deployment risk. The browser is narrower than the desktop. It is not simple.

Related: Small-Model Routing With Frontier Fallback: The Production Cost Pattern.

Source trail

Benchmark papers and research

Model and vendor reports

Related Swarm Signal coverage