Stagehand vs Steel

Caching

1. developerCache resolved actions or generated code so repeat runs replay deterministically at lower cost and latency than re-prompting the LLM

   weight 2 · round to Stagehand
   Stagehand✓fullclaimed7/10

   Stagehand's docs explicitly state that act(), observe(), and extract() results are cached server-side to reduce LLM costs and speed up automations, directly matching the story's request for cached deterministic replay at lower cost/latency. Additional support for persistent user data (cookies/local storage, Browserbase contexts) reinforces cross-run determinism, though there's no independent/hands-on corroboration of cache-hit behavior or cache invalidation details. Missing for 10: independent verification of caching effectiveness/determinism claims, details on cache invalidation when page structure changes, and quantified latency/cost savings.

   • [claimed-docs] “Stagehand caches `act()`, `observe()`, and `extract()` results server-side to reduce LLM costs and speed up your automations.”
   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”

   proof ↗⚑ flag

   Steel—none0/10

   Steel's evidence covers session management, stealth, proxies, human-in-the-loop debugging, and agent traces, but nothing about caching resolved actions or generated code to enable deterministic, lower-cost replay without re-invoking the LLM. Agent traces (steel-docs-6/7) provide observability/export, not action-cache replay for cost savings.

   ⚑ flag

Dom

1. developerDrive the page through DOM-understanding action primitives (act/click/type on described elements) that survive selector and layout changes

   weight 3 · round to Stagehand
   Stagehand✓fullcommunity8/10

   Docs describe act()/observe()/extract() as natural-language, DOM-understanding primitives with selfHeal to re-infer broken selectors and automatic iframe/shadow-DOM handling, directly matching the story; independent HN commentary corroborates that Stagehand dynamically regenerates Playwright actions making it resilient to DOM changes. Missing for 10: rigorous independent benchmark of resilience across real layout changes and more than a single third-party account.

   • [claimed-docs] “Execute actions using natural language”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Turn on `selfHeal` to re-infer an action when its recorded selector breaks.”
   • [claimed-docs] “Stagehand automatically handles iFrame traversal and shadow DOM elements without requiring additional configuration.”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”

   proof ↗⚑ flag

   Steel—none0/10

   Steel's evidence shows only traditional CDP/Puppeteer/Selenium-based control and CLI commands like click/fill/type (steel-docs-8, steel-gh-1), which are selector-based automation primitives, not AI/DOM-understanding 'act on described element' primitives that resolve targets semantically and survive selector/layout changes. No documentation or hands-on evidence describes a Stagehand-like natural-language action resolver.

   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”

   proof ↗⚑ flag

Observe

1. developerPreview candidate actions on the current page (observe/plan) before committing the agent to act

   weight 1 · round to Stagehand
   Stagehand✓fullprobed8/10

   observe() is a first-class primitive documented explicitly for discovering actionable elements and returning structured actions 'you can execute or validate before acting,' directly matching the preview/plan-before-act story, and it composes with act()/extract() as separate committed steps (stagehand-docs-3). Runtime probe confirms the package installs and exposes the Stagehand class in practice. missing for 10: independent hands-on developer confirmation specifically of observe()'s preview behavior (community evidence discusses self-healing/act() but not observe() directly).

   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Execute actions using natural language”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Steel~partialclaimed4/10

   Steel exposes browser observation primitives (page-to-markdown/readability/screenshot extraction, agent traces/timeline, and a debug URL for human-in-the-loop review) that let a developer inspect page state or a human intervene mid-session, but there is no documented 'plan' or dry-run API that lets an agent preview a set of candidate actions before committing to execute them. missing for 10: an explicit plan/observe-then-act primitive or dry-run action preview API, evidence of independent developers using it specifically for pre-commit action review.

   • [github] “Browser Tools: Exposes APIs to quick convert pages to markdown, readability, screenshots, or PDFs.”
   • [claimed-docs] “Steel's debug URL feature allows you to implement human-in-the-loop workflows where users can directly interact with and control browser ses…”
   • [claimed-docs] “It turns the run into a timeline of agent activity, so you can see what happened without scrubbing through the whole recording.”

   proof ↗⚑ flag

Vision

1. developerSwitch to a vision or computer-use action mode that operates on screenshots for canvases and UIs the DOM path can't handle

   weight 2 · round drawn
   Stagehand—none0/10

   No documentation describes a vision/computer-use mode operating on screenshots; the only related evidence is a community comment stating the team is 'working on a better computer use integration' — implying it isn't shipped yet.

   • [community] “Our Stagehand MCP server actually won Anthropic's Claude MCP hackathon :) ... We're working on a better computer use integration using Stage…”

   proof ↗⚑ flag

   Steel—none0/10

   Evidence shows Steel can capture screenshots, convert pages to markdown/PDF, and offers a debug URL for human-in-the-loop control, but there is no mention of a vision/computer-use action mode where an agent issues click/type actions based on screenshot coordinates instead of DOM selectors.

   ⚑ flag

Agent access

1. ai-native userPoint an agent at llms.txt or agent-oriented docs

   weight 2 · round to Steel
   Stagehand✓fullprobed8/10

   The probe confirms Stagehand's docs site serves a valid llms.txt (HTTP 200) with structured links to docs pages, directly enabling an agent to be pointed at agent-oriented documentation. missing for 10: no evidence of independent/community confirmation that agents actually consume this llms.txt successfully in practice, and no detail on completeness/coverage of the llms.txt beyond the introduction page.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stagehand.dev/llms.txt # Stagehand - [Introducing Stagehand](https://docs.stagehand.dev/v4/first-s…”

   proof ↗⚑ flag

   Steel✓fullprobed9/10

   Probe confirms llms.txt is live at docs.steel.dev/llms.txt (HTTP 200) with agent-oriented framing, and the docs also expose an OpenAPI spec, making the docs machine/agent consumable. missing for 10: no independent third-party confirmation that agents actually consume the llms.txt file successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.steel.dev/llms.txt # Steel Documentation > Steel is the open-source browser API for AI agents — ma…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”

   proof ↗⚑ flag

