Related Pages

Related topics: Core Automation Engine: act, extract, observe, and agent, LLM Provider Layer and AI Agent System, CLI, Server Runtime, and Framework Integrations

Repository Overview and System Architecture

Purpose and Scope

Stagehand is an AI-powered browser automation framework maintained by Browserbase. It exposes a programmatic TypeScript API (@browserbasehq/stagehand) and a separate agent-facing CLI (browse) that wrap Playwright, Puppeteer, and Patchright, while delegating reasoning to an LLM provider. The repository contains both the runtime library and the supporting infrastructure (HTTP server, CLI, function tooling) needed to drive a real browser from either code or an autonomous agent.

The project README frames the contributor priorities as "reliability, extensibility, speed, and cost" (README.md) — a useful lens for understanding the architectural boundaries. The current published release is @browserbasehq/[email protected], and the repo targets Node ^20.19.0 || >=22.12.0 (package.json).

Monorepo Layout

Stagehand is a pnpm workspace orchestrated by Turborepo. The root package.json declares the Node engine constraints and central pnpm overrides for transitive dependencies (e.g., axios, lodash, hono, playwright), keeping the supply chain consistent across packages. Source: package.json.

The high-level package map is:

Turborepo enforces the dependency graph: core#build:esm runs gen-version and build-dom-scripts first, and the server packages consume the ESM build of core before generating their OpenAPI specs. Source: turbo.json.

Core Architecture

The runtime is split into a public surface and a v3 implementation tree. The exported entry point in packages/core/lib/v3/v3.ts is what most consumers touch, while packages/core/lib/v3/index.ts aggregates the public API. Internally, the LLM client is pluggable, and the browser driver is pluggable — the same Stagehand class can be backed by any of the optional peer drivers.

A driver command is a thin adapter around Playwright locators. For example, the get command in the CLI resolves a selector, asks the active page for a deep locator, and returns one of text, html, value, visible, checked, markdown, or a centroid box — see the exhaustive z.enum for what in the source. Source: packages/cli/src/lib/driver/commands/page-info.ts.

flowchart LR
    User[SDK user or Agent] -->|imports| Core[packages/core<br/>@browserbasehq/stagehand]
    Agent[Managed Agent] -->|invokes| CLI[packages/cli<br/>browse daemon]
    CLI -->|CDP / Browserbase Cloud| Browser[(Chromium)]
    Core -->|playwright-core /<br/>puppeteer-core /<br/>patchright-core| Browser
    Core <-->|LLMClient| LLM[(LLM Provider)]
    Core -->|HTTP| Server[packages/server-v3<br/>Fastify + OpenAPI]
    Server -->|CDP| Browser

Build, Distribution, and Extensibility

The repo ships three distribution shapes from core:

• ESM — primary build, produced by build:esm and consumed by both the server packages and downstream users.
• CJS — legacy build for environments that still require CommonJS.
• SEA (Single Executable Application) — produced by build:sea:esm/build:sea:cjs, controlled by SEA_BUILD_MODE, SEA_TARGET_PLATFORM, and SEA_TARGET_ARCH env vars. Source: turbo.json.

The CLI additionally ships an "init" flow that scaffolds a brand-new functions project: it writes package.json, .env, .gitignore, index.ts (a Zod-typed starter function), and tsconfig.json, then installs @browserbasehq/sdk-functions and playwright-core via the user's chosen package manager. Source: packages/cli/src/lib/functions/init.ts.

Community-Driven Architectural Pressure Points

The architecture's plug-in boundaries are the most heavily discussed surface in the issue tracker:

• LLM provider extensibility — users want first-class support for Ollama and other local models, and for AISdkClient to track the Vercel AI SDK's LanguageModelV3 (issues #183, #307, #1645). The current contract still expects LanguageModelV2, which is a TypeScript-level break for AI SDK v6+ users.
• Page attachment for Playwright video — issue #507 highlights that init() does not currently accept an existing Playwright Page to wrap, breaking e2e video recording workflows.
• Reusable extraction plans — issue #389 asks the extract flow to return a static parsing plan that can be replayed without re-invoking the LLM, which would decouple the LLM call from the parse step.

