Introducing Stagehand v4: The SDK for browser agents.
Browserbase Blog ·
The authors introduce Stagehand v4, an SDK for browser agents, and describe its in-browser state management, domain-policy enforcement and shared core for language SDKs. They also report a single crawl comparing batch execution with Playwright and explain the limits of that measurement. Lisez 4 points de vue avec leurs éléments à l’appui et les liens vers les sources.
Miguel Gonzalez, Sean McGuire, Sam Finton, Harsehaj Dhami
The browser is the only real source of truth for page state; automation frameworks that maintain local mirrors risk acting on stale state, especially over remote connections.
In Stagehand v4, domain policy enforcement runs inside the browser extension rather than client-side, enabling true blocking of unauthorized pop-ups before they load—eliminating the v3 workaround of closing tabs after they open.
By moving state management (target handling, frame tracking, CDP dispatch) into a browser extension, Stagehand v4 reduces each SDK to a thin RPC client—enabling simultaneous TypeScript, Python, and Go releases and maintaining feature parity with single-core updates.
Faster batch execution in one crawl, with a measurement caveat
In one 50-action Wikipedia crawl reported by the authors, batch execution took 14,221.7 ms and Playwright took 22,650.3 ms, a 1.59x difference. Both completed all 50 actions. The authors stress that this was one run on one route from one client, rather than a benchmark.
In v4, target management lives in the extension. You set your domain policy and the enforcement runs inside the browser, so a blocked pop-up gets blocked and shows a blocked page. We removed the workaround.
The browser is the only real source of truth. Every framework that hands you a page object is betting that it can keep a local copy accurate and fast enough to be worth the usability. The bet is usually good enough . When it isn’t, your script acts on a page that has already moved on, and you get an error describing a browser that no longer exists.
Faster batch execution in one crawl, with a measurement caveat
Extrait original
We measured one 50-action Wikipedia crawl. Batch finished in 14,221.7ms against Playwright's 22,650.3ms, and both completed 50 of 50 actions. That works out to 3.52 actions per second versus 2.21, a 1.59x difference, with 44.0ms of overhead for the outer batch call.
By putting it in the extension, each SDK becomes a thin client over one RPC boundary. We ship a feature to the core implementation once and every language has it immediately, which is what made launching TypeScript, Python, and Go together possible and what keeps them at parity afterward.