Open-Source Browser Agents That Actually Work: Benchmarked

Open-source browser agents can drive a real web application in 2026, but the number a project quotes tells you almost nothing until you know which benchmark produced it. browser-use, Skyvern and Stagehand each publish a headline score from a different suite, graded by a different judge, against a different set of live sites. Line them up side by side and the field’s honest ceiling looks nothing like the marketing page.

That matters because the decision in front of most teams is no longer “can an agent click things.” It is whether a self-hosted stack can survive a login wall, a two-factor prompt, a CAPTCHA and a multi-step form often enough to be worth the engineering. On the one benchmark built specifically to stress those steps, the best published result across the whole field is 64.4% — 32.6 points below the 97% figure circulating from a read-heavy leaderboard, and scored on an entirely different system.

This guide covers the four open-source shapes and how to tell them apart, current repository vitals and the maintenance signal most roundups skip, a benchmark-by-benchmark table that keeps the harness labels intact, the authentication failure mode that decides real deployments, what self-hosting genuinely costs, and where anti-bot detection and prompt injection now sit. For the closed-product side of the market, our commercial computer-use matrix covers Claude, OpenAI and Gemini; this post stays strictly on open-source projects.

Most comparison posts rank these projects as if they were competing products. They are not. The cleaner mental model is architectural: in any given stack, something has to decide what happens next — the agent framework, your own code, or the model. That single question sorts the field faster than any feature table, and it explains why Stagehand ships an agent primitive while browser-use also exposes low-level tooling. The marketing pages overlap; the architectures do not.

That framing is worth holding onto through the rest of this post. If you are already deep in Playwright and want AI only where the DOM is unstable, the hybrid pattern in our Playwright vs Stagehand deep-dive is the shorter path. If you want the agent to own the plan end to end, you are choosing between browser-use and Skyvern, and the licence question becomes real. For where these projects sit inside the wider ecosystem, see the full open-source agent landscape.

Star counts are a popularity signal, not a quality one, but they do reveal how much community tooling, how many Stack Overflow answers and how many third-party integrations you inherit. The distribution here is lopsided: browser-use carries more than twice the stars of Skyvern and Stagehand combined. All figures below were read from the projects’ own repositories at the time of writing and move daily.

Two adjacent numbers put those in perspective. Microsoft’s Playwright MCP server sits at 35,884 stars under Apache-2.0 — more than either dedicated agent framework — and OpenHands, a general coding agent with browsing capability rather than a browser-specific project, sits at 83,335. Teams are clearly comfortable giving a model browser tools without adopting a browser-agent framework at all.

The metric almost every roundup omits is pushed_at. A project can hold six thousand stars, appear in “best open source browser agent” roundups, and have received no commits in well over a year. That is not a hypothetical.

Every project in this category quotes the benchmark that flatters it, and none of them are lying — they are simply reporting different tests. The table below keeps the labels intact: what the number is, which suite produced it, whose harness ran it, and what it does not tell you. Read the fourth column first; it is where the useful information lives.

Three readings fall out of that grid. First, the Stagehand rows are the cleanest natural experiment available: identical framework, two different models, ten points of difference. The framework is not what is being measured on most leaderboards — the model is. Second, the two highest open-source-adjacent numbers on the page, 64.4% and 63.3%, come from suites designed to be hard, and they land within 1.1 points of each other despite entirely separate authorship. That convergence is more informative than either figure alone.

Third, the open-weight ceiling is the quiet story. On OSWorld-Verified, the strongest open-weight model tracked sits at 66.7% while frontier closed models are reported in the mid-70s and mid-80s — an 18.7-point gap to the top entry. Today’s open-source browser agents mostly win by wrapping a closed frontier model, not by shipping a competitive open brain of their own. Self-hosting the agent is not the same thing as self-hosting the intelligence.

This is the single most common error in coverage of this category, so it is worth stating plainly: Browser Use publishes a 97% result and a 63.3% result, and both are honest. The 97% belongs to Browser Use Cloud v3 on Online-Mind2Web — a managed service with vendor infrastructure, evaluated by the vendor with the vendor’s own judge. The 63.3% belongs to the open-source library calling the bu-2-0 model on BU Bench V1, a deliberately harder 100-task suite drawing equally from WebBench, Mind2Web 2, GAIA and BrowseComp plus a custom slice. If you pip install the library, the second number is the one describing your stack.

The bottom row deserves its own caveat. It comes from a 2025 academic paper — not a new measurement — which found that on live, less-curated tasks frontier agents completed only roughly 30% of what was asked, against benchmark scores above 90% on curated suites. It pre-dates every other row here, and the specific number is a year old. It stays on the chart because the methodological critique it makes is still the right one: curated task sets flatter agents, and the gap between a leaderboard and your own site is where projects fail.