These three issues together describe the same theme: the project is moving from "LLM-in-the-loop-every-call" toward a more composable runtime where drivers, models, and parse plans are swappable inputs. Source: README.md, packages/core/package.json.

See Also

• Core SDK API
• LLM Provider Configuration
• Browser Driver Adapters
• CLI (browse) Reference

Related Pages

Related topics: Repository Overview and System Architecture, LLM Provider Layer and AI Agent System

Core Automation Engine: act, extract, observe, and agent

Overview and Purpose

The Core Automation Engine is the heart of Stagehand's v3 SDK (@browserbasehq/stagehand). It exposes four high-level primitives — act, extract, observe, and agent — that let developers drive a browser through natural-language instructions rather than hand-rolled Playwright/Puppeteer selectors. Each primitive is implemented as a dedicated handler that consumes a page context (the Understudy page wrapper), an LLM client, and instruction arguments, then returns a structured result. Source: packages/core/lib/v3/handlers/actHandler.ts, packages/core/lib/v3/handlers/extractHandler.ts, packages/core/lib/v3/handlers/observeHandler.ts, packages/core/lib/v3/handlers/v3AgentHandler.ts.

The engine is engine-agnostic with respect to the underlying browser automation library. The package.json declares playwright-core, patchright-core, and puppeteer-core as optional peer dependencies, allowing the same handlers to operate over any of the three driver types. Source: packages/core/package.json.

flowchart LR
    User[Caller / Test] --> Page[Understudy Page<br/>packages/core/lib/v3/understudy/page.ts]
    Page --> Act[actHandler]
    Page --> Extract[extractHandler]
    Page --> Observe[observeHandler]
    Page --> Agent[v3AgentHandler]
    Page --> CUA[v3CuaAgentHandler<br/>computer-use-agent]
    Act --> LLM[LLM Provider]
    Extract --> LLM
    Observe --> LLM
    Agent --> LLM
    CUA --> LLM
    LLM --> Tools[Browser Actions /<br/>DOM Snapshots]
    Tools --> Page

The Four Primitives

`act` — Perform an action on the page

actHandler translates a free-form instruction (for example, "click the Sign In button") into a concrete browser action. The handler observes the current page state, queries the LLM for the appropriate element reference and action verb, and dispatches the resulting call back through the Understudy page. This is the "act, then continue" building block most automation scripts use to drive a workflow. Source: packages/core/lib/v3/handlers/actHandler.ts.

`extract` — Pull structured data from the page

extractHandler pairs a Zod schema with a prompt and returns data that conforms to that schema. This is the path that community issue #389 targets: users want the *plan* (the inferred XPath / CSS / attribute selectors) returned alongside the values so it can be replayed deterministically across many instances without re-invoking the LLM. Source: packages/core/lib/v3/handlers/extractHandler.ts.

`observe` — Discover possible actions without performing them

observeHandler returns a list of candidate actions the LLM believes are currently possible on the page, without actually executing any of them. This is useful for planning, validation, and for driving agent loops that need to inspect a page before deciding what to do next. Source: packages/core/lib/v3/handlers/observeHandler.ts.

`agent` — Multi-step autonomous loop

v3AgentHandler orchestrates a loop that interleaves observe and act until a goal is reached. The handler manages step limits, error recovery, and tool selection. A sibling handler, v3CuaAgentHandler, provides a "computer-use-agent" (CUA) variant that uses screenshot-based reasoning instead of DOM snapshots — useful for visual-only sites or canvas-rendered applications. Source: packages/core/lib/v3/handlers/v3AgentHandler.ts, packages/core/lib/v3/handlers/v3CuaAgentHandler.ts.

