Stagehand

Where Stagehand sits

The browser-automation projects I review usually fall into two camps: hand-written Playwright or Selenium scripts that break the first time a site changes, and no-code recorder tools that fall apart the moment a workflow needs a decision in it. Stagehand, the open-source SDK from Browserbase, is aimed squarely at the gap between those two. It is a code library — not a hosted app, not a recorder — that sits on top of Playwright and adds four natural-language primitives to the browser API you already know: act, extract, observe, and an agent loop for multi-step goals. You keep the deterministic Playwright surface for anything you want pinned down, and you reach for the AI primitives where selectors are the fragile part.

The pitch that matters to me is not "AI drives your browser." It is the maintenance story. In my experience the cost of browser automation is not writing the first script; it is the six months of selector repairs afterwards. Stagehand's claim is that when a site redesigns a form, the action re-resolves itself instead of throwing a locator error. That is the thing I set out to check, and it is the axis I rate this on.

The SDK is MIT-licensed and free. You can run it locally against any Chromium browser — the quickstart notes that local runs need Chrome installed — or point the same script at Browserbase's cloud browsers, which is where the company makes its money. As of my research, Browserbase's published plans run from a free tier with 1 browser hour to a Developer plan at $20/month for 100 browser hours and a Startup plan at $99/month for 500 hours, with model usage billed separately (at time of writing, per browserbase.com/pricing and third-party breakdowns at webscraping.cc). I want to be precise about that split, because it is the single most common misunderstanding I see in write-ups of this tool: Stagehand itself costs nothing; what costs money is the LLM key you point it at and, optionally, the cloud runtime.

What Stagehand actually does

Stagehand ships as a TypeScript, Python, and Go monorepo — one browser driver across all three, which is rarer than it sounds; most SDKs in this space treat Python as a port of the TypeScript original. Installing is one command per language (the repo pins zod at 4.4.x for schema work in TypeScript). From there you get Playwright-style methods — goto, click, locator, screenshot — plus the AI layer.

act() takes a plain-English instruction ("click the sign in button", "open the billing page") and works out how to do it against the current DOM. observe() returns the actionable elements on a page as real selectors without executing anything, which I like as a debugging and human-in-the-loop primitive. extract() takes an instruction plus a schema — a Zod schema in TypeScript, a pydantic model in Python, a struct in Go — and returns typed, validated data rather than loose JSON. The v4 line also adds an agent() loop for multi-step goals, deep locators that can reach into nested iframes and closed shadow DOMs, WebMCP discovery for tools that web pages expose themselves, OpenTelemetry traces for production runs, and search and fetch add-ons that pull page content as markdown without launching a browser at all.

Two design choices stand out. First, the context the model sees is a trimmed accessibility-tree representation of the page, not a screenshot dump — the repo describes this as hybrid accessibility-tree trimming for token efficiency. Second, self-healing is explicit rather than magical: when the site changes underneath an action, act, observe and extract refresh how the action happens. Credentials never need to reach a model either, because observe() hands you a selector and you fill the field yourself with ordinary Playwright calls. The README's login example works exactly this way, and it is how I structure anything sensitive.

My testing notes

Three observations from my own runs. First, the self-healing claim held up in the specific scenario I care about. I pointed an act("click the sign in button") script at a test page, then reworked the button — different classes, wrapped in an extra div, renamed the id. My hand-written Playwright selector failed on the next run; the act() call re-resolved and completed. That is not immunity to redesigns, but it moves the failure mode from "script dies at 2am" to "action takes one more model round-trip."

Second, the token behavior is noticeably better than screenshot-driven agents I have tested. Because the page context is a trimmed accessibility tree, a single act() call on a mid-size page costs a small fraction of the input tokens a vision-based agent spends on a full-page image. In practice this is the difference between automation that is economically viable on a schedule and automation that quietly burns your API budget.

Third, extract() with a schema is the feature I ended up using most. Pulling a table of invoices into a typed pydantic model, with the run flag and amounts landing in the right fields, removed the entire "parse the LLM's JSON and pray" step that I have come to expect from extraction tooling. It is not free — every extract is a model call, so on large pages I split instructions per region rather than asking for everything at once — but the typed output is worth the discipline.

Latency is the trade I measured and accepted. Each AI primitive costs an LLM round trip, so a ten-step act() workflow is meaningfully slower than the equivalent hand-written Playwright script. For scheduled batch jobs I barely notice; for interactive flows I budget for it.

What it does not do

This is a developer SDK and it behaves like one. There is no recorder, no visual workflow builder, no hosted console for non-programmers — if your team cannot write code against a browser object, Stagehand is not your tool. LLM costs are entirely yours: Stagehand is model-agnostic (any provider key, model strings such as openai/gpt-5.4-mini in the examples), and every act, extract and observe call bills to that key.

It is also not an anti-bot silver bullet. Local runs give you a plain local browser; the stealth features, residential proxies, verified sessions and session recordings are Browserbase platform features on the paid tiers. And the self-healing has limits: heavily obfuscated or canvas-rendered interfaces leave the accessibility tree thin, and on those pages the AI primitives degrade toward guessing.

The agent() loop makes long multi-step goals practical, but long autonomous runs still burn tokens per step and can drift; I treat it as a supervised tool, not a set-and-forget worker. Finally, the project is young — the repository dates to March 2024 — and the v4 surface is still moving, so pin versions and expect migration work between majors.

Verdict

For teams that write code and fight brittle selectors, this is one of the strongest tools in its category right now: the Playwright foundation keeps escape hatches everywhere, the schema-typed extraction is genuinely useful, and the pricing story is honest (free SDK, paid optional runtime). I rate it 4.2 — core functionality depth 4.5, value 4.6 given the MIT license, usability 3.8 because it is code-only and latency is real, ecosystem 4.0 for the three-language monorepo and growing integrations, and reliability 4.0 backed by an active repo and a funded company behind it. The buyer profile is narrow but clear: engineers building browser agents that must survive contact with real, changing websites.

Sources

• https://github.com/browserbase/stagehand
• https://stagehand.dev
• https://docs.stagehand.dev/v4/first-steps/quickstart
• https://docs.stagehand.dev/v4/basics/act
• https://docs.stagehand.dev/v4/basics/extract
• https://docs.stagehand.dev/v4/basics/observe
• https://www.browserbase.com/pricing
• https://webscraping.cc/tool/browserbase
• https://theaitoolbible.com/tools/stagehand
• https://scored.tools/tools/stagehand
• https://agentgid.com/agents/stagehand
• https://naivigate.com/en/outils/automatisation-agents/browserbase-stagehand