The same dynamic explains why the older WebVoyager benchmark has fallen out of use for serious comparison. An independent field-notes compilation of vendor-posted scores puts its tracked top four systems all above 93%, with the leading pair separated by a fraction of a point. When a benchmark can no longer distinguish first place from fourth, it has stopped measuring capability and started measuring optimisation against a fixed task list. Treat any 2026 browser-agent claim that leans on WebVoyager as marketing rather than evidence.

Browser Use’s own model progression illustrates how much of the movement is model-side rather than framework-side. The vendor reports bu-2-0 lifting internal-eval accuracy from 74.7% to 83.3% at a similar average task duration — 8.6 points, headlined in the changelog as “+12% accuracy.” It is a real improvement on a vendor-run evaluation, and it says nothing about how the framework performs against a model you supply yourself.

Ask anyone running a browser agent in production what breaks and almost nobody says planning. They say the login page. Authentication is the load-bearing failure mode across every framework in this comparison, and it is structural rather than a bug in any one project: the agent has to prove it is a specific human with a specific device, and none of the reasoning improvements of the last two years touch that problem.

One framework comparison found roughly six in ten attempts failing on login and two-factor flows without human-in-the-loop help — and the analyst relaying that figure called it fair criticism of every framework in the category rather than a knock on one vendor. Treat it as a directional signal from a single comparison, not a settled statistic; the useful part is the direction, which every other source in this post agrees with. It is also why WebBench’s read/write split matters more than another point of headline accuracy: the write tasks are the ones your workflow actually depends on.

Three workaround patterns have converged across 2026 deployments. None of them is elegant, all of them work, and the third is the one most teams underestimate when they scope the project.

The strategic read: choose workflows where authentication happens once and rarely, not workflows that hit a login wall on every run. A nightly extraction against a system you already hold credentials for is a good fit. An agent that logs into forty client dashboards each morning is a staffing plan wearing an automation costume. Our write-up on browser agents in marketing operations works through which recurring tasks survive that filter.

Licence cost is where most open-source comparisons stop, and it is the least interesting column. Every project here is free to download. What separates them is the infrastructure the free core deliberately does not include, and the engineering time to keep a self-hosted stack running against a web that changes underneath it.

Two cost details are easy to miss. Stagehand caches a successfully AI-resolved action as a selector, so repeat runs of a stable workflow decay toward native Playwright speed instead of paying for an LLM call on every step — which makes it structurally the cheapest of the three for high-frequency, low-variation jobs. And Skyvern’s AGPL-3.0 core carries genuine obligations if you distribute or expose a modified version as a network service; that is a conversation with your legal team before it is a conversation with your platform team. If you are weighing a self-hosted agent against a purpose-built internal tool, our web development engagements frequently start with exactly that build-or-adopt comparison.

Two constraints sit outside your framework choice entirely and will shape what you can deploy more than any benchmark number.

The first is detection. Skyvern disables the AutomationControlled Blink flag, suppresses the navigator.webdriver signal, and can detect and attempt reCAPTCHA v2 and v3, hCaptcha, Cloudflare Turnstile, FunCaptcha/ArkoseLabs and MTCaptcha. The vendor is explicit that solving is not guaranteed and can fail on novel challenges or rate-limited addresses. That honesty is the right posture, because the detection side has moved: an arXiv paper on multi-layer fingerprinting of LLM-driven browsing agents (arxiv.org/pdf/2606.30119) shows that combining HTTP and header signals, TLS/JA4 fingerprinting that catches Playwright, Selenium and Puppeteer signatures, and network-timing anomalies makes automated browsing identifiable. Spoofing a user agent is no longer evasion.

The practical consequence is a scoping rule rather than a technical fix: point browser agents at systems you own or are contractually permitted to automate, and expect friction anywhere else. If your business case depends on evading a site’s defences, you do not have an engineering problem, you have a compliance one.

Looking forward, the gap that closes first is probably not accuracy. The write-task benchmarks suggest the reasoning is already adequate for most commercial workflows; the blockers are identity, detection and injection, and all three are being addressed at the protocol and platform layer rather than inside agent frameworks. Expect the next meaningful step-change to come from agreed mechanisms for an agent to prove it is acting on a specific user’s behalf — not from another five points on a curated leaderboard. Teams building on this now should design for a staffed authentication step and be pleasantly surprised if it disappears. The same pattern is visible in open-source deep research agents, where access to sources — not synthesis quality — is the binding constraint.

Four situations cover most of what teams actually need. Match yours and the shortlist collapses to one, which is the point of sorting by control loop rather than by star count.

Whichever you pick, run the same evaluation before committing: twenty representative tasks from your own workflows, executed ten times each, scored on completion rather than on whether the agent looked busy. Two hundred runs is a day of work and it will tell you more than every benchmark in this post combined, because it measures the only sites that matter to you. That eval is also the artefact worth keeping — it is what lets you re-test cheaply when the next model lands. Our AI transformation engagements typically open with exactly this kind of comparative test before any framework is chosen.