# Stagehand v4: Browser Agent SDK Now 2x Faster > Source: > Published: 2026-08-14 01:08:56+00:00 Stagehand v4 shipped on August 10 with a change that sounds minor but fixes the worst bug in remote browser automation: the SDK’s core — state tracking, CDP dispatch, target management — moved out of the client and into a browser extension. For the first time, the agent’s view of the page is not a stale copy. It is the live truth. ## Why the Old Model Kept Breaking Playwright was built for tests. When you write a test, you control the page and the timing. When an AI agent uses Playwright, it does not. The agent issues commands across a network connection to a remote browser, and the client holds a mirrored state that lags behind. Every action risks hitting a stale reference. The result is the error every browser-automation developer knows by heart: `Target page, context or browser has been closed` . Stagehand v3 improved on raw Playwright but inherited the same fundamental architecture. The SDK still maintained a client-side mirror. The round-trip cost per CDP call measured 42.2ms. That adds up fast across a 50-action agent task. v4 eliminates the mirror. The extension runs as a service worker inside the browser itself. State queries get answered directly from the live page. The client-side lag is gone, and so is the primary cause of those “Target closed” crashes. ## The Performance Numbers Browserbase ran a 50-action Wikipedia crawl to benchmark the difference. Stagehand v4 finished in 14,221ms (3.52 actions per second). Playwright finished in 22,650ms (2.21 actions per second). That is a 1.59x improvement — close enough to the headline “2x faster” claim to matter in production. The per-action picture is more striking: **waitForSelector:** 493ms → 238ms (52% faster)**click:** 628ms → 323ms (49% faster)**goBack:** 139ms → 17ms (87% faster) Token efficiency improved by roughly 80%. The accessibility tree pruning now runs inside the extension, against the live DOM. Because the pruning no longer acts on a serialized copy that crossed the network, it can be more aggressive — and delivers a smaller, cleaner context to the model. ## Python and Go Are First-Class Now This is the part that matters most if you are building AI agents in Python. Stagehand v4 ships TypeScript, Python, and Go SDKs simultaneously at full feature parity. The Go SDK is new — v4 is its debut. The mechanism that makes this work: all three languages wrap the same browser extension core. A feature lands in the extension once, and all three language SDKs have it immediately. Previously, the Python SDK lagged the TypeScript one. That is no longer the case. If you are building a browser agent inside a [LangChain](https://python.langchain.com/docs/introduction/), [CrewAI](https://www.crewai.com/), or [Mastra](https://mastra.ai/) workflow — all Python-heavy ecosystems — you can now use Stagehand without switching languages or accepting a slower feature set. ## What Breaks in the Migration The Browserbase team says most v3 scripts migrate unchanged. That is roughly accurate, but the initialization lifecycle has flipped — and it will break your setup code if you miss it. In v3, Stagehand launched the browser internally. In v4, you launch the browser first, then hand it to Stagehand: ``` js // v4 — browser launches before Stagehand wraps it const browser = await localBrowser({ headless: true }); const stagehand = await Stagehand.create({ browser, model: { modelName: "openai/gpt-4-mini", apiKey: OPENAI_API_KEY } }); const page = await stagehand.activePage(); // now async await page.goto("https://example.com"); await stagehand.act("click the login button"); const { data } = await stagehand.extract("get the user email", schema); ``` Three additional changes to catch before upgrading: **Unified Locator:**`agent()` ,`deepLocator()` , and`frameLocator()` are replaced by a single`Locator` abstraction.**Async getters:**`activePage()` and`activeContext()` now return Promises. Wrap them in`await` .**Custom models:** Implement a single`model: { generate(params) }` interface instead of the previous config approach. ## New Capabilities in v4 Cross-origin iframes and nested iframes now work without selector gymnastics. Shadow DOM — including closed roots — is addressable directly. [WebMCP](https://webmcp.io/) support means that if a page exposes structured tools to agents, Stagehand can drive it through those tools instead of raw DOM clicks. Clipboard support adds real copy/paste workflows. Batch mode dispatches multiple commands in a single extension round-trip, reducing overhead further for high-action tasks. ## Stagehand vs Playwright: Stop Conflating Them Playwright is the right tool for CI test suites on stable page structures: sub-100ms clicks, zero LLM cost, near-100% reliability when the selectors hold. It was not designed for agents and it shows the moment an agent tries to navigate a page it has never seen. Stagehand is the right tool when the agent’s task is navigating pages it has never seen. Self-healing selectors, native iframe and Shadow DOM support, structured extraction with Zod schemas, and now near-native speed on remote browsers. The LLM cost is real — $0.002 to $0.02 per action — but compare it against the engineering hours of maintaining selectors every time a design system ships an update. To try it: ``` npm install @browserbasehq/stagehand # or pip install stagehand ``` Full documentation lives at [stagehand.dev](https://www.stagehand.dev/). The architectural writeup behind v4’s extension design is on the [Browserbase blog](https://www.browserbase.com/blog/stagehand-v4). The [GitHub repo](https://github.com/browserbase/stagehand) is MIT-licensed with 23.9k stars.