browser-use vs stagehand: a Python agent that drives Chrome versus a TypeScript SDK that wraps Playwright
browser-use hands an LLM a live Chrome browser and a task to finish; stagehand gives you Playwright-style methods with natural language act, observe and extract calls layered on top. They are adjacent rather than identical: browser-use decides what to do, stagehand helps you write the code that does it.
At a glance
| Project | browser-use/browser-use | browserbase/stagehand |
|---|---|---|
| Licence | MITPermissive: commercial use allowed | MITPermissive: commercial use allowed |
| Maintenance | Commits in the last six monthsLast push September 26, 2026 | Commits in the last six monthsLast push September 25, 2026 |
| Language | Python | TypeScript |
| GitHub stars | 116,719 | 25,387 |
| Read more | Our analysisGitHub | Our analysisGitHub |
Which one to choose
Choose browser-use if you are writing Python that has to operate a site with no API, if you want an existing coding agent such as Claude Code or Cursor to reach the browser through the CLI skill, or if you want the agent loop itself rather than a set of primitives. Do not choose it for high-volume scraping of static pages, and do not choose it if every run costing LLM tokens or failing on a captcha is unacceptable.
Choose stagehand if you are building a browser agent in TypeScript, Python or Go and you already accept an LLM provider key plus Browserbase credentials, and if you want Playwright-style control with self-healing act, observe and extract calls. Do not choose it if you need fully deterministic automation or want to avoid cloud dependencies.
Who decides the next step: the model or your code
The core difference is where the loop lives. browser-use is a Python library and CLI that drives Chrome through the Chrome DevTools Protocol so an LLM can click, type and fill forms. You hand it a task string and an LLM, and the agent decides the sequence of actions itself. The README example is a single Agent object with a task and a model, followed by agent.run(). The README also states that Browser Use is number one on the Odysseys leaderboard with an 87.4 percent average across 200 long-horizon web tasks, and that the open-source agent and the hosted cloud agent are benchmarked separately across 100 real-world tasks, with the cloud agent described as the more powerful one for complex tasks.
stagehand inverts that. Its README calls itself the SDK for browser agents and says Playwright was built for testing while Stagehand is built for agents. You still write the program: goto, click, locator and screenshot are the familiar Playwright-style methods, and act, observe and extract are the natural language additions. The README states that when sites change, Stagehand detects it and refreshes how the actions happen on the page automatically. So browser-use asks the model to plan the whole run; stagehand asks the model to resolve individual steps inside a program you control. That is the line to hold onto when reading the rest of this page.
Getting each one running
browser-use needs Python 3.11 or newer according to its README, and its quickstart installs with uv add browser-use or pip install browser-use. You need an LLM key. The README shows BROWSER_USE_API_KEY for the Browser Use Cloud key, and also lists GOOGLE_API_KEY and ANTHROPIC_API_KEY as bring-your-own-provider options. The README's agent-oriented path is different from the library path: you paste a prompt into Claude Code, Codex, Cursor, Hermes or OpenClaw, and the agent is told to install browser-use with uv using Python 3.12, run browser-use skill install to register the skill, and connect to your browser. If setup or connection fails, the README points at a separate install document. Notice the version mismatch in the README itself: the library section says Python 3.11 or newer, while the prompt it tells you to paste specifies Python 3.12. Verify which one your environment satisfies before you start.
stagehand is a TypeScript, Python and Go monorepo, built with just driving pnpm, uv and go together. The README's build-from-source path is git clone, just install, just generate, just build. Its example imports browserbase and Stagehand from @browserbasehq/stagehand, launches a browser through browserbase.launch with BROWSERBASE_API_KEY, creates a Stagehand instance with a model name and OPENAI_API_KEY, then calls browser.context.pages() and page.goto. The README says Stagehand is best when you have an API key for an LLM provider and Browserbase credentials, and tells you to export both. That is a heavier setup than browser-use's single library install, and it is a deliberate one: the Browserbase credentials are part of the intended path, not an optional extra.
Where the tokens and the latency go
Both projects spend LLM tokens, but they spend them differently. browser-use spends them on the planning loop: the agent looks at the page, chooses an action, looks again, and repeats until the task is done. Every step in that loop is a model call, which is why the earlier analysis warns that every run costs LLM tokens. The README's own framing supports this: the hosted cloud agent is described as much more powerful for complex tasks, with the open-source agent positioned as the free option that runs on your own machine with deep code-level control. The README recommends pairing the open-source agent with cloud browsers for stealth, proxy rotation and scaling, which tells you the open-source path is not the one with the scaling story built in.
stagehand spends tokens on resolution rather than planning. Its README lists token efficiency as a priority and describes a hybrid accessibility tree trimming that gives agents exactly what they need to understand the page and nothing more. It also states that Stagehand runs as an extension next to the browser, closing the distance and reducing round-trip latency for all actions on the page. The self-healing primitives are the trade: act, observe and extract resolve at run time, so a site change does not necessarily break the script, but the resolution is a model call and the earlier analysis notes that self-healing primitives trade some determinism for adaptability. Neither project publishes a per-task token figure in the excerpts here, so treat any cost estimate as something you measure on your own flows.
Operations, credentials and scaling
browser-use's operational surface is the browser and the model provider. It drives Chrome over the Chrome DevTools Protocol, so the browser has to be reachable, and the README's remote browser documentation is the path it recommends for stealth, proxy rotation and scaling. On the hosted side, the README shows a single curl call to an api.browser-use.com runs endpoint with an X-Browser-Use-API-Key header and a task in the body, and lists persistent filesystem and memory, more than 1000 integrations, and rerunnable scripts that fetch live data even when sites change. The README does not document rollback, retry policy or rate limits for that endpoint, and it does not document what happens to a run when the model provider is unavailable. If you need those guarantees, they are not in the source here.
stagehand's operational surface is broader because Browserbase is in the default path. You supply BROWSERBASE_API_KEY and an LLM provider key, and the README's example launches the browser through browserbase.launch. The README lists WebMCP, clipboard support, batch commands, deep locators for nested iframes and OTel support as features agents need. OTel support matters if you already have tracing; the README does not describe the span structure or what is exported, so check that against your observability stack. The README also mentions native support for out-of-process iframes and closed Shadow DOMs, which is the kind of DOM that breaks naive selectors. What the README does not give you is a story for running without Browserbase: the earlier analysis is explicit that you should not use it if you want to avoid cloud dependencies.
Where each one is the wrong tool
browser-use is the wrong tool for high-volume scraping of static pages. An HTTP client is cheaper and deterministic, and the earlier analysis says so directly. It is also the wrong tool if you cannot accept that every run costs LLM tokens and can fail on a captcha; the README lists captcha solving as a feature of the hosted cloud agent, not of the open-source agent, so the open-source path inherits that failure mode. The README's own accuracy plot is worth reading before you assume the open-source agent and the cloud agent behave the same, because the README says they do not.
stagehand is the wrong tool if you need fully deterministic automation. Self-healing means the action can be re-resolved, and re-resolution is a model call, so a run is not bit-for-bit reproducible in the way a Playwright script is. The earlier analysis also warns against it if you want to avoid cloud dependencies, because the README's default path needs Browserbase credentials. There is a version risk too: the earlier analysis says to confirm that the v3 API in the README matches the version you plan to deploy, and the release list here shows both a stagehand-server-v3 line and a @browserbasehq/stagehand line moving on the same day, which is a reminder that the server and the SDK are versioned separately.
Licence and maintenance, read from the facts
Both projects are MIT licensed, which is the permissive outcome most teams want, and neither repository is archived. The difference is cadence. browser-use's last push was 2026-09-15, two days before today, and its recent releases run 0.13.6 on 2026-07-17, 0.13.7 on 2026-07-27 and 0.13.8 on 2026-08-16. stagehand's last push was 2026-09-16, one day before today, with stagehand-server-v3/v3.7.5 on 2026-08-20, stagehand-server-v3/v3.7.6 and @browserbasehq/[email protected] both on 2026-08-28. Both are being pushed to within the last few days, so neither falls into the archived or stale category, and the six-month test does not catch either one.
Two maintenance details are worth separating from the cadence. First, browser-use's own earlier analysis carries a last push of 2026-08-16, while the repository facts here say 2026-09-15. That is a discrepancy in the sources, not a sign of inactivity, but it is a reason to check the branch you actually track. Second, stagehand ships a server and an SDK on separate version lines, so an SDK upgrade does not automatically tell you which server version you are talking to. The README does not document a compatibility matrix between the two. If you pin versions, pin both.
Scenarios, and when to use both
If you have a Python service that must operate a site with no API, and the task is open-ended enough that you cannot write the click path in advance, browser-use is the direct fit: one Agent object, one task string, one model, and the loop is handled for you. If you already work inside a coding agent, the CLI skill path is the lighter integration, because the README's prompt does the install and registration for you. If you are scraping static pages at volume, neither project is the answer; use an HTTP client.
If you are building a production browser agent in TypeScript, Python or Go and you want to keep writing the control flow while letting the model resolve the fragile parts, stagehand is the fit. The Playwright-style methods keep the code legible to engineers who already know Playwright, and act, observe and extract absorb the changes that would otherwise break selectors. If you need tracing, the OTel support is in the README's feature list; verify the exported spans against your stack. If you cannot take a Browserbase dependency, this is the point where stagehand stops being the right choice.
The two are not strictly competitors. browser-use is the agent that decides what to do; stagehand is the SDK that makes the doing more resilient. A team that wants both could let browser-use own the task loop and use stagehand-style primitives in the code it calls, though neither README documents that combination, so treat it as something to prove rather than assume.
Bottom line
Pick browser-use when the task itself is the unknown and you want a Python agent to work it out on a live Chrome browser; pick stagehand when the task is known and the page is the unstable part, and you want Playwright-style code with model-resolved steps. Verify first: for browser-use, your Python version against the README's 3.11 versus 3.12 mismatch, which provider key you hold, and the accuracy plot that separates the open-source agent from the cloud agent. For stagehand, verify the self-healing behavior on your own flows, the OTel and WebMCP support against your stack, that the v3 API in the README matches the version you will deploy, and that you are willing to carry Browserbase credentials. Both are MIT licensed and both were pushed to within the last two days, so the decision is about architecture and dependencies, not about which project is alive.