What Is Stagehand? The Browser Agent SDK That Removed Its Agent

Stagehand is an open source library (MIT) from Browserbase that lets a program, usually an AI agent, drive a Chrome browser using natural-language instructions instead of CSS selectors. Version 4, released on August 10, 2026, is a full rewrite: it drops Playwright as a dependency and moves its engine inside the browser itself, as a Chrome extension. And it does something almost nobody has reported: it removes the agent() method, the primitive for launching an autonomous agent.

Yes: the SDK announced as "the SDK for browser agents" is the same one that deleted its agent function. That isn't a marketing contradiction: it's a defensible engineering decision, and explaining it properly is half of this article.

Disambiguation. If you landed here looking for something else: a stagehand is a theater crew member. There's also a character in Don't Starve Together, a Pioneer DJ product, and a live-music app by that name. This article is about the developer SDK.

How we verified this. Checked on August 13, 2026 against primary sources: the GitHub repository, the published npm and PyPI packages (including tarball contents), the official migration guide, Browserbase's engineering blog, the Hacker News API, and each cited product's pricing page. We have not run Stagehand in production: where we describe behavior, we're describing what the code and documentation say. Pricing changes, so check before you buy.

What problem does Stagehand solve?

Browser automation has always worked the same way: you tell the program exactly which element to touch. page.click("#submit-button"). Works perfectly until someone changes the id, and then it breaks.

For an automated test that's fine: if the page changed, you want to know. For an AI agent it's a disaster, because the agent doesn't know the HTML ahead of time and can't predict selectors.

Stagehand proposes the opposite: describe what you want to achieve in natural language and let it find the element. Three primitives:

The underlying idea is that you can mix: deterministic code where the page is stable and cheap to traverse, natural language only where you need it. That's the sensible part, and it's their best argument.

What exactly is version 4?

Here's the real change, and it isn't any of the three things the launch tweet advertises.

In v3, Stagehand was a layer on top of Playwright. Its package.json declared playwright-core as a dependency, plus puppeteer-core, patchright-core, and sixteen optional AI-provider dependencies.

In v4, Playwright is gone. The package has five dependencies and none is Playwright or a model provider. It shrinks from 1,174 files and 10.1 MB to 16 files and 3.37 MB.

Where did the engine go? Inside the browser. Stagehand v4 installs a Chrome extension (Manifest V3) called Stagehand Runtime that lives as a service worker. The SDK and the extension talk over JSON-RPC inside the CDP connection that was already open, without opening a second port.

And that's the honest explanation for the token savings. In v3, to know what was on the page you had to serialize the accessibility tree, send it over the network, and prune it on the outside. In v4 pruning runs inside the extension, against the live tree. Since there's no risk of working from a stale copy, they can prune far more aggressively. Less tree sent to the model, fewer tokens.

That's a real technical argument you can explain in a classroom. It's much better than the slogan.

The API still looks like Playwright

goto, click, locator, screenshot: the ergonomics stay, but underneath it speaks raw CDP. One nice side effect: Bun works without warnings, precisely because there's no Playwright underneath anymore.

Why did they remove agent()?

The official v3 → v4 migration guide says it plainly: agent() is gone and nothing in v4 replaces it one-to-one. The bundled orchestrator goes away and flow control returns to the programmer.

Browserbase's stated reason is simple: every step of that agent was an inference call. Expensive, slow, and hard to debug.

They recommend two patterns instead:

Code mode. Have a coding assistant write a Stagehand script, then you run that script. Intelligence is spent once, at authoring time; execution is deterministic and repeatable.

Tool calling. Expose the full API surface to the model as discrete tools, rather than three broad ones.

There's a warning in their documentation worth reading twice, and it applies to any agent automation:

Scale retries on observe(), never on act(): a failed act() may already have clicked, submitted, or paid before the error surfaced.

Our read: removing agent() is probably right, and it matches where the whole sector is heading: use the model to write the automation, not to execute each step. But announcing the version that removes the agent primitive as "the SDK for browser agents" is, at minimum, an unfortunate headline.

The launch numbers, checked

Precision matters here, because the figure making the rounds isn't the one their own engineering team published.

What the website says: v4 is "2x faster than Playwright" and "80% more token efficient."

What their engineering blog says, the same day: 1.59x on a single 50-action Wikipedia crawl: 14,221.7 ms versus 22,650.3 ms. Plus an explicit disclaimer: treat it as one run rather than a benchmark.

Three more caveats, all from the same source:

• The measurement uses batch commands, a feature that same post calls experimental.
• None of the 50 actions invokes an AI model. It's a comparison of network plumbing, not agentic capability.
• The text itself concedes that the advantage shrinks if the browser runs on your laptop rather than in the cloud.

There is no independent measurement. If you see "2x" repeated elsewhere, it comes from the vendor's homepage, not their lab.

"Self-healing" isn't new, and it now ships off

The tweet presents it as one of three new features. Checked in the code:

• It already existed in v3, and there it was on by default.
• In v4 it's a selfHeal boolean that ships disabled by default in the action service.
• It isn't magic selector repair: it's a single retry that recaptures the accessibility tree and re-infers the action with the model.
• It's deliberately disabled when replaying cached actions and inside batches.

And there's an uncomfortable data point the company published itself: one of their own pull requests, dated thirteen days before launch, acknowledges v4 was developed without the feature and publishes their internal numbers: 93.89% action accuracy on v3 versus 78.83% on v4 in their own eval.

Combine that with their own warning about not retrying act(), and the practical conclusion is: if you're on v3, measure before migrating.

