Browser Use vs Stagehand

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
   Browser Use—none0/10

   No evidence of caching resolved actions or generated code for deterministic, lower-cost replay; the product is LLM-driven agent automation with sessions/runs but nothing about caching or replay without re-invoking the model. missing for 10: any mention of action/code caching, deterministic replay mechanism, or cost/latency savings from skipping re-prompting.

   ⚑ flag

   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

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
   Browser Use~partialcommunity6/10

   Browser Use's core agent is built around natural-language task instructions (e.g. "Find the top Hacker News story", "Fill in this job application") executed via an LLM-driven agent that perceives the DOM/page state and decides actions, which is the essence of DOM-understanding, layout-resilient automation — this is corroborated by GitHub task examples and community hands-on use (LinkedIn automation, resume filling). However, the evidence pack lacks explicit documentation of discrete act/click/type primitives with described-element targeting or any stated guarantee/mechanism for surviving selector/layout changes; it's inferred from the agent's general design rather than directly documented. missing for 10: explicit API/primitive-level documentation of click/type/act-on-described-element functions, and direct evidence/testing showing resilience to selector or layout changes rather than just general LLM-driven task completion.

   • [github] “Task: "Fill in this job application with my resume and information."”
   • [github] “Task: "Extract structured data about my followers and export it as a CSV."”
   • [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”

   proof ↗⚑ flag

   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

Observe

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

   weight 1 · round to Stagehand
   Browser Use—none0/10

   Evidence shows live-preview URLs for human intervention during CAPTCHA/2FA and event polling for observability, but nothing about an explicit preview/plan step where candidate actions are surfaced for developer review before the agent commits to acting.

   • [claimed-docs] “If the challenge remains, open the [live preview](/cloud/browser/live-preview) for human control.”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
   • [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event]”

   proof ↗⚑ flag

   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

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
   Browser Use—none0/10

   Browser Use's docs describe DOM-based agent actions, live preview/human handoff for CAPTCHA/2FA, and CDP-based control, but there is no evidence of a dedicated vision or computer-use mode that acts directly on screenshots for canvas/UI elements the DOM can't reach.

   ⚑ flag

   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

Agent access

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

   weight 2 · round drawn
   Browser Use✓fullprobed8/10

   Browser Use publishes a discoverable llms.txt at docs.browser-use.com/llms.txt confirmed live via probe (HTTP 200), which is exactly the agent-oriented docs entry point an AI-native user could point an agent at, and the broader docs site is structured/markdown-friendly for agent consumption. Missing for 10: no evidence of additional structured formats like llms-full.txt or explicit guidance encouraging agents to consume it, and no independent community confirmation of agents successfully using it.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browser-use.com/llms.txt # Browser Use > Documentation for Browser Use Cloud Agent and Browser API…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Stagehand
   Browser Use~partialclaimed6/10

   Browser Use ships both an open-source Python library and a cloud API (client.runs.create) that are inherently script/automatable, implying headless/CI use, and gh-3 explicitly pitches automating the web 'from your own code, and with any LLM.' However, there is no explicit documentation of headless mode flags, Docker images, or CI pipeline examples/integration guides. Missing for 10: explicit headless-mode configuration docs, CI/CD pipeline examples (e.g., GitHub Actions), and independent confirmation of running unattended in CI.

   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
   • [claimed-docs] “For a local agent, use the [open-source library](/open-source/quickstart).”
   • [claimed-docs] “Launch a browser, connect to its CDP URL, then stop it”

   proof ↗⚑ flag

   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

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

   weight 3 · round to Stagehand
   Browser Use!disputedcontradicted5/10

   Docs describe an official MCP server enabling Claude, Cursor, Windsurf or any MCP client to run Browser Use tasks (browser-use-docs-12, browser-use-probe-3), but a hands-on community report says the author had to switch tools because Browser Use 'doesn't support MCP integration' in Cursor (browser-use-comm-4), directly contradicting the documented claim. Missing for 10: independent corroboration that MCP connection actually works end-to-end, and resolution of the conflicting user report.

   • [claimed-docs] “Run browser automation tasks from your AI coding assistant. Connect to Claude, Cursor, Windsurf, or any MCP client.”
   • [probe] “official MCP server documented at https://docs.browser-use.com/cloud/guides/mcp-server”
   • [community] “I want to use browser-use in Cursor but I am using another option because it doesn't support MCP integration which is the common language th…”

   proof ↗⚑ flag

   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

4. ai-native userUse an official CLI

   weight 2 · round drawn
   Browser Use—none0/10

   The evidence pack documents a Python SDK, cloud API, MCP server, and web dashboard, but never mentions an official standalone CLI tool for Browser Use. Since a browser-automation product could plausibly ship a CLI, absence of any such evidence means this axis is unmet.

   ⚑ flag

   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

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

   weight 3 · round to Stagehand
   Browser Use~partialprobed7/10

   Browser Use documents a public Cloud API (client.runs.create, sessions, events polling, structured output, CDP connection) across multiple docs pages, indicating a real programmatic interface beyond the UI. However, probes for a formal OpenAPI/swagger spec returned 404s, so there's no machine-readable API contract, only prose docs and SDK examples. Missing for 10: a published OpenAPI/spec artifact, independent third-party confirmation of API usage beyond vendor docs.

   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
   • [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
   • [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browser-use.com/llms.txt # Browser Use > Documentation for Browser Use Cloud Agent and Browser API…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Browser Use—none0/10

   No evidence of scoped or least-privilege API key/credential issuance (e.g., role-based tokens, permission scopes) for agents; docs mention API keys implicitly via client usage but no mention of scoping, restricted permissions, or credential management features. Community/GitHub evidence also silent on this.

   ⚑ flag

   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

7. ai-native userBuild against official SDKs

   weight 2 · round to Stagehand
   Browser Use✓fullprobed7/10

   Browser Use ships an official open-source Python library (github, docs-19) and a cloud client SDK with documented usage patterns (client.runs.create, sessions, events polling) shown in docs-1/4/5/14, giving AI-native devs a concrete first-party SDK to build against. Missing for 10: evidence of SDKs beyond Python (e.g. JS/TS), and no OpenAPI spec was found (probe-2 all 404) or independent third-party corroboration of SDK usage.

   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
   • [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
   • [claimed-docs] “For a local agent, use the [open-source library](/open-source/quickstart).”
   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”

   proof ↗⚑ flag

   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

Agentic features

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

   weight 2 · round drawn
   Browser Use~partialclaimed5/10

   Browser Use Cloud lets users kick off agent runs via API (client.runs.create) that execute asynchronously in a hosted browser, with session reuse and event polling to monitor progress without keeping a local process open, which supports a form of unattended background execution. However there is no documented scheduling, cron-like triggers, or webhook-based automation setup for recurring/background jobs, so it's unclear whether truly hands-off recurring automations are supported. Missing for 10: explicit scheduling/trigger mechanism, evidence of long-running unattended jobs beyond single API-invoked runs, and independent confirmation of background reliability.

   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
   • [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
   • [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Stagehand
   Browser Use✓fullcommunity8/10

   Browser Use is fundamentally natural-language driven: tasks are issued as plain-English strings like "Find the top Hacker News story" or "Fill in this job application with my resume and information", with the agent interpreting and executing them autonomously, corroborated by GitHub examples and community hands-on use for LinkedIn automation. missing for 10: independent benchmark of instruction-following accuracy, and clearer docs on limits/failure modes of natural-language parsing.

   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [github] “Task: "Fill in this job application with my resume and information."”
   • [github] “Task: "Extract structured data about my followers and export it as a CSV."”
   • [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”

   proof ↗⚑ flag

   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

Api quality

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

   weight 2 · round drawn
   Browser Use—none0/10

   Docs show static code snippets (e.g., client.runs.create examples) but no evidence of an interactive, runnable API console/reference; explicit probes for OpenAPI/Swagger specs at standard paths all returned 404, indicating no interactive API explorer exists.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”
   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browser-use.com/llms.txt # Browser Use > Documentation for Browser Use Cloud Agent and Browser API…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Browser Use—none0/10

   A direct probe for OpenAPI/swagger spec files returned 404 on all candidate paths, and no documentation references a downloadable machine-readable API spec despite having a REST/cloud API.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”

   proof ↗⚑ flag

   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

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

   weight 1 · round drawn
   Browser Use—none0/10

   The evidence describes cloud browser sessions, live preview, and CDP connections, but nothing indicates a dedicated sandbox/staging mode that isolates test runs from production data or real accounts. Users are shown reusing real logged-in profiles (browser-use-comm-5) rather than isolated test environments, and no docs mention a sandbox distinct from production.

   • [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
   • [claimed-docs] “Log in once, save the profile, then reuse it to start future browsers already logged in.”
   • [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”

   proof ↗⚑ flag

   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

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

   weight 2 · round drawn
   Browser Use—none0/10

   Evidence shows an API version label ("V4") in docs, but there is no documented deprecation policy, versioning changelog, or API stability guarantees anywhere in the pack; the OpenAPI spec probe also 404s, indicating no formal API contract is published.

   • [claimed-docs] “V4 returns `run.result` as a string. Ask for JSON only, then validate it client-side”
   • [claimed-docs] “Automatic CAPTCHA solving is enabled by default for API V4 Agent runs and standalone Cloud Browser sessions.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”

   proof ↗⚑ flag

   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

Compat

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

   weight 2 · round to Browser Use
   Browser Use✓fullcommunity7/10

   Docs explicitly describe connecting existing Playwright/Puppeteer/CDP code to Browser Use's browsers via CDP URL, with a documented choice between Browser Use driving or the developer's own code connecting directly over CDP (docs-2, docs-18), and community reports confirm connecting to a real local Chrome profile via CDP for existing automation. missing for 10: independent hands-on validation specifically with Playwright/Puppeteer libraries (not just CDP raw), and more detail on session/auth persistence when using external code.

   • [claimed-docs] “Launch a browser, connect to its CDP URL, then stop it”
   • [claimed-docs] “Choose whether Browser Use drives the browser or your Playwright/Puppeteer code connects directly over CDP.”
   • [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
   • [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”

   proof ↗⚑ flag

   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

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 to Browser Use
   Browser Use~partialclaimed5/10

   Browser Use supports saved/reused login profiles (docs-10) and a documented 2FA workflow where the run pauses at the challenge and a human enters the code via live view (docs-11/16), but there is no vault/secrets-manager integration for storing credentials and injecting them without model exposure, and TOTP is handled via human-in-the-loop rather than automated secret injection. missing for 10: a credential vault/secrets-manager integration, evidence that passwords/TOTP secrets are injected without ever passing through the model context, fully automated TOTP handling without human intervention, independent confirmation of the 2FA flow working in practice.

   • [claimed-docs] “Log in once, save the profile, then reuse it to start future browsers already logged in.”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event]”

   proof ↗⚑ flag

   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

Profiles

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

   weight 3 · round drawn
   Browser Use✓fullcommunity8/10

   Docs explicitly describe saving a login profile once and reusing it to start future browsers already logged in, plus a 2FA guide for handling the initial login flow, and community evidence confirms local profile reuse works for logged-in automation (e.g., LinkedIn). missing for 10: independent/hands-on corroboration specifically of the cloud profile-reuse feature (only local profile reuse is community-validated) and no detail on profile storage/security guarantees.

   • [claimed-docs] “Log in once, save the profile, then reuse it to start future browsers already logged in.”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event]”
   • [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Browser Use
   Browser Use~partialclaimed3/10

   The library is pitched for automating the web 'at scale' from custom code (gh-3) and cloud sessions can hold multiple runs, hinting at multi-task orchestration, but there is no explicit documentation of a batch/bulk API, parallel run submission, or looping over many items as a first-class feature. Missing for 10: dedicated bulk/batch endpoint or SDK pattern, concurrency limits/guidance, and hands-on evidence of running many items in one operation.

   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
   • [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Browser Use—none0/10

   Browser Use's evidence covers on-demand task runs, sessions, observability polling, CAPTCHA/stealth, and MCP integration, but nothing describes user-defined rules or triggers that fire actions automatically on external events (e.g., webhooks, schedules, conditional triggers). The product is presented as an agent you invoke to perform a task, not an event-driven automation/rules engine.

   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
   • [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
   • [claimed-docs] “Run browser automation tasks from your AI coding assistant. Connect to Claude, Cursor, Windsurf, or any MCP client.”
   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”

   proof ↗⚑ flag

   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

Local

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

   weight 2 · round to Browser Use
   Browser Use✓fullcommunity8/10

   Browser Use ships an open-source Python library explicitly positioned for local, code-driven automation ('For a local agent, use the open-source library'; 'automate the web at scale, from your own code, and with any LLM'), and community reports confirm running it locally against a real local Chrome browser/profile without a cloud account. missing for 10: no explicit walkthrough showing zero network/account calls during local runs, and no independent benchmark of purely offline/local operation.

   • [claimed-docs] “For a local agent, use the [open-source library](/open-source/quickstart).”
   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
   • [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
   • [claimed-docs] “Launch a browser, connect to its CDP URL, then stop it”

   proof ↗⚑ flag

   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

Frameworks

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

   weight 2 · round to Stagehand
   Browser Use—none0/10

   Evidence documents an MCP server for connecting to Claude, Cursor, or Windsurf, and a Python library for custom code, but there is no mention of documented adapters for Claude Agent SDK, Vercel AI SDK, LangChain, or CrewAI specifically.

   • [claimed-docs] “Run browser automation tasks from your AI coding assistant. Connect to Claude, Cursor, Windsurf, or any MCP client.”
   • [probe] “official MCP server documented at https://docs.browser-use.com/cloud/guides/mcp-server”
   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”

   proof ↗⚑ flag

   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

Models

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

   weight 2 · round to Browser Use
   Browser Use✓fullcommunity8/10

   GitHub docs explicitly market the library as usable with any LLM ('Use the Python library ... with any LLM'), and independent community testing corroborates this by reporting successful use with Gemini models rather than being locked to one vendor. Missing for 10: a dedicated docs page enumerating specific supported providers/configuration examples and broader independent confirmation across multiple providers beyond Gemini.

   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
   • [community] “From the first glance, browser-use is compatible with more models, and has (much) more github stars. Coincidentally I played with it over th…”

   proof ↗⚑ flag

   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

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 to Browser Use
   Browser Use✓fullprobed8/10

   Docs show a hosted Cloud API (client.runs.create) that creates runs, supports polling via runs.events() with cursors, and returns structured results without the caller managing browser infrastructure (stealth, proxies, CAPTCHA solving handled server-side). Missing for 10: no explicit webhook callback mechanism is documented (only polling is shown), and no public OpenAPI spec was found to confirm full REST surface.

   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [claimed-docs] “V4 returns `run.result` as a string. Ask for JSON only, then validate it client-side”
   • [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
   • [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
   • [claimed-docs] “Every cloud browser session runs in a hardened Chromium fork with stealth enabled by default — no configuration needed.”
   • [claimed-docs] “Residential proxies are enabled by default across 195+ countries.”
   • [claimed-docs] “Every Browser Use Cloud browser enables automatic CAPTCHA solving.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”

   proof ↗⚑ flag

   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

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 to Browser Use
   Browser Use✓fullcommunity8/10

   Docs and GitHub examples show natural-language goals (e.g., "Find the top Hacker News story", "Fill in this job application") driving an agent that navigates, logs in, handles 2FA/CAPTCHA, and completes multi-step flows end-to-end via both cloud API and open-source library; community reports corroborate real-world use (e.g., LinkedIn automation). Missing for 10: independent third-party benchmark of complex multi-step task success rates and more robust evidence of reliability at scale beyond anecdotal community reports.

   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [github] “Task: "Fill in this job application with my resume and information."”
   • [github] “Task: "Extract structured data about my followers and export it as a CSV."”
   • [claimed-docs] “Log in once, save the profile, then reuse it to start future browsers already logged in.”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
   • [claimed-docs] “Every Browser Use Cloud browser enables automatic CAPTCHA solving.”
   • [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”

   proof ↗⚑ flag

   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

Workflows

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

   weight 2 · round to Stagehand
   Browser Use—none0/10

   Evidence shows Browser Use runs are essentially single natural-language task strings within a session/run model (create run, poll events, reuse session) with no documented constructs for loops, conditionals, or parameterized workflow templates; the Python library is described as scriptable but no workflow-composition API (branching, iteration, variables) is shown.

   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
   • [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”

   proof ↗⚑ flag

   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

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

   weight 3 · round drawn
   Browser Use—none0/10

   The evidence pack describes agent runs, sessions, CAPTCHA handling, and pricing, but nothing documents an account/data export feature (e.g., downloading all run history, sessions, or stored data in an open format) that would let a user leave the platform with their data intact; the open-source library allows self-hosting but that's a separate capability from exporting existing cloud account data.

   ⚑ flag

   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

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

   weight 2 · round to Browser Use
   Browser Use~partialprobed5/10

   The GitHub repo (browser-use/browser-use) and docs reference an 'open-source library' with a public quickstart, indicating the core Python library's source is publicly viewable, but no evidence explicitly states an open-source license (e.g., MIT/Apache) or shows license text. missing for 10: explicit license file/declaration, confirmation of license type, evidence of full source (vs. cloud API) being open.

   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
   • [claimed-docs] “For a local agent, use the [open-source library](/open-source/quickstart).”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browser-use.com/llms.txt # Browser Use > Documentation for Browser Use Cloud Agent and Browser API…”

   proof ↗⚑ flag

   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

3. ai-native userSelf-host the core product

   weight 3 · round to Browser Use
   Browser Use✓fullprobed7/10

   Browser Use ships an open-source Python library (github.com/browser-use/browser-use) that runs locally and independently of the Cloud API, explicitly positioned as the option for self-hosted/local agents ("For a local agent, use the open-source library"), and community reports confirm running it locally connected to a real browser/profile. missing for 10: no first-party self-hosting guide covering infra/deployment (e.g. Docker, scaling), and no independent audit of parity between self-hosted and cloud feature sets (stealth, CAPTCHA solving, proxies are cloud-only per docs).

   • [claimed-docs] “For a local agent, use the [open-source library](/open-source/quickstart).”
   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
   • [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.browser-use.com/llms.txt # Browser Use > Documentation for Browser Use Cloud Agent and Browser API…”

   proof ↗⚑ flag

   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

Pricing

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

   weight 2 · round to Browser Use
   Browser Use~partialclaimed4/10

   Pricing page shows credits-based model ($5+ credits, no subscription, one-time $15 signup credit) but there is no documented per-task or per-browser-hour cost breakdown, and no documented rate/concurrency limits anywhere in the evidence. missing for 10: explicit per-task/per-browser-hour cost figures, documented rate limits, documented concurrency limits, any independent confirmation of pricing transparency.

   • [claimed-docs] “One-time $15 credit for eligible Google, GitHub or Microsoft signups ... No card required”
   • [claimed-docs] “Credits from $5. No subscription. No expiry.”

   proof ↗⚑ flag

   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

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

   weight 2 · round to Stagehand
   Browser Use—none0/10

   No evidence pack material addresses data residency, region selection, or storage location controls for cloud runs/sessions; the open-source library option avoids the cloud entirely but that's not the same as choosable region/residency within the product. missing for 10: any mention of data center regions, residency options, or storage location controls.

   ⚑ flag

   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

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

   weight 3 · round drawn
   Browser Use—none0/10

   No evidence in the pack addresses data usage for AI model training, opt-out policies, or privacy/data-retention commitments for Browser Use Cloud or the open-source library.

   ⚑ flag

   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

3. ai-native userControl data retention and deletion

   weight 2 · round drawn
   Browser Use—none0/10

   No evidence of data retention controls, deletion APIs, or privacy/data-lifecycle policy documentation anywhere in the pack; only session/profile reuse and credit pricing are mentioned. missing for 10: retention policy documentation, data deletion API/UI, export/erasure controls, any privacy compliance statement.

   ⚑ flag

   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

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

   weight 2 · round drawn
   Browser Use—none0/10

   No evidence in the pack mentions telemetry, usage data collection, or any opt-out/privacy setting for Browser Use; the documentation and community items cover unrelated features like stealth browsing, CAPTCHA solving, and MCP integration.

   ⚑ flag

   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

Live

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

   weight 2 · round to Browser Use
   Browser Use~partialclaimed6/10

   Docs describe a live_view_url/live preview that lets a human take control mid-run for cases like CAPTCHAs or 2FA, and events can be polled to monitor a run, which supports live-watch-and-intervene workflows. However, this is scoped to specific triggers (CAPTCHA/2FA) rather than a general 'agent gets stuck, operator takes over anytime' workflow, and there's no independent/hands-on evidence confirming smooth mid-run handoff in practice. missing for 10: general-purpose stuck-detection/handoff beyond CAPTCHA/2FA scenarios, independent hands-on confirmation of live takeover working reliably, clear UI/replay-debugging tooling details.

   • [claimed-docs] “If the challenge remains, open the [live preview](/cloud/browser/live-preview) for human control.”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event]”
   • [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
   • [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”

   proof ↗⚑ flag

   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

Replay

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

   weight 2 · round to Stagehand
   Browser Use~partialclaimed4/10

   Docs describe an observability/events stream (runs.events()) for monitoring a run and a live_view_url for real-time human intervention, which could support building a step timeline, but there is no explicit mention of recorded video or screenshot capture for post-hoc replay debugging of failed runs. Missing for 10: documented video recording of sessions, screenshot capture per action, and a dedicated replay/timeline UI for past runs.

   • [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
   • [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
   • [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event]”

   proof ↗⚑ flag

   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

Fleets

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

   weight 2 · round to Browser Use
   Browser Use~partialclaimed4/10

   Docs show programmatic session/run creation (client.runs.create, session IDs holding multiple runs) and event polling for observability, implying some ability to manage sessions programmatically, but there is no documented concurrency limit, no fleet/parallel-session guidance, and no scaling architecture described. missing for 10: documented concurrency limits, guidance/examples for running multiple concurrent sessions at scale, rate-limit or quota specs, and independent evidence of parallel session management working in practice.

   • [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
   • [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
   • [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
   • [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
   • [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”

   proof ↗⚑ flag

   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

Lifecycle

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

   weight 1 · round drawn
   Browser Use—none0/10

   Docs explicitly describe polling patterns for run status (runs.events() with cursor, polling ordered V4 events) but no webhook or callback-based notification mechanism is mentioned anywhere in the evidence pack.

   • [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
   • [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”

   proof ↗⚑ flag

   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

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 Browser Use
   Browser Use✓fullclaimed8/10

   Browser Use documents a clear captcha stance: automatic CAPTCHA solving is enabled by default for cloud Agent runs and standalone Cloud Browser sessions, with an explicit human-fallback path via the live preview if the challenge persists. This directly matches the story's requirement of a documented stance rather than silent failure. Missing for 10: independent/hands-on verification of captcha-solving success rates and explicit behavior/limits for the self-hosted open-source library (docs focus on Cloud).

   • [claimed-docs] “Every Browser Use Cloud browser enables automatic CAPTCHA solving.”
   • [claimed-docs] “If the challenge remains, open the [live preview](/cloud/browser/live-preview) for human control.”
   • [claimed-docs] “Automatic CAPTCHA solving is enabled by default for API V4 Agent runs and standalone Cloud Browser sessions.”

   proof ↗⚑ flag

   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

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
   Browser Use—none0/10

   The evidence pack documents stealth, proxy, and CAPTCHA-solving features in detail, but there is no published acceptable-use policy, terms of service, or anti-abuse statement governing what these stealth/automation features may or may not be used for; community discussion even raises security/abuse concerns without any vendor policy response cited.

   ⚑ flag

   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

Stealth

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

   weight 2 · round to Browser Use
   Browser Use✓fullclaimed7/10

   Docs explicitly state cloud browsers run in a hardened Chromium fork with stealth enabled by default and residential proxies across 195+ countries, directly matching the story's stealth+proxy ask, with automatic CAPTCHA solving as a complementary layer. Missing for 10: explicit control/documentation for selecting a specific geo-target rather than automatic 195+ country rotation, and independent/hands-on evidence confirming bot-detection evasion actually works in practice.

   • [claimed-docs] “Every cloud browser session runs in a hardened Chromium fork with stealth enabled by default — no configuration needed.”
   • [claimed-docs] “Residential proxies are enabled by default across 195+ countries.”
   • [claimed-docs] “Every Browser Use Cloud browser enables automatic CAPTCHA solving.”
   • [claimed-docs] “Automatic CAPTCHA solving is enabled by default for API V4 Agent runs and standalone Cloud Browser sessions.”

   proof ↗⚑ flag

   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

Extraction

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

   weight 3 · round to Stagehand
   Browser Use~partialclaimed4/10

   Docs mention structured output but V4 returns `run.result` as a plain string with a recommendation to 'ask for JSON only, then validate it client-side' — there's no native Zod/Pydantic schema binding or first-party typed-schema extraction feature shown. This is a workaround rather than a built-in schema-validated extraction pipeline. missing for 10: no evidence of a documented schema/type-binding API (e.g., passing a Pydantic/Zod schema directly to the agent), no SDK-level validation helpers, no independent/hands-on confirmation that structured JSON output reliably conforms to a given schema.

   • [claimed-docs] “V4 returns `run.result` as a string. Ask for JSON only, then validate it client-side”
   • [github] “Task: "Extract structured data about my followers and export it as a CSV."”

   proof ↗⚑ flag

   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

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
   Browser Use—none0/10

   The evidence pack has no documentation of file upload/download handling or of artifacts being stored and retrievable after a run — GH task examples merely reference a resume being filled in and CSV export, but no confirmation these are handled as retrievable files via any API or session mechanism. Missing for 10: explicit file upload API/tooling, download/save-to-cloud-storage feature, and an artifact retrieval endpoint or docs section.

   • [github] “Task: "Fill in this job application with my resume and information."”
   • [github] “Task: "Extract structured data about my followers and export it as a CSV."”

   proof ↗⚑ flag

   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