2. ai-native userRun the product headlessly / in CI for automation

   weight 2 · round to Steel
   Stagehand✓fullprobed8/10

   Stagehand is a Node/TS library built on Playwright with a scriptable API (act/observe/extract), headless browser support via Browserbase or CDP-attached Chromium, and npm-installable package confirmed via runtime probe, making CI/headless automation straightforward. missing for 10: explicit first-party CI pipeline examples (GitHub Actions/Docker recipes) and independent hands-on confirmation of a full unattended CI run.

   • [claimed-docs] “When you know the selector or want zero inference, use page methods you already know.”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [claimed-docs] “Attach over CDP (localBrowser.connect): Attach to any Chromium browser you are already running, by URL”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [community] “Have been on the Slack for a while and this crew has had an insane product velocity. Excited to see where it goes!”

   proof ↗⚑ flag

   Steel✓fullprobed9/10

   Steel provides a documented CLI for end-to-end headless browser workflows from the terminal, a REST/SDK API for programmatic session creation, an open-source Docker image for self-hosting, and a verified probe confirming a keyless self-host roundtrip (docker run, health check, session creation via API, CLI install, SDK install) — all strongly supporting CI/headless automation use. missing for 10: no explicit first-party CI pipeline example (e.g., GitHub Actions template) or independent hands-on report of running Steel inside an actual CI system.

   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [github] “Pre-built Docker Image (combined API + UI)”
   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
   • [probe] “official CLI documented at https://docs.steel.dev/overview/steel-cli”
   • [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”

   proof ↗⚑ flag

3. ai-native userConnect an agent via an official MCP server

   weight 3 · round to Stagehand
   Stagehand✓fullprobed8/10

   Stagehand ships an official MCP server ('Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio') and a runtime probe confirms `npx -y @browserbasehq/mcp` actually boots and identifies as 'Browserbase MCP Server ... powered by Browserbase and Stagehand', responding to JSON-RPC initialize. Community evidence corroborates real-world use (the Stagehand MCP server won Anthropic's Claude MCP hackathon). Missing for 10: independent third-party review of the full tool surface/robustness of the MCP server beyond the hackathon anecdote and the first-party docs/probe.

   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [community] “Our Stagehand MCP server actually won Anthropic's Claude MCP hackathon :) ... We're working on a better computer use integration using Stage…”

   proof ↗⚑ flag

   Steel~partialclaimed5/10

   Steel's docs mention an integration with the Claude Agent SDK that 'exposes a cloud browser as in-process MCP tools,' showing some official MCP tool exposure for agents, but there's no evidence of a standalone, general-purpose official MCP server endpoint independent of this one SDK integration. missing for 10: a dedicated/standalone MCP server doc or endpoint usable by any agent framework, independent corroboration or hands-on proof of MCP connectivity.

   • [claimed-docs] “The Steel integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the browser.”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Steel
   Stagehand—none0/10

   Stagehand is distributed as an npm SDK/library plus an MCP server; the evidence pack shows npm install and MCP server invocation via npx, but no dedicated official CLI tool for direct AI-native command-line interaction is documented anywhere.

   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”

   proof ↗⚑ flag

   Steel✓fullprobed8/10

   Steel ships a documented official CLI (steel-docs-8) that supports end-to-end browser workflows from the terminal, and probe evidence confirms real installation via setup.steel.dev installing 'steel CLI 0.4.4' into a fresh environment (steel-probe-rt-1), corroborating the docs. Missing for 10: independent third-party reviews of the CLI's UX/reliability beyond the vendor-run probe, and more detail on advanced CLI subcommands/scripting capabilities.

   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [probe] “official CLI documented at https://docs.steel.dev/overview/steel-cli”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”

   proof ↗⚑ flag

5. ai-native userDrive the product through a documented public API

   weight 3 · round to Steel
   Stagehand✓fullprobed8/10

   Stagehand ships a well-documented public SDK API (act(), extract(), observe(), page methods, selfHeal, caching) with a dedicated docs site and llms.txt, and an npm package that a runtime probe confirms actually installs and exports a working class plus a functioning MCP server exposing the same tools. Community posts corroborate real developer usage of this API for browser automation. Missing for 10: an OpenAPI/REST spec (404s) and deeper independent (non-community) validation of API stability/versioning.

   • [claimed-docs] “Execute actions using natural language”
   • [claimed-docs] “extract() grabs structured data from a webpage. Every call takes an instruction and an output shape”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “When you know the selector or want zero inference, use page methods you already know.”
   • [claimed-docs] “Turn on `selfHeal` to re-infer an action when its recorded selector breaks.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stagehand.dev/llms.txt # Stagehand - [Introducing Stagehand](https://docs.stagehand.dev/v4/first-s…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stagehand.dev/openapi.json, https://docs.stagehand.dev/swagger.json, https://docs.stage…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”

   proof ↗⚑ flag

   Steel✓fullprobed9/10

   Steel publishes a full OpenAPI spec (steel-probe-2), documented Sessions API with SDKs, and a CLI, all confirmed hands-on by a runtime probe showing session creation, health checks, and SDK usage working end-to-end. This is strong first-party documentation plus independent verification of a working public API. Missing for 10: no third-party community deep-dive validating API completeness beyond the probe.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
   • [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [probe] “official CLI documented at https://docs.steel.dev/overview/steel-cli”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”

   proof ↗⚑ flag

6. ai-native userIssue scoped/least-privilege API credentials for an agent

   weight 2 · round drawn
   Stagehand—none0/10

   Stagehand is a browser-automation library; evidence covers API keys for model/Browserbase access but no scoped/least-privilege credential issuance, role-based permissions, or token-scoping features for agents are documented anywhere in docs, community, or probes. Missing for 10: any mention of scoped API key issuance, permission scoping, or least-privilege credential management for agents.

   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Steel—none0/10

   No evidence anywhere in the pack of scoped or least-privilege API key/credential issuance (e.g., role-based keys, permission scopes, restricted tokens) for agents — only session isolation, proxies, and CLI features are documented, none of which address credential scoping.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round drawn
   Stagehand✓fullprobed8/10

   Stagehand ships an official TypeScript/JS SDK (@browserbasehq/stagehand npm package) with documented APIs (act, observe, extract) and confirmed runtime install/import success, making it directly usable by AI-native developers building agentic browser automation. missing for 10: no evidence of official SDKs in other languages (e.g., Python) or independent third-party corroboration of SDK API stability beyond docs and one runtime probe.

   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [claimed-docs] “extract() grabs structured data from a webpage. Every call takes an instruction and an output shape”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Execute actions using natural language”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stagehand.dev/llms.txt # Stagehand - [Introducing Stagehand](https://docs.stagehand.dev/v4/first-s…”

   proof ↗⚑ flag

   Steel✓fullprobed8/10

   Steel ships an official steel-sdk npm package (verified working via probe: exports a Steel client class), a documented OpenAPI spec, and an official CLI for full browser workflows, all covered in first-party docs and confirmed by a hands-on runtime probe. missing for 10: explicit multi-language SDK coverage (e.g., Python/other languages) and independent community confirmation of SDK usage beyond the CLI/API.

   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
   • [probe] “official CLI documented at https://docs.steel.dev/overview/steel-cli”
   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [claimed-docs] “The Steel integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the browser.”

   proof ↗⚑ flag

Agentic features

1. ai-native userSet up automations that run autonomously in the background

   weight 2 · round to Stagehand
   Stagehand~partialclaimed5/10

   Stagehand supports cloud-hosted Browserbase sessions with persistent user data/contexts, caching to speed repeat runs, and a real-time observability dashboard, all of which enable automations to run without a local machine and be monitored asynchronously. However there's no documented scheduler, trigger system, or explicit 'run unattended over time' capability distinguishing this from any scripted automation run on-demand. missing for 10: explicit scheduling/cron or trigger mechanism, evidence of long-running unattended multi-step autonomous sessions, independent confirmation of background execution reliability.

   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [claimed-docs] “Browserbase provides real-time visibility into your automation sessions: **Session dashboard features** * Real-time browser screen recordi…”
   • [claimed-docs] “Stagehand caches `act()`, `observe()`, and `extract()` results server-side to reduce LLM costs and speed up your automations.”

   proof ↗⚑ flag

   Steel—none0/10

   Steel provides on-demand browser sessions, CLI, SDK, and agent-trace tooling for agents to control browsers, but nothing in the evidence describes a scheduling/trigger mechanism or persistent background job runner that lets a user set up automations to run autonomously without invocation — sessions are explicitly spun up 'on demand' by an agent/script, not scheduled by Steel itself.

   • [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”

   proof ↗⚑ flag

2. ai-native userOperate the product with natural-language commands

   weight 2 · round to Stagehand
   Stagehand✓fullcommunity9/10

   Stagehand's core API (act/extract/observe) is explicitly designed around natural-language instructions instead of hardcoded selectors, with docs describing instruction-driven execution and self-healing when selectors break. Community commentary independently corroborates that this NL-driven approach dynamically generates Playwright actions and is more resilient than traditional automation frameworks. Missing for 10: independent quantitative benchmarks on NL command accuracy/reliability across diverse sites.

   • [claimed-docs] “Execute actions using natural language”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Turn on `selfHeal` to re-infer an action when its recorded selector breaks.”
   • [claimed-docs] “Traditional selectors break when websites change”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”

   proof ↗⚑ flag

   Steel~partialclaimed5/10

   Steel exposes its browser control as MCP tools within agent SDKs (e.g., Claude Agent SDK) so an AI agent can translate natural-language user requests into Steel API calls, and the CLI/SDK/API allow full programmatic control — but there's no evidence of a native natural-language interface to Steel itself (e.g., a chat command layer); control still requires structured API/CLI calls or a separate agent framework. Missing for 10: a first-party NL command interface or chat-driven control surface, and independent confirmation that NL-driven agent use works end-to-end in production.

   • [claimed-docs] “The Steel integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the browser.”
   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”

   proof ↗⚑ flag

Api quality

1. ai-native userExplore an interactive API reference with runnable examples

   weight 2 · round to Steel
   Stagehand—none0/10

   The evidence pack shows standard prose documentation pages (docs.stagehand.dev) and confirms no OpenAPI/swagger spec exists (404s on all candidate paths), with no mention anywhere of an interactive, runnable-example API reference (e.g., live code sandbox or Swagger-style explorer). The llms.txt probe only shows a docs index for LLM ingestion, not an interactive reference.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stagehand.dev/openapi.json, https://docs.stagehand.dev/swagger.json, https://docs.stage…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stagehand.dev/llms.txt # Stagehand - [Introducing Stagehand](https://docs.stagehand.dev/v4/first-s…”
   • [claimed-docs] “Execute actions using natural language”

   proof ↗⚑ flag

   Steel~partialprobed6/10

   Steel publishes a full OpenAPI spec (docs.steel.dev/openapi.json) and an llms.txt, and a community commenter independently praised the docs/API reference quality, suggesting an interactive, well-documented API surface. However, there's no explicit evidence of an in-browser 'try it' / runnable-example console distinct from static docs. Missing for 10: direct confirmation of an interactive try-it console with live runnable code snippets, and independent hands-on verification of that specific feature.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.steel.dev/llms.txt # Steel Documentation > Steel is the open-source browser API for AI agents — ma…”
   • [community] “beautiful docs + api ref! what are you using? (cool that you're doing open-source browserbase also, excited to check this out)”

   proof ↗⚑ flag

2. ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)

   weight 2 · round to Steel
   Stagehand—none0/10

   Direct probes for OpenAPI/swagger specs at all standard paths returned 404, and no documentation mentions a downloadable machine-readable API spec; only an llms.txt exists which is not an API spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stagehand.dev/openapi.json, https://docs.stagehand.dev/swagger.json, https://docs.stage…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.stagehand.dev/llms.txt # Stagehand - [Introducing Stagehand](https://docs.stagehand.dev/v4/first-s…”

   proof ↗⚑ flag

   Steel✓fullprobed9/10

   A probe confirms a live, valid OpenAPI JSON spec served at docs.steel.dev/openapi.json (HTTP 200 with 'openapi' key), directly satisfying the machine-readable spec requirement, complemented by an llms.txt index for discoverability. missing for 10: independent third-party corroboration beyond the automated probe.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.steel.dev/llms.txt # Steel Documentation > Steel is the open-source browser API for AI agents — ma…”

   proof ↗⚑ flag

3. ai-native userTest against a sandbox environment without touching production data

   weight 1 · round to Steel
   Stagehand—none0/10

   Stagehand's docs cover browser session persistence, regions, and observability but nothing about a dedicated sandbox/staging mode or safeguards to prevent hitting production data; the evidence pack shows only live browser automation against real or Browserbase-hosted sites.

   ⚑ flag

   Steel✓fullprobed7/10

   Steel's core Sessions API spins up isolated, on-demand browser instances each with their own state, cookies, and storage, and this isolation was independently verified via a self-hosted runtime probe that created a live, separate browser session from a throwaway Docker instance — effectively a sandbox with no shared production state. Missing for 10: explicit documentation framing sessions as a 'test vs production' environment, and no first-party guidance on staging/production data separation policies beyond session isolation.

   • [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
   • [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
   • [github] “Pre-built Docker Image (combined API + UI)”

   proof ↗⚑ flag

4. ai-native userRely on versioned APIs with a documented deprecation policy

   weight 2 · round drawn
   Stagehand—none0/10

   Docs reference a 'v4' version path, but there is no evidence of a documented API versioning scheme or deprecation policy for Stagehand's SDK/API; no openapi spec or changelog/deprecation docs were found (openapi probe 404s).

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stagehand.dev/openapi.json, https://docs.stagehand.dev/swagger.json, https://docs.stage…”

   proof ↗⚑ flag

   Steel—none0/10

   No evidence pack item mentions API versioning scheme or a documented deprecation policy; only an OpenAPI spec and general docs are shown, neither of which discuss version lifecycle or deprecation commitments.

   ⚑ flag

Compat

1. developerConnect my existing Playwright, Puppeteer, or CDP automation code to the product's browsers instead of rewriting it

   weight 2 · round to Steel
   Stagehand~partialcommunity6/10

   Stagehand explicitly supports attaching over CDP to any existing Chromium browser and lets you keep using familiar page-level (Playwright) methods when you don't need AI inference, which lets developers reuse existing Playwright/CDP automation rather than rewriting from scratch. However there is no evidence of native Puppeteer script compatibility, and community comments note Stagehand is positioned as a replacement/wrapper rather than a drop-in for arbitrary existing Playwright suites. Missing for 10: explicit Puppeteer interop, first-party guide on migrating existing Playwright test suites unmodified, and independent confirmation that CDP-attach preserves auth/session state seamlessly.

   • [claimed-docs] “Attach over CDP (localBrowser.connect): Attach to any Chromium browser you are already running, by URL”
   • [claimed-docs] “When you know the selector or want zero inference, use page methods you already know.”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”
   • [community] “This looks very cool and makes a lot of sense, except for the idea that it should take the place of Playwright et al. Personally I'd love to…”

   proof ↗⚑ flag

   Steel✓fullprobed9/10

   Steel explicitly supports connecting existing Puppeteer, Playwright, or Selenium code via CDP to control its browser instances, and a runtime probe confirms live sessions expose websocket/debugger URLs consistent with CDP connectivity. Docs and SDK further corroborate first-class session management compatible with standard automation libraries. Missing for 10: independent third-party hands-on confirmation specifically of a rewritten Playwright/Puppeteer script running unmodified against Steel.

   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
   • [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”

   proof ↗⚑ flag

Credentials

1. automation-engineerStore credentials in a vault and have the agent complete logins including TOTP/2FA challenges without exposing secrets to the model

   weight 2 · round drawn
   Stagehand—none0/10

   Evidence covers session/state persistence (cookies, local storage, Browserbase contexts) but there is no mention of vault-based credential storage, secret injection to avoid model exposure, or TOTP/2FA handling anywhere in the docs or community evidence.

   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”

   proof ↗⚑ flag

   Steel—none0/10

   Steel's docs show session-level auth persistence (reusing cookies/storage across sessions) but no evidence of a credentials vault, secret injection without model exposure, or TOTP/2FA challenge automation — the core asks of this story are unaddressed.

   • [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”

   proof ↗⚑ flag

Profiles

1. developerPersist logged-in browser state in reusable profiles so agents skip the login wall on every subsequent run

   weight 3 · round drawn
   Stagehand✓fullclaimed8/10

   Docs explicitly describe persisting local browser user-data directories (cookies/local storage survive across runs) and Browserbase contexts for persisting session/browser data across cloud runs, directly matching the reusable-profile/login-skip story. Missing for 10: independent hands-on confirmation that a persisted profile actually skips a real login wall, and more detail on context lifecycle/expiry limits.

   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”

   proof ↗⚑ flag

   Steel✓fullprobed8/10

   Steel docs explicitly document reusing auth context across sessions to let agents skip repeated logins, backed by session isolation, custom session IDs, and a real API/CLI/SDK confirmed via runtime probe. Missing for 10: independent third-party hands-on confirmation of the reuse-auth-context feature specifically (only vendor docs cite it) and no explicit profile-export/import UX details beyond the docs description.

   • [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”
   • [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
   • [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”

   proof ↗⚑ flag

1. ai-native userPerform bulk operations across many items at once

   weight 2 · round to Steel
   Stagehand—none0/10

   The evidence pack covers single-page act/extract/observe primitives, caching, and session persistence, but nothing describes batch/bulk operations across many items or parallelized runs at once. A browser-automation framework could plausibly support this (e.g., running many sessions in parallel), so the axis applies, but no such capability is documented.

   ⚑ flag

   Steel~partialclaimed4/10

   Steel's Sessions API allows spinning up isolated browser sessions on demand and reusing auth context across multiple sessions, which implies you could programmatically launch many sessions for parallel/bulk tasks, but there is no explicit documentation of a batch/bulk API, concurrency limits, or guidance for orchestrating many items at once. missing for 10: explicit bulk/batch API or documented pattern for running many operations concurrently, concurrency/rate limits, and independent evidence of large-scale parallel session usage.

   • [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
   • [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”
   • [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”

   proof ↗⚑ flag

2. ai-native userDefine rules that trigger actions automatically on events

   weight 3 · round drawn
   Stagehand—none0/10

   The evidence describes Stagehand's act/observe/extract primitives for executing AI-driven browser actions, caching, and self-healing selectors, but nothing about defining persistent rules that automatically trigger on events (e.g., webhooks, schedules, DOM-change listeners) outside of an explicit script invocation.

   ⚑ flag

   Steel—none0/10

   Steel's evidence covers sessions, proxies, captcha solving, CLI, and agent traces, but nothing describes a rules engine or event-triggered automation (e.g., 'if X happens then do Y') that a user could configure declaratively.

   ⚑ flag

Local

1. developerRun the agent against a local browser on my own machine for development, without any cloud account

   weight 2 · round to Steel
   Stagehand✓fullclaimed7/10

   Docs confirm Stagehand can attach to a local Chromium browser over CDP (localBrowser.connect) and persist local user data on disk, meaning it can run fully locally without Browserbase/cloud accounts; Browserbase is presented as optional rather than required. missing for 10: independent hands-on confirmation of a pure-local run with no cloud account, and clearer docs distinguishing local-only setup from Browserbase defaults.

   • [claimed-docs] “Attach over CDP (localBrowser.connect): Attach to any Chromium browser you are already running, by URL”
   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “When you know the selector or want zero inference, use page methods you already know.”

   proof ↗⚑ flag

   Steel✓fullprobed9/10

   Steel Browser is open-source and can be self-hosted via Docker with no cloud account, confirmed by a runtime probe showing a local Docker container booting the browser API, creating live sessions, and working with the official CLI and SDK entirely locally. missing for 10: independent third-party (non-vendor) confirmation of long-term local dev workflow beyond the single recorded probe.

   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
   • [github] “Pre-built Docker Image (combined API + UI)”
   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
   • [probe] “official CLI documented at https://docs.steel.dev/overview/steel-cli”

   proof ↗⚑ flag

Frameworks

1. developerPlug the browser layer into agent frameworks (Claude Agent SDK, Vercel AI SDK, LangChain, CrewAI) through documented adapters

   weight 2 · round to Steel
   Stagehand~partialprobed4/10

   Docs and community evidence confirm a documented MCP/stdio integration for Claude Code agents (and a Browserbase MCP server actually powered by Stagehand), but there is no evidence of documented adapters for Vercel AI SDK, LangChain, or CrewAI as the story specifically requires. missing for 10: Vercel AI SDK adapter docs, LangChain adapter docs, CrewAI adapter docs, and any first-party guide unifying these framework integrations.

   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”
   • [community] “Our Stagehand MCP server actually won Anthropic's Claude MCP hackathon :) ... We're working on a better computer use integration using Stage…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Steel~partialclaimed5/10

   Steel documents a concrete integration with the Claude Agent SDK exposing its browser as in-process MCP tools (steel-docs-9), showing at least one first-party framework adapter exists. However, the evidence pack contains no documented adapters or integration guides for Vercel AI SDK, LangChain, or CrewAI, so the broader multi-framework claim is only partially substantiated. missing for 10: documented adapters for Vercel AI SDK, LangChain, and CrewAI, plus independent corroboration of any of these integrations working in practice.

   • [claimed-docs] “The Steel integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the browser.”

   proof ↗⚑ flag

Models

1. developerBring my own LLM provider — the framework is model-agnostic rather than locked to one vendor's models

   weight 2 · round drawn
   Stagehand—none0/10

   The evidence pack never documents which LLM providers Stagehand supports or describes any provider-swapping configuration; it only notes that a 'model key' is required to run (stagehand-probe-rt-1), without specifying that multiple vendors' models are interchangeable. Missing for 10: any docs or examples showing configuration for OpenAI/Anthropic/other providers, a provider-agnostic API surface, or community confirmation of using non-default models.

   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Steel—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

Tasks

1. ai agentSubmit a browser task over a hosted HTTP API and receive the result by polling or webhook, without managing any browser myself

   weight 2 · round drawn
   Stagehand—none0/10

   Stagehand is presented as an SDK/library (with an MCP server for agent tool-use) rather than a hosted HTTP task-submission API; the probe explicitly found no OpenAPI/REST endpoint (openapi paths all 404), and no docs describe submitting a task and polling or receiving a webhook result. Evidence shows Browserbase-hosted browser sessions and MCP/stdio integration, but nothing matching the described async HTTP task API.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.stagehand.dev/openapi.json, https://docs.stagehand.dev/swagger.json, https://docs.stage…”
   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”

   proof ↗⚑ flag

   Steel—none0/10

   Steel's docs describe a Sessions API that hands agents a raw, controllable browser (via CDP/Puppeteer/Playwright) plus a CLI for scripted step-by-step actions, but there is no evidence of a higher-level 'submit a task, poll or get a webhook for the result' abstraction — the agent still must drive the browser session itself rather than delegate a task and retrieve a finished output.

   • [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”

   proof ↗⚑ flag

2. developerHand the product a natural-language goal and it completes a multi-step web task end to end — navigating, filling forms, and clicking through flows

   weight 3 · round drawn
   Stagehand~partialcommunity5/10

   Stagehand's docs confirm natural-language act()/observe()/extract() primitives that can navigate, click, and fill forms, plus self-healing and iframe/shadow-DOM handling that support robustness across steps, and community posts confirm real-world scraping/automation use (stagehand-comm-1, stagehand-comm-9). However, the evidence shows these as composable single-action primitives rather than a documented single-call 'give it a goal and it autonomously completes a multi-step flow' agent mode — multi-step chains appear to require the developer to sequence act/observe/extract calls or wire it via MCP into another agent (stagehand-docs-11). Missing for 10: first-party or hands-on evidence of a single natural-language goal driving full end-to-end multi-step task completion without developer-orchestrated step chaining.

   • [claimed-docs] “Execute actions using natural language”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “Turn on `selfHeal` to re-infer an action when its recorded selector breaks.”
   • [claimed-docs] “Stagehand automatically handles iFrame traversal and shadow DOM elements without requiring additional configuration.”
   • [claimed-docs] “Give a Claude Code agent persistent Stagehand browser tools over MCP/stdio.”
   • [community] “I've been playing around with Stagehand for a minute now, actually a useful abstraction here. We build scrapers for websites that are pretty…”
   • [community] “Playwright codegen is incredibly powerful, but still pretty brittle. Its DOM selectors are still hardcoded... With Stagehand, the code is se…”

   proof ↗⚑ flag

   Steel~partialprobed5/10

   Steel provides the browser primitives (sessions, navigate/click/fill/extract via CLI or API, CDP control) that a multi-step web task requires, and its CLI/MCP integrations let external agent frameworks drive those actions from natural-language goals. However, Steel's own docs state the agent loop and NL reasoning are handled by the paired SDK (e.g., Claude Agent SDK), not by Steel itself — Steel 'handles the browser' while the SDK runs the reasoning loop, so Steel alone does not accept a raw NL goal and autonomously plan/execute it end to end. missing for 10: evidence of Steel natively parsing/planning from a raw NL instruction without an external agent/LLM orchestrating the steps, and independent hands-on proof of a full NL-driven multi-step flow completed unattended.

   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [claimed-docs] “The Steel integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the browser.”
   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”

   proof ↗⚑ flag

Workflows

1. automation-engineerCompose repeatable multi-step workflows with loops, conditionals, and parameters instead of one-shot prompts

   weight 2 · round to Stagehand
   Stagehand~partialclaimed5/10

   Stagehand is a code-first SDK (act/observe/extract primitives) that developers embed in regular TypeScript/Python code, which implicitly allows loops, conditionals, and parameters since it's just function calls in a host language — but no docs explicitly describe workflow composition, control-flow patterns, or parameterized repeatable workflows as a first-class feature. missing for 10: explicit workflow/orchestration documentation, examples of loops or conditionals chaining act/observe/extract calls, parameterized workflow templates, and any community evidence of engineers building such multi-step conditional workflows.

   • [claimed-docs] “extract() grabs structured data from a webpage. Every call takes an instruction and an output shape”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”
   • [claimed-docs] “When you know the selector or want zero inference, use page methods you already know.”
   • [claimed-docs] “Stagehand caches `act()`, `observe()`, and `extract()` results server-side to reduce LLM costs and speed up your automations.”

   proof ↗⚑ flag

   Steel—none0/10

   Steel's docs describe browser session management, stealth, CLI scripting of sequential steps (create session → navigate → click/fill → extract → stop), and MCP tool exposure, but nothing in the evidence pack shows a workflow-composition layer with loops, conditionals, or parameterized branching — the CLI and SDK are linear step sequences, not a control-flow DSL. missing for 10: any documented loop/conditional constructs, parameterized workflow templates, or reusable multi-branch automation definitions.

   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”

   proof ↗⚑ flag

1. ai-native userExport all of my data in open formats and leave

   weight 3 · round to Steel
   Stagehand—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Steel~partialprobed5/10

   Steel's agent-traces feature explicitly supports exporting run data as markdown, JSON, or a ZIP with markdown+screenshots (steel-docs-7), and the product itself is open-source and self-hostable (steel-gh-4, steel-probe-rt-1), meaning users are never locked into a proprietary cloud and can run/keep everything themselves. However, there's no documented comprehensive 'export all my data' capability covering sessions, auth contexts, or account-level data beyond traces. Missing for 10: a documented full-account data export/portability feature covering sessions, auth states, and configs, not just trace recordings.

   • [claimed-docs] “Copy the run as markdown, download JSON, or grab a ZIP with markdown plus screenshots.”
   • [github] “Pre-built Docker Image (combined API + UI)”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”

   proof ↗⚑ flag

2. ai-native userRead the product's source under an open license

   weight 2 · round to Steel
   Stagehand—none0/10

   The evidence pack contains only docs, community discussion, and runtime probes about Stagehand's automation features; none of it references a public source repository, license, or open-source status. Missing for 10: any mention of a GitHub repo, license file, or open-source claim.

   ⚑ flag

   Steel~partialprobed6/10

   The product's llms.txt explicitly states 'Steel is the open-source browser API for AI agents,' there's a public GitHub repo (steel-dev/steel-browser) with feature docs, and a runtime probe confirms the self-hostable OSS image can be pulled and run via Docker — all consistent with source availability. However, no evidence pack item names or shows a specific OSS license (e.g., MIT/AGPL) or a LICENSE file, so the exact openness terms are unconfirmed. Missing for 10: explicit license file/type citation, independent confirmation of license terms.

   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
   • [github] “Pre-built Docker Image (combined API + UI)”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.steel.dev/llms.txt # Steel Documentation > Steel is the open-source browser API for AI agents — ma…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
   • [community] “beautiful docs + api ref! what are you using? (cool that you're doing open-source browserbase also, excited to check this out)”

   proof ↗⚑ flag

3. ai-native userSelf-host the core product

   weight 3 · round to Steel
   Stagehand~partialprobed6/10

   Stagehand is installable via npm and can run against a locally-controlled Chromium instance via CDP (localBrowser.connect), and the runtime probe confirms local install/execution without requiring Browserbase credentials, indicating the core library can be self-hosted. However, several advanced features (proxies, captcha handling, session recording, multi-region hosting) are documented as Browserbase-cloud-only, and there is no explicit self-hosting/Docker deployment guide or licensing statement. Missing for 10: dedicated self-host deployment docs, confirmation that captcha/proxy features work without Browserbase, and independent hands-on confirmation of a fully self-hosted setup.

   • [claimed-docs] “Attach over CDP (localBrowser.connect): Attach to any Chromium browser you are already running, by URL”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/stagehand/): `npm install @browserbasehq/stagehand` completed and the ESM…”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”

   proof ↗⚑ flag

   Steel✓fullprobed10/10

   Steel is explicitly open-source with a pre-built Docker image (combined API + UI), and a runtime probe confirms a full keyless self-host roundtrip: docker-running the OSS image, health check succeeding, and creating/listing live browser sessions, corroborating vendor docs and GitHub claims.

   • [github] “Pre-built Docker Image (combined API + UI)”
   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.steel.dev/llms.txt # Steel Documentation > Steel is the open-source browser API for AI agents — ma…”

   proof ↗⚑ flag

Pricing

1. developerSee transparent per-task or per-browser-hour pricing and documented rate/concurrency limits before committing

   weight 2 · round drawn
   Stagehand—none0/10

   No evidence pack items mention pricing tiers, per-task/per-browser-hour costs, or documented rate/concurrency limits — docs cover only technical features (caching, contexts, regions) and community comments are unrelated to pricing transparency.

   ⚑ flag

   Steel—none0/10

   No first-party documentation in the evidence pack lays out per-task or per-browser-hour pricing or concurrency/rate limits; the only pricing-related evidence is a community report of inconsistency between the pricing page and docs pricing ($59 vs $99), which itself signals the opposite of transparent, dependable pricing rather than confirming it.

   • [community] “Looking interesting, will definitely give it a go. Btw, there is inconsistency between pricing page and pricing on docs. Pricing page for de…”

   proof ↗⚑ flag

1. ai-native userChoose where my data is stored (region/residency)

   weight 2 · round to Stagehand
   Stagehand~partialclaimed6/10

   Docs state Browserbase-hosted sessions can be started in one of four regions and that this can keep session data in a required jurisdiction, giving some data-residency control (stagehand-docs-9). However this only covers Browserbase-run browser sessions, not other data flows like server-side act/observe/extract caching (stagehand-docs-6) or local user-data directories (stagehand-docs-7), and there is no independent/hands-on confirmation of residency guarantees. Missing for 10: region control over cached LLM/action results and other stored artifacts, explicit compliance/residency guarantees, and third-party verification.

   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [claimed-docs] “Stagehand caches `act()`, `observe()`, and `extract()` results server-side to reduce LLM costs and speed up your automations.”
   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”

   proof ↗⚑ flag

   Steel~partialprobed4/10

   Steel offers a self-hostable open-source Docker image (steel-gh-4, steel-probe-rt-1) which lets users control where their data physically resides by hosting it themselves, but there is no explicit region/residency selection feature documented for the managed cloud offering. missing for 10: explicit region-selection UI/API for the managed cloud service, documentation on data residency guarantees or compliance certifications (e.g., GDPR/SOC2 region controls).

   • [github] “Pre-built Docker Image (combined API + UI)”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”

   proof ↗⚑ flag

2. ai-native userPrevent my data from being used to train AI models

   weight 3 · round drawn
   Stagehand—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

   Steel—none0/10

   The axis applies to this product kind (peer products hold positive or none verdicts on this story), so lack of evidence for an applicable capability is "none", never "na". (na/none harmonized at arena bring-up — see pipeline/scripts/na-harmonize.ts.)

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Steel
   Stagehand—none0/10

   Docs describe persisting user data (cookies/local storage, Browserbase contexts) and choosing a data region for jurisdiction, but there is no evidence of any deletion controls, retention limits, or user-facing settings to purge stored session/browser data. missing for 10: explicit retention policy, deletion/purge mechanism, and user controls over how long session data or extracted data is kept.

   • [claimed-docs] “Stagehand creates the directory if it does not exist and leaves it in place after the browser shuts down, so the next run starts from the sa…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”

   proof ↗⚑ flag

   Steel~partialprobed4/10

   Steel is open-source and self-hostable (steel-gh-4, steel-probe-rt-1), which gives users full control over where session data lives and how long it's retained, and session lifecycle docs show sessions can be created/stopped with custom IDs (steel-docs-10). However, there is no explicit documentation of a retention policy, data-deletion API, or GDPR-style controls for the managed cloud offering. Missing for 10: documented retention/deletion controls or policy for the hosted cloud service, explicit data-purge API, independent confirmation of retention behavior.

   • [github] “Pre-built Docker Image (combined API + UI)”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
   • [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”

   proof ↗⚑ flag

4. ai-native userOpt out of telemetry and usage tracking

   weight 2 · round drawn
   Stagehand—none0/10

   No evidence pack item discusses telemetry, usage tracking, or opt-out settings for Stagehand; documentation covers automation features, caching, and Browserbase infrastructure but is silent on telemetry practices.

   ⚑ flag

   Steel—none0/10

   No evidence pack item mentions telemetry, analytics, usage tracking, or an opt-out mechanism; the self-hostable OSS nature is noted (steel-probe-rt-1) but that alone does not confirm any telemetry opt-out control exists or is documented.

   ⚑ flag

Live

1. automation-engineerWatch a session live and take human control mid-run when the agent gets stuck

   weight 2 · round to Steel
   Stagehand~partialclaimed4/10

   Stagehand's docs mention Browserbase's session dashboard offering real-time browser screen recording and replay, which covers 'watching a session live,' but there is no evidence of a mechanism to hand control back to a human mid-run when the agent stalls. missing for 10: explicit live take-over/human-in-the-loop control feature, evidence of pausing agent execution for manual intervention, and independent confirmation of this workflow.

   • [claimed-docs] “Browserbase provides real-time visibility into your automation sessions: **Session dashboard features** * Real-time browser screen recordi…”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”

   proof ↗⚑ flag

   Steel✓fullprobed8/10

   Steel's debug URL feature is explicitly documented for human-in-the-loop workflows enabling users to directly interact with and control a live browser session, and runtime proof confirms sessions expose a live debugger/websocket URL for real-time viewing/control. The agent-traces timeline feature complements this by letting engineers review what happened, though it's more post-hoc than live takeover. Missing for 10: explicit documentation of mid-run handoff back to the agent after human control, and independent/community corroboration of the human-in-the-loop debug feature specifically (vs. general product commentary).

   • [claimed-docs] “Steel's debug URL feature allows you to implement human-in-the-loop workflows where users can directly interact with and control browser ses…”
   • [claimed-docs] “It turns the run into a timeline of agent activity, so you can see what happened without scrubbing through the whole recording.”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”

   proof ↗⚑ flag

Replay

1. automation-engineerDebug a failed agent run from recorded replays — video, screenshots, step-by-step action timelines

   weight 2 · round to Steel
   Stagehand~partialclaimed5/10

   Stagehand relies on Browserbase's session dashboard for real-time screen recording and replay, giving some visibility into runs, but there is no documented step-by-step action timeline correlated with agent decisions, no screenshot-per-step artifact, and no dedicated debugging/replay tooling built into Stagehand itself. missing for 10: native step-by-step action timeline tied to LLM decisions, per-step screenshots, first-party replay/debug UI (beyond Browserbase's generic session recording), independent hands-on confirmation of replay-based debugging workflows.

   • [claimed-docs] “Browserbase provides real-time visibility into your automation sessions: **Session dashboard features** * Real-time browser screen recordi…”

   proof ↗⚑ flag

   Steel✓fullclaimed7/10

   Steel's Agent Traces feature explicitly turns a run into a timeline of agent activity with screenshots, and lets you export as markdown, JSON, or a ZIP with markdown+screenshots, directly matching the replay-debugging story for automation engineers. Missing for 10: explicit video recording/playback evidence and independent/hands-on corroboration of the traces UI beyond first-party docs.

   • [claimed-docs] “It turns the run into a timeline of agent activity, so you can see what happened without scrubbing through the whole recording.”
   • [claimed-docs] “Copy the run as markdown, download JSON, or grab a ZIP with markdown plus screenshots.”
   • [claimed-docs] “Steel's debug URL feature allows you to implement human-in-the-loop workflows where users can directly interact with and control browser ses…”

   proof ↗⚑ flag

Fleets

1. automation-engineerRun a fleet of concurrent browser sessions with documented concurrency limits and programmatic session management

   weight 2 · round to Steel
   Stagehand—none0/10

   The evidence shows Stagehand/Browserbase supports single-session configuration (regions, contexts, persistence, observability) but nowhere documents fleet-level concurrency limits or APIs for managing many concurrent sessions programmatically. Missing for 10: documented concurrency caps, fleet/session-pool management API, and any evidence of running many sessions in parallel.

   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”
   • [claimed-docs] “Browserbase provides real-time visibility into your automation sessions: **Session dashboard features** * Real-time browser screen recordi…”
   • [claimed-docs] “For Browserbase sessions, use contexts to persist browser data”

   proof ↗⚑ flag

   Steel~partialprobed6/10

   Steel's Sessions API and CLI clearly support spinning up isolated on-demand browser sessions with custom session IDs, and a runtime probe confirms working session creation/listing via self-hosted API — solid programmatic session management. However, the evidence pack contains no documented concurrency limits, quotas, or fleet-scale guidance for running many sessions in parallel. Missing for 10: explicit documented concurrency/session limits, guidance or examples for orchestrating many simultaneous sessions, and independent corroboration of scale behavior.

   • [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
   • [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
   • [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”

   proof ↗⚑ flag

Lifecycle

1. developerGet webhook notifications when tasks and sessions finish instead of polling for status

   weight 1 · round drawn
   Stagehand—none0/10

   No evidence of any webhook/callback mechanism for task or session completion; Stagehand's docs focus on act/observe/extract, caching, and session dashboards but nothing about push notifications replacing polling.

   ⚑ flag

   Steel—none0/10

   No evidence pack item mentions webhooks, event callbacks, or push notifications for session/task completion; Steel's docs cover sessions API, CLI, proxies, captcha, and traces but nothing about async status notifications, implying developers must poll session status endpoints.

   ⚑ flag

Captcha

1. automation-engineerRely on a documented captcha stance — automatic solving, human fallback, or explicit non-support — instead of silent task failures

   weight 2 · round to Steel
   Stagehand~partialcommunity3/10

   Only a single community anecdote claims Stagehand/Browserbase have 'built in proxies and captcha' handling, but no first-party documentation in the pack states an explicit captcha policy (auto-solve, human fallback, or non-support). missing for 10: official docs describing captcha handling behavior, guidance on fallback/human-in-the-loop when captchas are hit, and independent verification beyond one forum comment.

   • [community] “I've been playing around with Stagehand for a minute now, actually a useful abstraction here. We build scrapers for websites that are pretty…”
   • [community] “I recently tried to implement a workflow automation using similar frameworks that were playwright or puppeteer based... What stopped me enti…”

   proof ↗⚑ flag

   Steel✓fullclaimed8/10

   Steel documents a single explicit flag covering captcha detection, solving, and verification for the whole session, plus a separate human-in-the-loop debug URL feature for manual takeover when needed — giving automation engineers a documented stance rather than silent failures. Missing for 10: independent/hands-on verification that automatic captcha solving actually succeeds on real-world captchas, and clearer documentation of failure/fallback behavior when auto-solve fails.

   • [claimed-docs] “One flag covers detection, solving, and verification for the whole session”
   • [claimed-docs] “Steel's debug URL feature allows you to implement human-in-the-loop workflows where users can directly interact with and control browser ses…”

   proof ↗⚑ flag

Posture

1. automation-engineerPoint to the vendor's published acceptable-use and anti-abuse posture governing what its stealth and automation features may be used for

   weight 1 · round drawn
   Stagehand—none0/10

   No evidence pack item references a published acceptable-use policy, anti-abuse terms, or governance statement about how Stagehand's automation/anti-detection features may or may not be used; docs focus entirely on features (act/observe/extract, caching, proxies) with no mention of usage policy or abuse prevention stance.

   ⚑ flag

   Steel—none0/10

   The evidence pack documents Steel's stealth/captcha-solving, proxy, and CAPTCHA features extensively, but contains no published acceptable-use policy, terms of service, or anti-abuse statement governing what these stealth capabilities may be used for. No AUP, ToS, or anti-abuse page is cited or referenced anywhere in the docs, GitHub repo, or community discussion. Missing for 10: a published acceptable-use policy, anti-abuse/misuse guidelines, or ToS language specifically addressing stealth/captcha feature usage.

   ⚑ flag

Stealth

1. automation-engineerEnable stealth fingerprinting and residential or geo-targeted proxies so legitimate automations aren't blocked as bots

   weight 2 · round to Steel
   Stagehand~partialcommunity5/10

   A community hands-on comment praises Stagehand/Browserbase's 'built in proxies and captcha' handling for adversarial sites, and docs confirm Browserbase supports multi-region session placement (geo-targeting) — but there is no first-party documentation of stealth fingerprinting configuration or explicit residential-proxy selection controls. missing for 10: dedicated docs on fingerprint spoofing/stealth mode, explicit residential proxy configuration options, and independent verification that bot-block evasion works reliably.

   • [community] “I've been playing around with Stagehand for a minute now, actually a useful abstraction here. We build scrapers for websites that are pretty…”
   • [community] “I recently tried to implement a workflow automation using similar frameworks that were playwright or puppeteer based... What stopped me enti…”
   • [claimed-docs] “Browserbase runs browsers in four regions, so you can cut latency by starting the browser near your users or your target site, and keep sess…”

   proof ↗⚑ flag

   Steel✓fullcommunity8/10

   Steel's docs explicitly document stealth mode (single flag covering detection evasion, captcha solving, and verification) plus both Managed Residential Proxies and Bring-Your-Own-Proxy (BYOP) for geo-targeting, directly matching the story, and community comment confirms custom proxy support works in practice. Missing for 10: no independent/hands-on evidence quantifying bot-detection bypass success rates or geo-targeting granularity, and no first-party benchmark showing reduced block rates.

   • [claimed-docs] “One flag covers detection, solving, and verification for the whole session”
   • [claimed-docs] “Steel offers two powerful ways to use proxies: our built-in **Managed Residential Proxies** or connecting to your own proxy provider with ou…”
   • [community] “It appears you can set your own proxies to not use their cloud.”

   proof ↗⚑ flag

Extraction

1. developerExtract typed, schema-validated data (Zod/Pydantic-style) from pages the agent visits, not just raw text

   weight 3 · round to Stagehand
   Stagehand✓fullclaimed7/10

   Stagehand's documented extract() API takes an instruction plus an output shape (schema), directly matching typed/schema-validated extraction rather than raw text scraping. Missing for 10: explicit mention of Zod/Pydantic naming in the evidence pack, independent/hands-on confirmation of schema validation behavior beyond docs.

   • [claimed-docs] “extract() grabs structured data from a webpage. Every call takes an instruction and an output shape”
   • [claimed-docs] “observe() discovers actionable elements on a page and returns structured actions you can execute or validate before acting.”

   proof ↗⚑ flag

   Steel—none0/10

   Steel's docs/GitHub only show raw content extraction utilities (markdown, readability, screenshots, PDF conversion) and generic 'extract content' CLI commands, with no mention of Zod/Pydantic-style schema validation or typed structured outputs. The axis is fair for a browser-automation API since competitors offer schema-based extraction, but no evidence shows Steel provides this.

   • [github] “Browser Tools: Exposes APIs to quick convert pages to markdown, readability, screenshots, or PDFs.”
   • [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”

   proof ↗⚑ flag

Files

1. developerMy agent can download files from and upload files to the sites it operates, with the artifacts retrievable afterwards

   weight 1 · round drawn
   Stagehand—none0/10

   The evidence pack covers Stagehand's act/observe/extract primitives, session persistence, and MCP integration, but nowhere mentions file download/upload handling or artifact retrieval after a session ends. Since browser automation tools plausibly support file transfer, this is an applicable axis with no supporting evidence.

   ⚑ flag

   Steel—none0/10

   The evidence covers session artifacts (traces, screenshots, page-to-markdown conversion) and CLI-driven browser control, but nothing documents actual file upload to web forms or downloading files from a site with persistent artifact retrieval — a distinct capability from trace export.

   ⚑ flag