Where it genuinely wins (and this part is new)

Strip the noise and two solid advantages remain that almost nobody has covered.

1. Out-of-process iframes, nested iframes, and closed Shadow DOM. page.locator() crosses iframe boundaries with hop notation:

page.locator('iframe#checkout >> button.submit')

Chain as many as the page nests, and it resolves deep XPath like /html/body/iframe[2]//div. It also covers closed-mode shadow roots, which is where Playwright doesn't reach.

If you've ever fought a checkout buried in a third-party iframe, you know exactly what that's worth.

Under-advertised limitation, from their own docs: resolving closed roots relies on privileged APIs that don't exist on about:blank or data: URLs. You have to navigate to an http/https URL first.

2. Real parity across TypeScript, Python, and Go. Because all three are thin clients over the same extension, there's no per-language reimplementation. Stagehand is currently the only serious agentic layer with Go. Browser Use is Python only; Skyvern is Python with a TypeScript SDK.

With a distribution caveat: TypeScript and Python both published 4.0.0 on August 10 two minutes apart, but the Go module has no version listed in the official proxy as of August 13, only a commit pseudo-version. The install command in their own documentation doesn't work yet.

One table that needs correcting

The comparison table on Stagehand's website marks Playwright with a "no" for Shadow DOM and iframe support. That isn't accurate.

Playwright's documentation states that all its locators work with elements in Shadow DOM, it ships frameLocator, and Microsoft maintains a dedicated test suite for out-of-process iframes.

The real difference (which Browserbase itself describes more precisely on another of its own pages) narrows to two cases: closed-mode Shadow DOM roots and the XPath that traverses them. That's a genuine, narrow technical edge. It didn't need overstating.

What does it cost?

The SDK is MIT and free, verified in the repository's LICENSE, on npm, and on PyPI. It runs locally against your own Chrome.

What costs money are two layers the headline doesn't mention:

And two features only exist if the browser is Browserbase's: automatic model routing (Model Gateway) and the server-side cache that makes repeated calls cheaper. Locally they have no effect.

Security note, from their own documentation: act() variables aren't shared with the model provider (only the name is passed and substitution is local), but with server-side caching enabled the real values travel to the cache service. Turn caching off for calls carrying credentials.

Models: five first-class providers callable by name (OpenAI, Anthropic, Google, Groq, Cerebras), always with a provider/model prefix. Anything else goes through your own callback, running in your process with your credentials. Note: the SDK validates the model name against a list of known IDs before sending anything, so a brand-new model requires an SDK update.

Requirements: Chrome or Chromium installed (Chromium engines only, no Firefox or WebKit), Node ≥ 22.18.0 (pure ESM, no require), Python ≥ 3.11, Go 1.26.0.

Where does Stagehand fit?

This is the most common confusion, and the tweet feeds it. Stagehand is not an agent and not a browser: it's the layer an agent uses to touch the browser. It competes with Playwright, not with autonomous agents.

Four layers coexist today that coverage constantly conflates:

Plus a fifth cross-cutting axis: browser infrastructure (Browserbase, Cloudflare Browser Run), where the Chrome actually runs.

The comparison

⚠️ Watch Skyvern: AGPL-3.0 is strong copyleft. If you're embedding it in a service, run it past whoever handles legal.

And here's their distribution problem. For the "I want my agent to browse" use case, Microsoft and Google already give the default away: Playwright MCP and Chrome DevTools MCP total 85,000 stars between them, they're free, they have no vendor attached, and they're already installed in Cursor, Claude Code, and Copilot. Stagehand has to earn every install.

Did anyone care about the launch?

Two things worth separating, because the tweet blends them.

The v4 launch didn't move the needle. Its Show HN, posted by a project maintainer, stood at 2 points and no comments three days later (checked via the Hacker News API on August 13). For calibration: Stagehand's original Show HN in January 2025 did 326 points, and Cloudflare's Kitesurf, launched three days earlier, did 220. There's also no GitHub release page for v4, and no tech-press coverage we could locate.

The project, on the other hand, has real adoption. 23,926 GitHub stars and 1,249,587 weekly npm downloads, a figure that has tripled in eleven months.

Two caveats for reading that million properly: npm downloads include CI, mirrors, and reinstalls, so it's a ceiling rather than a developer count. And Playwright logged 80.1 million that same week: 64 times more.

One detail from the tweet itself says a lot: 249,699 views against 406 likes is a 0.16% ratio, well below normal for developer tooling. But 378 bookmarks against 406 likes is the classic "saving this to try later" pattern, not "this excites me." Cold technical interest, not enthusiasm.

When to use it, and when not to

If you're learning to code

Three things this launch teaches better than most tutorials.

One: reading the migration guide tells you more than reading the announcement. Everything that matters in this article came from diffing v3's package.json against v4's and reading the migration document. No contacts, no early access. That's a trainable skill and it separates you from the pack.

Two: deterministic where you can, intelligent where you must. Stagehand's best idea isn't the AI: it's that you can mix. A plain click() costs milliseconds and zero tokens; an act() costs a model call. Knowing when to use which is engineering judgment, and it's what you get paid for.

Three: read vendor benchmarks with a magnifying glass. Here the website says 2x and the same team's engineering blog says 1.59x, on a single run, with no AI involved, carrying a written disclaimer. You don't need to distrust anyone, you just need to open the source.

If you want to be in the layer that designs these systems (agent architecture, orchestration, evaluation), that's what 4Geeks Academy's AI Engineering for Developers program works on. And if you're deciding which tool to adopt, we keep a comparison of AI coding agents current.