Architecture and Page Surface

All four handlers share a common abstraction: the Understudy page. The Understudy wraps whichever underlying driver the user selected (Playwright, Patchright, or Puppeteer) and exposes a uniform API for snapshotting the DOM, executing actions, and querying state. This is what makes a single handler implementation work across driver backends. Source: packages/core/lib/v3/understudy/page.ts.

The build pipeline produces both ESM and CJS distributions and injects a generated version constant; the Turborepo graph also runs a build-dom-scripts task before the ESM build, which is what produces the in-page scripts the handlers inject for snapshotting. Source: turbo.json, packages/core/package.json.

Configuration and Extensibility

The engine is designed to be LLM-agnostic. The LLM client is injected into the handlers at construction time, so swapping providers is a configuration concern rather than a code change. Community issue #1645 tracks a current limitation: the built-in AISdkClient is typed against LanguageModelV2, while the Vercel AI SDK v6+ providers return LanguageModelV3, requiring a type-level compatibility shim until the engine is updated. Source: packages/core/lib/v3/handlers/v3AgentHandler.ts.

Issue #183 requests expansion to local providers such as Ollama, and issue #307 requests a unified llmOptions surface. Both depend on the handler layer accepting arbitrary tool-use-capable clients, which the v3 handler split makes tractable. Source: packages/core/lib/v3/handlers/actHandler.ts, packages/core/lib/v3/handlers/v3AgentHandler.ts.

Common Failure Modes

