Browser Use vs Stagehand vs Skyvern: Browser Agents 2026
One architectural choice, read the DOM or look at a screenshot, explains the cost, the failure modes, and which of these three you should be running.
The demo always works. You point a browser agent at a site, say “log in and download last month’s invoices,” and it does exactly that on the first attempt. Then you run it a hundred times against a real portal with a session timeout, a lazy-loaded table, and a modal that appears only on Tuesdays, and the success rate settles somewhere around 60%.
That gap is what actually separates these frameworks. Not the star count, not the benchmark number in the README. So this is Browser Use, Stagehand, and Skyvern from the angle that matters when you are the one getting paged: how each decides what to click, what that costs per run, and how it fails when the page moves.
These are not the same category as the consumer AI browsers. Those are products you use. These are libraries you build on, and they turn up in your dependency file, your token bill, and your incident channel.
Repo numbers and prices checked on 21 August 2026.
The choice everything else falls out of
Every browser agent answers the same question on every page: what is on this screen and what can I do with it.
Reading the DOM is cheap, fast, precise, and completely lost when a site draws its controls on a canvas or ships four thousand nested divs with hashed class names. Looking at a screenshot survives any markup at all and costs roughly an order of magnitude more per page view, plus a couple of seconds of latency each time.
Keep that in mind through the rest of this.
Browser Use: hand it the goal, get out of the way
The one everybody has heard of. Python, MIT, and just under 110,000 GitHub stars today, which puts it near the top of AI infrastructure repos by raw attention.
You hand it a task in plain English and a model, and the agent plans its own steps. It reads the page, decides to click the third result, notices the login wall, fills it in, keeps going. You write no selectors and barely any code.
from browser_use import Agent, ChatBrowserUse
agent = Agent(
task="Find the pricing page and extract every tier name and monthly price",
llm=ChatBrowserUse(),
)
result = await agent.run()The team publishes a leaderboard result putting it first on long-horizon web tasks, ahead of agents from the large labs. Treat that the way you would treat any vendor-run benchmark, since the harness and the task selection are both theirs. The ranking does match the shape of what it is good at: when the task is “go find this thing somewhere on this site,” this is the one that finds it.
Cost and determinism are where it hurts. Every step is a model call, so a thirty-step workflow is thirty round trips, and each one is a fresh opportunity for the model to get creative. Run the same task twice and you may get two different click paths. Fine for research. Miserable for anything you have to audit.
Browser Use Cloud adds proxy rotation, CAPTCHA handling, and persistent storage on top, with a free tier and paid plans from around $29 a month. Per-step cost depends on which model you point it at, so read the pricing page before you budget.
Pick it when the target site is unknown or keeps changing, the task is exploratory, and a few cents a run is noise.
Stagehand: code for the boring parts, model for the hard parts
From Browserbase, MIT, about 24,000 stars. An order of magnitude below Browser Use, which says more about marketing than engineering.
The philosophy inverts “give the agent the goal.” You write ordinary deterministic browser code and reach for the model only at the steps where the page is unpredictable. Three primitives carry it: act performs a natural-language action, extract pulls structured data validated against a schema, and observe tells you what is actionable before you touch anything.
await page.goto("https://example.com/invoices");
await page.act("click the date filter and select last month");
const invoices = await page.extract({
instruction: "get every invoice row",
schema: z.array(z.object({ id: z.string(), amount: z.number() })),
});That goto is plain code and costs nothing. The act call is where the model earns its keep. If 80% of a workflow is deterministic navigation and 20% needs judgment, the bill drops by roughly that ratio, and so does the variance, because the deterministic part does the same thing on every run.
Version 3 rewrote the engine to drive Chrome directly over CDP and dropped the Playwright dependency, which the team measured as a large speedup on complex DOM interaction. It also added action caching, so a step that worked once can replay without asking the model again. TypeScript is first class; the Python port trails.
The catch is that Stagehand assumes you know what the page looks like. You are writing a script against a known flow, and someone maintains that script when the flow changes. It also leaves more of the production layer to you: auth persistence, proxies, retry policy.
Pick it when you automate the same handful of sites over and over, you need runs to be debuggable, and the token bill matters.
Skyvern: for the sites that hate you
Python, AGPL-3.0, around 23,000 stars. Vision-first: agents look at rendered screenshots, work out what the page is, and act. No selectors, no per-site scripting.
That sounds wasteful until you meet the sites it exists for. Insurance portals. State licensing systems. Procurement platforms whose markup has not been touched in fifteen years. Where a DOM-based agent chokes on a table rendered in nested frames with no semantic structure, Skyvern just sees a table.
It also ships the unglamorous parts that turn a demo into a system: 2FA across TOTP, email and SMS, password manager integrations, a visual workflow builder, and a livestreamed viewport so you can watch a run instead of reading the logs after it failed. Self-hosting is a Docker Compose file, and you bring your own model, including a local one.
Two things to weigh. Vision means image tokens on every page and a couple of extra seconds per step, which compounds in both directions across a long workflow. And AGPL-3.0 is not MIT. Self-hosting internal automation, that is a non-issue. Embedding it in something you distribute or offer as a service, have legal read the license before you write the integration rather than after. The managed cloud exists partly to sidestep that, and it is also where the anti-bot handling lives, which is not in the open repo.
Pick it when the targets are legacy, hostile, or numerous, and the work is form-filling rather than open-ended browsing.
Side by side
| Browser Use | Stagehand | Skyvern | |
|---|---|---|---|
| Language | Python | TypeScript (Python port) | Python |
| License | MIT | MIT | AGPL-3.0 |
| Reads the page via | DOM, vision fallback | DOM over CDP | Vision |
| Control model | agent plans everything | you script, model assists | agent plans, vision-driven |
| Token cost per run | high | low | highest |
| Determinism | low | high | medium |
| Auth, 2FA, proxies | via cloud | bring your own | in the box |
| Best at | unknown sites | repeated known flows | legacy portals and forms |
Star counts move. All three repos had commits today. Check them yourself before quoting a number anywhere that matters.
About those benchmark numbers
You will see WebVoyager and WebBench percentages quoted all over this space, usually by whoever scored well. Read them with suspicion.
Each project runs its own harness, picks its own model, sets its own retry budget, and reports the configuration that worked. One framework claiming 89% and another claiming 64% may not be measuring the same thing at all. Worse, benchmark sites are public, stable and well structured, which is the exact opposite of the crusty internal portal you actually need to automate.
The only benchmark that predicts anything is ten runs of your real workflow against your real target. That is an afternoon per framework and it beats every leaderboard put together.
What teams end up doing
Not picking one. The recurring pattern is a split by site. Stagehand for the two or three high-volume flows that run hourly and need to be cheap and predictable. Skyvern for the long tail of weird portals nobody wants to write selectors for. Browser Use when somebody needs a one-off “go find out X” that is not worth scripting.
More moving parts than a single dependency, and usually still right, because the cost profiles are so far apart. A workflow that runs ten thousand times a day belongs in deterministic code with three model touchpoints. A workflow that runs twice a month against a site you have never seen belongs in a fully autonomous agent. Forcing both into one framework means overpaying for one of them.
Worth watching from the other direction: WebMCP and the browser-native agent APIs want to make this whole layer unnecessary by having sites expose their capabilities to agents directly, no screen-driving required. Early reports point at large token savings when a site cooperates. Cooperates is the operative word, and the legacy portal you are fighting with never will. Screen-driving is not going away this year.
If you are starting today, take the workflow costing you the most human hours and build it three times, once in each, with a stopwatch and a token counter running. The one that survives ten consecutive runs is your answer, and it will not necessarily be the one with a hundred thousand stars.