browser-control Tops WebVoyager at 99.19%
Keon Kim and Krish Chelikavada
Our browser-control submission now leads the Steel.dev WebVoyager leaderboard with a reported score of 99.19%. The Fable 5 run completed 610 of 615 tasks on the submitted live-web scope.
| System | Score | Completed tasks |
|---|---|---|
| browser-control (Fable 5) | 99.19% | 610 / 615 |
| Alumnium | 98.5% | — |
| Surfer 2 (H Company) | 97.1% | — |
| Magnitude | 93.9% | — |
| Surfer-H + Holo1 (H Company) | 92.2% | — |
We also ran the same browser-control harness with Opus 4.8. That run completed 556 of 615 tasks, or 90.41%. The two runs demonstrate that the execution layer is portable across driving models, though their task text is not identical and the scores should not be treated as a controlled model comparison.
What WebVoyager tests
WebVoyager is a live-web benchmark introduced at ACL 2024 by researchers from Zhejiang University, Tencent AI Lab, and Westlake University. Its original dataset contains 643 tasks across 15 popular websites, including Amazon, Google Flights, Google Maps, Booking.com, GitHub, ArXiv, Coursera, Hugging Face, Wolfram Alpha, and Google Search.
The tasks ask an agent to search, navigate, filter results, fill forms, compare products, use maps, plan travel, and retrieve information from websites that continue to change after the benchmark is published.
That makes WebVoyager useful and difficult. It tests a complete browser system against the open web rather than a model against a static dataset. Page drift, expired dates, authentication, bot detection, dynamic interfaces, and ambiguous success conditions all affect the result.
What browser-control is
browser-control is a small Rust CLI that drives a real browser through the Chrome DevTools Protocol. It gives a coding agent compact browser commands it can call directly from the shell.
It is not a model, an agent framework, or an MCP server. The coding agent remains responsible for planning. browser-control provides the execution layer: page snapshots, stable element references, browser actions, raw CDP access, background events, and failure traces.
This separation matters because browser benchmarks measure more than model intelligence. The browser interface determines what evidence the model sees, which actions it can take, how failures are surfaced, and whether it can recover without losing the task.
The result supports a harness-first thesis: browser-agent reliability can improve materially through better control primitives, evidence capture, and recovery mechanics, without training a custom browsing model.
How we measured the result
The published run starts from the original 643-task WebVoyager snapshot. It excludes the 24-task Alumnium removed set and four tasks documented as currently impossible, leaving a 615-task evaluation scope.
The Fable 5 run passed 610 tasks. Results were judged with the GPT-5.5 implementation of Alumnium's vanilla success policy, using the task instruction, final response, and captured screenshots.
The complete benchmark package includes:
- the original, cleaned, current, and model-specific task layers;
- the run and evaluation scripts;
- pinned browser-control and Python dependencies;
- per-task results, screenshots, transcripts, and page evidence;
- judge outputs and aggregate score reports; and
- a record of task removals and prompt changes.
The package also includes a clean-slate verification script that checks the task counts, artifact coverage, score summaries, and pinned browser-control build.
How to read the ranking
Steel.dev lists browser-control (Fable 5) as the current leader and labels the result self-reported. That is the right framing.
Modern WebVoyager submissions are not perfectly standardized. Teams may use different evaluators, retry budgets, task filters, prompt updates, browser infrastructure, and evidence policies. Small gaps between rows are therefore not equivalent to differences on a controlled model benchmark.
The 99.19% result is a system-level score for Fable 5 plus browser-control, the task layer, run policy, and judge. It is not a claim that the base model alone reaches 99.19%.
There are two additional caveats:
- Fable 5 is no longer available, so the exact Fable run cannot currently be rerun from scratch. Its task artifacts and judgments remain public for inspection.
- The Opus 4.8 run used a model-specific layer with 47 documented prompt differences. It uses the same harness, but it is not an apples-to-apples ablation against the Fable 5 run.
Publishing these details is part of the contribution. A high benchmark number is most useful when the scope, task changes, evaluator, failures, and evidence can all be inspected.
Why this matters
Browser agents can operate software without waiting for every product to expose an API. That makes the browser an important execution surface for coding agents, research systems, QA automation, and enterprise workflows.
A shell-native control layer fits naturally into that environment. Any coding agent that can run a command can use browser-control. It does not need a language-specific SDK or a separate agent framework, and raw CDP remains available when a higher-level command is not enough.
The leaderboard result shows how much the execution interface matters. Better models help, but so do tools that preserve the right evidence, expose recoverable state, and make failures legible to the agent.
The model plans. The harness gives it reliable hands and eyes.
Reproduce and inspect
Citation
Please cite this work as:
Kim, Keon and Chelikavada, Krish, "browser-control Tops WebVoyager at 99.19%", Om Labs, Aug 2026.
Or use the BibTeX citation:
@article{kim2026browsercontroltopswebvoyagerat9919,
author = {Keon Kim and Krish Chelikavada},
title = {browser-control Tops WebVoyager at 99.19%},
journal = {Om Labs},
year = {2026},
note = {https://omlabs.xyz/blog/browser-control-tops-webvoyager},
}