• Stale DOM references on rapid popups. Recent patch 2.5.8 added handling for "target closed" errors thrown when a page closes underneath a handler mid-action. This is the most common transient failure during act loops over volatile UI. Source: README.md (release notes for 2.5.8, PR #1710).
• Driver mismatch with video recording. When a test runner (notably Playwright) owns the page and Stagehand attaches later, video artifacts can be lost because Stagehand's normal initialization path opens its own context. Issue #507 tracks attaching to an existing Playwright page so that the runner's recording hooks remain intact. Source: packages/core/lib/v3/understudy/page.ts (the construction path that creates a new context).
• LLM provider schema drift. Provider packages that change their LanguageModel interface (as the Vercel AI SDK has done from v2 to v3) require handler-side updates before TypeScript callers can compile. Source: packages/core/lib/v3/handlers/v3AgentHandler.ts.

See Also

• Stagehand CLI (browse) — exposes a subset of the same DOM actions as a long-running daemon.
• LLM Provider Layer — how providers are wired into the handlers.
• Understudy Page Model — the cross-driver abstraction the handlers sit on top of.

Related Pages

Related topics: Repository Overview and System Architecture, Core Automation Engine: act, extract, observe, and agent

LLM Provider Layer and AI Agent System

Overview

The LLM Provider Layer and AI Agent System is the abstraction that lets Stagehand talk to large language models uniformly. It is the seam between the framework's browser-driving primitives — act(), extract(), and agent() — and whichever model the user brings. The layer lives under packages/core/lib/v3/llm/, with one client implementation per provider and a V3AgentHandler that orchestrates the agent flow described in packages/core/lib/v3/agent/tools/README.md. Source: packages/core/README.md.

The core package version 3.5.0 is published as @browserbasehq/stagehand and exposes a subpath CLI entry point through its exports map, indicating the v3 line is the current and recommended version. Source: packages/core/package.json.

LLM Provider Architecture

Each provider is implemented as its own client class, all conforming to a shared LLMClient interface, with LLMProvider.ts acting as the factory/dispatcher. The concrete clients in the v3 tree are:

Source: packages/core/lib/v3/llm/LLMProvider.ts, packages/core/lib/v3/llm/LLMClient.ts.

This per-provider split lets Stagehand support tool-use conventions, response shapes, and streaming behaviors that are unique to each vendor (Anthropic, OpenAI, Google Gemini, Cerebras) while keeping the upper layers model-agnostic.

flowchart LR
  User[User Code: act / extract / agent] --> SH[Stagehand Core]
  SH --> Prov[LLMProvider]
  Prov --> Ant[AnthropicClient]
  Prov --> OAI[OpenAIClient]
  Prov --> Gog[GoogleClient]
  Prov --> Cer[CerebrasClient]
  Ant --> API1[(Anthropic API)]
  OAI --> API2[(OpenAI API)]
  Gog --> API3[(Google API)]
  Cer --> API4[(Cerebras API)]

Agent System

The agent subsystem is layered on top of the LLM clients. Per the v3 agent tools README, the agent flow is AISDK-based and is consumed by V3AgentHandler. The tools in packages/core/lib/v3/agent/tools/ are explicitly described as "v3-native agent tools for the AISDK-based agent flow" that "mirror the v2 tools but operate on the V3 CDP-native APIs." Source: packages/core/lib/v3/agent/tools/README.md.

The public surface is a small set of entry points, as shown in the core README example:

// Use act() to execute individual actions
await stagehand.act("click on the stagehand repo");

// Use agent() for multi-step tasks
const agent = stagehand.agent();
await agent.execute("Get to the latest PR");

// Use extract() to get structured data from the page
const { author, title } = await stagehand.extract(
  "extract the author and title of the PR",
  z.object({
    author: z.string().describe("The username of the PR author"),
    title: z.string().describe("The title of the PR"),
  }),
);

Source: packages/core/README.md.

• act() resolves a single instruction into one or more browser actions.
• extract() returns structured, schema-typed data parsed from the current page.
• agent() returns an executor that drives a multi-step task by composing LLM calls with the agent tools.

The agent's reasoning loop is decoupled from any specific provider: the handler dispatches a tool-use request through LLMProvider, the chosen client renders it in the provider's native format, and the resulting tool calls are executed against the v3 CDP-native APIs.

Configuration and Build Wiring

The LLMProvider factory is the single configuration touchpoint most users need. Community issue #307 (titled "llm Options") points directly at packages/core/lib/v3/llm/LLMProvider.ts line 62 as the place where model selection currently lives, and requests the ability to plug in models such as Tongyi or Gemini. Source: community issue #307.

The build graph is managed by Turborepo. The core package's ESM build is wired in turbo.json to depend on ^build:esm, gen-version, and build-dom-scripts, and it uses DOM-scripts produced under lib/dom/build/ and lib/v3/dom/build/. Source: turbo.json.

The repository requires Node ^20.19.0 || >=22.12.0, set in both the root and the core package engines field. Source: package.json, packages/core/package.json.

Known Gaps and Community Requests

Several open issues document where the LLM/agent layer is being extended:

• Custom / local models (#183): Requests expanding support beyond the four shipped clients to Ollama and other self-hosted providers that require custom tool-use integration. Source: issue #183.
• AI SDK v6 / LanguageModelV3 (#1645): Reports that AISdkClient is currently typed against LanguageModelV2, while the latest Vercel AI SDK v6+ providers return LanguageModelV3, causing a TypeScript incompatibility. Source: issue #1645.
• Caching extract plans (#389): Suggests returning the static parsing plan produced by extract() so it can be reused across runs without re-invoking the LLM. Source: issue #389.
• LLM option surface (#307): Asks for a configuration model similar to other frameworks so non-Anthropic, non-OpenAI models (e.g. Tongyi, Gemini) can be selected. Source: issue #307.

Together these issues describe a layer that is functionally complete across the four shipped providers but is being actively expanded toward (a) bring-your-own-model workflows and (b) a forward-compatible AI SDK type surface.

See Also

• Stagehand Core Overview — high-level entry point and act / extract / agent reference
• Browse CLI — the browse command-line surface in packages/cli/
• Stagehand Server (v3) — Fastify server in packages/server-v3/ that exposes Stagehand over HTTP

Related Pages

Related topics: Repository Overview and System Architecture, Core Automation Engine: act, extract, observe, and agent, LLM Provider Layer and AI Agent System

CLI, Server Runtime, and Framework Integrations

Overview

Stagehand ships more than a programmatic SDK. The monorepo publishes three coordinated layers that wrap the core library for non-Node consumers and production deployments:

1. The browse CLI — a thin, agent-friendly command surface that drives a persistent headless or remote browser.
2. The HTTP Server Runtime (stagehand-server-v3) — a Fastify service that exposes the core as a versioned, OpenAPI-documented API.
3. Framework Integrations — scaffolding (browse functions init) and cookbook guides (Anthropic Managed Agents, Playwright attachment patterns) that connect Stagehand to external automation stacks.

These layers share the same core under the hood and are coordinated through a Turborepo pipeline so a single pnpm build produces all artifacts. Source: turbo.json:1-120.

The `browse` CLI

What it is

The browse CLI is published as the browse npm package and is positioned as "the official CLI for browse.sh". It exposes 30+ DOM commands (open, click, fill, browse type, browse select, screenshot, snapshot, network, etc.) optimized for LLM agents rather than human users. Source: packages/cli/README.md:1-30.

Per-session daemon

The CLI is designed around a long-lived per-session daemon. The first command starts it, and subsequent commands reuse the same browser process so cookies, tabs, and snapshot references (@0-12) persist across invocations. Multiple isolated sessions can run concurrently via the --session <name> flag or the BROWSE_SESSION environment variable, and a session is torn down with browse stop. Source: packages/cli/README.md:32-44.

Browser targets

Every driver command accepts the same selector flags. The default target is a managed local browser; when BROWSERBASE_API_KEY is set, the same commands transparently route to a Browserbase cloud session. A --local flag keeps execution on the host. Source: packages/cli/README.md:46-58.

Driver command surface

Low-level page introspection is implemented as parameterized driver commands. The page-info handler accepts a Zod-validated what enum covering box, checked, html, markdown, text, title, url, value, and visible, returning structured data through manager.activePage() and Playwright's deepLocator. Source: packages/cli/src/lib/driver/commands/page-info.ts:1-49.

Server Runtime (`stagehand-server-v3`)

The stagehand-server-v3 package wraps the core as a Fastify HTTP service. It depends on fastify, fastify-metrics, fastify-zod-openapi, @fastify/swagger-ui, playwright, pino, and zod, producing both ESM and CJS bundles plus a generated openapi.v3.yaml spec. Source: packages/server-v3/package.json:1-40.

A gen:openapi Turbo task regenerates the spec from Zod schemas; the build:server:dist task produces dist/lib, dist/routes, dist/types, and declaration files consumed by downstream integrations. Source: turbo.json:60-95.

Server configuration is centralized through @t3-oss/env-core and requires NODE_ENV plus a BB_ENV enum (local, dev, prod). Defaults of production and local make local development frictionless. Source: packages/server-v3/src/lib/env.ts:1-18.

A parallel v4 server is in active development. The build:esm and gen:openapi tasks in the Turbo pipeline already build ESM bundles and emit an openapi.v4.yaml for the v4 service, and the CLI's build:cli task is wired to depend on it. Source: turbo.json:18-55.

Framework Integrations

`browse functions init`

browse functions init scaffolds a Functions project, generating a package.json (type module, scripts dev and deploy), .env, .gitignore, index.ts, and a strict tsconfig.json for ESM/NodeNext. It then installs @browserbasehq/sdk-functions, playwright-core, typescript, and @types/node using the user's chosen package manager (npm or pnpm) and initializes a git repository. Source: packages/cli/src/lib/functions/init.ts:35-120. The result is a deployable unit that publishes through browse functions publish.

Anthropic Managed Agents

The integration cookbook for Anthropic Managed Agents documents how to mount the browse CLI as a default npm package inside an Environment, optionally with "Unrestricted" networking. It then describes provisioning a Credential vault named BROWSERBASE_API_KEY with "Limited" networking scoped to *.browserbase.com, allowing the agent to issue browse click and browse network commands while keeping credentials scoped. Source: packages/cli/guides/anthropic-managed-agents/README.md:1-40.

Community-driven integrations

Several recurring community requests describe adjacent integration patterns:

• Playwright attachment. Issue #507 (13 comments) requests the ability to attach Stagehand to an existing Playwright page so that test runners can capture video properly during e2e tests. Source: community context.
• Bring-your-own LLM. Issue #183 (Ollama) and #307 (llm options) ask for first-class support for non-OpenAI / non-Anthropic models. These remain open, signalling that custom provider integration is a high-demand direction. Source: community context.
• Vercel AI SDK parity. Issue #1645 requests upgrade to LanguageModelV3 in AISdkClient so that Vercel AI SDK v6+ provider packages work without TypeScript errors. Source: community context.
• Caching extraction plans. Issue #389 asks for extraction results to be reusable so agents can replay a parsing plan without re-invoking the LLM. Source: community context.

Build and Release Pipeline

The monorepo is coordinated by Turborepo and pnpm 9.15. The root package.json pins node to ^20.19.0 || >=22.12.0 and centralizes dependency overrides for transitive security advisories (axios, follow-redirects, lodash, tar, esbuild, etc.). Source: package.json:1-50. The README directs contributors to pnpm install, pnpm run build, and pnpm run example for a quick start, with LLM and Browserbase credentials loaded from .env. Source: README.md:30-50.

flowchart LR
  A[Agent / User] -->|browse click, snapshot, ...| B[browse CLI]
  B -->|driver command| C[Per-session Daemon]
  C -->|local| D[(Local Chromium)]
  C -->|remote| E[(Browserbase Cloud)]
  F[Functions Project] -->|browse functions publish| G[@browserbasehq/sdk-functions]
  H[HTTP Client] -->|REST / OpenAPI| I[stagehand-server-v3]
  I -->|core API| J[Stagehand Core]
  G --> J
  B --> J
  J --> D
  J --> E

See Also

• Stagehand Core Library — the underlying programmatic API.
• LLM Provider System — covers the AISdkClient and LLMProvider referenced by community issues #183, #307, and #1645.
• Configuration & Environment — env variables, .env.example, and Turbo task definitions.
• Community: issue #507 (Playwright attachment), #389 (extract plan caching).

Doramagic Pitfall Log

Found 26 structured pitfall item(s), including 2 high/blocking item(s). Top priority: Runtime risk - Runtime risk requires verification.

1. Runtime risk: Runtime risk requires verification

• Severity: high
• Finding: Project evidence flags a runtime risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/browserbase/stagehand/issues/2188

2. Security or permission risk: Security or permission risk requires verification

• Severity: high
• Finding: Project evidence flags a security or permission risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/browserbase/stagehand/issues/899

3. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: @browserbasehq/[email protected]
• User impact: Upgrade or migration may change expected behavior: @browserbasehq/[email protected]
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: @browserbasehq/[email protected]. Context: Observed during installation or first-run setup.
• Evidence: failure_mode_cluster:github_release | https://github.com/browserbase/stagehand/releases/tag/%40browserbasehq/stagehand%403.6.0

4. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: Add AgentWeb — free business data API for agents
• User impact: Developers may fail before the first successful local run: Add AgentWeb — free business data API for agents
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Add AgentWeb — free business data API for agents. Context: Observed when using node
• Evidence: failure_mode_cluster:github_issue | https://github.com/browserbase/stagehand/issues/1985

5. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Developers should check this installation risk before relying on the project: stagehand/server-v3 v3.7.2
• User impact: Upgrade or migration may change expected behavior: stagehand/server-v3 v3.7.2
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: stagehand/server-v3 v3.7.2. Context: Observed during installation or first-run setup.
• Evidence: failure_mode_cluster:github_release | https://github.com/browserbase/stagehand/releases/tag/stagehand-server-v3/v3.7.2

6. Installation risk: Installation risk requires verification

• Severity: medium
• Finding: Project evidence flags a installation risk. Review the linked source before relying on this workflow.
• User impact: May increase setup, validation, or first-run risk for the user.
• Recommended check: Reproduce the official install and quickstart path in an isolated environment.
• Evidence: community_evidence:github | https://github.com/browserbase/stagehand/issues/1985

7. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: @browserbasehq/[email protected]
• User impact: Upgrade or migration may change expected behavior: @browserbasehq/[email protected]
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: @browserbasehq/[email protected]. Context: Observed when using playwright
• Evidence: failure_mode_cluster:github_release | https://github.com/browserbase/stagehand/releases/tag/%40browserbasehq/stagehand%403.4.0

8. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: @browserbasehq/[email protected]
• User impact: Upgrade or migration may change expected behavior: @browserbasehq/[email protected]
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: @browserbasehq/[email protected]. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/browserbase/stagehand/releases/tag/%40browserbasehq/stagehand%403.5.0

9. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Add x402 agent payments: let AI agents pay per browser session autonomously (USDC, no shared credit pools)
• User impact: Developers may misconfigure credentials, environment, or host setup: Add x402 agent payments: let AI agents pay per browser session autonomously (USDC, no shared credit pools)
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Add x402 agent payments: let AI agents pay per browser session autonomously (USDC, no shared credit pools). Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_issue | https://github.com/browserbase/stagehand/issues/1950

10. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: Can't use AWS Bedrock custom Llm on BROWSERBASE Env
• User impact: Developers may misconfigure credentials, environment, or host setup: Can't use AWS Bedrock custom Llm on BROWSERBASE Env
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: Can't use AWS Bedrock custom Llm on BROWSERBASE Env. Context: Observed during version upgrade or migration.
• Evidence: failure_mode_cluster:github_issue | https://github.com/browserbase/stagehand/issues/899

11. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: stagehand/server-v3 v3.6.10
• User impact: Upgrade or migration may change expected behavior: stagehand/server-v3 v3.6.10
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: stagehand/server-v3 v3.6.10. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/browserbase/stagehand/releases/tag/stagehand-server-v3/v3.6.10

12. Configuration risk: Configuration risk requires verification

• Severity: medium
• Finding: Developers should check this configuration risk before relying on the project: stagehand/server-v3 v3.7.0
• User impact: Upgrade or migration may change expected behavior: stagehand/server-v3 v3.7.0
• Recommended check: Before packaging this project, run the relevant install/config/quickstart check for: stagehand/server-v3 v3.7.0. Context: Source discussion did not expose a precise runtime context.
• Evidence: failure_mode_cluster:github_release | https://github.com/browserbase/stagehand/releases/tag/stagehand-server-v3/v3.7.0

Community Discussion Evidence

Doramagic exposes project-level community discussion separately from official documentation. Review these links before using stagehand with real data or production workflows.

• Can't use AWS Bedrock custom Llm on BROWSERBASE Env - github / github_issue
• Add x402 agent payments: let AI agents pay per browser session autonomou - github / github_issue
• Add HVTracker badge to README? - github / github_issue
• Add AgentWeb — free business data API for agents - github / github_issue
• Browserbase is flagged "accelerating" on GitDealFlow — optional badge - github / github_issue
• evals(cua): add a deterministic CUA agent regression task - github / github_issue
• @browserbasehq/[email protected] - github / github_release
• @browserbasehq/[email protected] - github / github_release
• stagehand/server-v3 v3.7.2 - github / github_release
• [email protected] - github / github_release
• @browserbasehq/[email protected] - github / github_release
• @browserbasehq/[email protected] - github / github_release