Stagehand 4.0.0 mixes locators with three model-driven commands
Stagehand 4.0.0 exposes ordinary browser methods such as goto, locator, click, and screenshot, then adds act, observe, and extract. An agent can ask what is clickable, carry out an instruction, or return data checked against a schema. TypeScript, Python, and Go clients talk to an extension inside Chrome over the Chrome DevTools Protocol. That split keeps the page runtime close to the browser while the SDK stays in the application process.
This is a sizeable implementation of that idea. Our commit contained 1,222 files, roughly 181,037 lines of source, and 49.4 MB before dependencies. The monorepo holds the protocol, extension, three public SDKs, documentation, evaluation tools, and agent integrations. Protocol models generate into Python and Go, so a wire change crosses language boundaries. A contributor cannot treat the TypeScript package as the whole project.
A local Chrome path exists, but model inference still needs a home
The v4 quickstart uses Browserbase and requires one Browserbase API key. Its model gateway selects and authenticates a model for act, observe, and extract, which avoids a second provider account. Stagehand can also launch Chrome locally, and the Python README demonstrates that route. Local browsing removes the hosted-browser key, while model-backed commands still require a configured provider or another approved model endpoint. Plain locator calls can run without asking a model to choose an action.
Building the repository asks for Node 22.18 or later, Go 1.26, pnpm, Python tooling, uv, and just. Our pnpm-focused sandbox installed 1,444 packages and occupied 1,595 MB. Local Linux execution also needs Chrome or Chromium plus system libraries including NSS, GTK, XSS, and ALSA packages listed in the browser guide. The source checkout is manageable on a workstation, but it is a poor fit for a tiny build image.
What happened when we ran it
Our sandbox installed Stagehand at commit 13c845e in 58 seconds, then completed the build in 41 seconds. Installation added 1,444 packages and left 1,595 MB on disk. The checkout used a Node 22 image with 3 CPUs and 8 GB of RAM. It had 6 CI workflow files, no Dockerfile, no root tests directory, and workspace packages spread through the monorepo.
The top-level test step exited 1 after 23 seconds. The lab summary counted 2 Vitest tests passed and 0 failed. In the same log tail, the browser task marked 2 test files failed, skipped 1 file, and skipped all 34 browser tests. The output does not identify an individual failed browser assertion, so we cannot say why those files failed. The decision-grade result is simpler: the repository test command did not pass in our fresh container.
It cannot replace Playwright for PDF and network-heavy jobs
Open issue #2744 documents a Stagehand 4.0.0 migration covering 15 automation scripts. The reporter says 13 remained blocked by missing APIs, including page.pdf(), request and response events, browser emulation, device presets, request interception, and several Playwright locator helpers. That report does not mean Stagehand fails at every Playwright job. It does show that similar method names do not amount to complete API compatibility.
The better use is selective. Keep direct locators for known elements and use observe or self-healing actions where page structure changes often. Then check the final URL, submitted value, downloaded file, or extracted schema in ordinary code. In the 15-script report, selector repair helped two brittle pipelines, yet 13 scripts still needed APIs outside Stagehand's current surface. That is a useful boundary for buyers, not a minor missing-method list.
Browser ownership and trace defaults need an explicit policy
The v4 quickstart closes Stagehand and the browser in nested cleanup blocks. The root TypeScript example does not. Open issue #2726 says copying that shorter example can leave a billable Browserbase session active until its timeout and may retain an uploaded extension. Python documentation also warns that keep_alive=True changes close() into a disconnect. Production code should record who created each browser, who releases it, and whether a surviving session was intentional.
Telemetry deserves the same review. Open issue #2732 reports that an omitted v4 telemetry setting defaults an OTLP trace exporter to https://example.com/v1/traces; the issue was still open with 0 comments when fetched. We did not reproduce that request in the lab, so treat it as a specific unresolved report rather than a measured behavior. A team with outbound-network controls should inspect the current protocol defaults and set tracing explicitly before rollout.
September activity is high, while v3 and v4 records overlap
GitHub showed 24,134 stars, 98 open issues, and 245 open pull requests. The last push was September 2, 2026, and issue activity covered v4 initialization, browser API gaps, Windows tests, telemetry, and integrations. The repository is being worked on daily. A queue with 343 issues and pull requests also takes sorting; the combined count is not a bug total.
GitHub's latest SDK release endpoint returned 3.7.3 from August 28, while the main workspace identifies itself as 4.0.0 and the current docs lead with v4. Pin the package and read its matching documentation instead of treating main as the installed release. Stagehand earns a trial when self-healing can save repeated selector repair. Our 1,595 MB install, failed test command, and the 13-of-15 migration gap make it a companion to direct automation today, not its wholesale replacement.