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. Read 4 viewpoints with supporting evidence and source links.

Miguel Gonzalez, Sean McGuire, Sam Finton, Harsehaj Dhami

Understand this piece

4 key points

Synthesis

  1. Browser as sole source of truth

    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.

    Supporting evidence 1

    Original excerpt

    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.

    Miguel Gonzalez, Sean McGuire, Sam Finton, Harsehaj Dhami · Paragraph 4

    Read in source context →
  2. In-browser domain policy enforcement

    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.

    Supporting evidence 1

    Original excerpt

    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.

    Miguel Gonzalez, Sean McGuire, Sam Finton, Harsehaj Dhami · Paragraph 11

    Read in source context →

    Continue exploring

    security architecture →
  3. Shared core enables cross-language feature parity

    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.

    Supporting evidence 1

    Original excerpt

    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.

    Miguel Gonzalez, Sean McGuire, Sam Finton, Harsehaj Dhami · Paragraph 18

    Read in source context →

    Continue exploring

    SDK architecture →
  4. 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.

    Supporting evidence 1

    Original excerpt

    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.

    Miguel Gonzalez, Sean McGuire, Sam Finton, Harsehaj Dhami · Paragraph 38

    Read in source context →

Key passages4

Attributed passages with the context to verify them. Open the original text to check the source.

browser automation state consistency

Browser as sole source of truth

Original excerpt

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.
performance benchmarking

Faster batch execution in one crawl, with a measurement caveat

Original excerpt

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.
SDK architecture

Shared core enables cross-language feature parity

Original excerpt

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.

Source & methodology

These viewpoints are linked to their original sources. Paraphrases are labeled and are not verbatim quotes.

Open transcript or source material (opens in a new tab)Report an issue

Continue with this topic

More sources on topics discussed here. Shared topics do not imply agreement.