Hyperbrowser 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 drawn
   Hyperbrowser—none0/10

   No evidence of any caching mechanism for resolved actions or generated code; Hyperbrowser's docs cover agents, extraction, sessions, stealth, proxies, and sandboxes but nothing about replaying deterministic cached actions to avoid re-prompting the LLM.

   ⚑ 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 Hyperbrowser
   Hyperbrowser~partialclaimed6/10

   HyperAgent's page.ai() lets developers issue natural-language commands (e.g., 'search for flights... select the cheapest option') instead of writing selectors, and docs explicitly say it lets you 'write natural language commands instead of complex selectors,' matching the DOM-understanding action-primitive story. However, evidence shows a single high-level task-execution call rather than discrete act/click/type primitives, and there's no independent/hands-on evidence confirming resilience to selector or layout changes. Missing for 10: granular primitive-level API docs (separate click/type/act calls), independent verification of survival across DOM/layout changes, and community confirmation of reliability.

   • [claimed-docs] “await page.ai("search for flights from Miami to LAX, select the cheapest option");”
   • [claimed-docs] “HyperAgent is our open-source tool that supercharges Playwright with AI.”
   • [claimed-docs] “HyperAgent is an open-source browser automation framework that extends Playwright with AI capabilities. Write natural language commands inst…”

   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 Steel
   Hyperbrowser—none0/10

   Hyperbrowser's agent APIs (page.ai(), HyperAgent, MCP tools) execute actions directly via natural-language commands, and extract()/scrape() only pull data — there is no documented observe/plan primitive that lets a developer preview candidate actions before the agent commits to acting. missing for 10: an explicit plan/observe API or dry-run mode, evidence of returning candidate actions for approval, any UI or SDK method to inspect proposed steps prior to execution.

   • [claimed-docs] “await page.ai("search for flights from Miami to LAX, select the cheapest option");”
   • [claimed-docs] “HyperAgent is our open-source tool that supercharges Playwright with AI.”
   • [claimed-docs] “HyperAgent is an open-source browser automation framework that extends Playwright with AI capabilities. Write natural language commands inst…”
   • [claimed-docs] “The `page.extract()` method pulls structured data from web pages. Define what you want using natural language and optionally enforce a schem…”

   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 to Hyperbrowser
   Hyperbrowser~partialclaimed3/10

   Hyperbrowser documents 'built-in support for Claude, OpenAI, Gemini, Grok, and BrowserUse agents' (model-native agents) and can return screenshots via fetch/scrape APIs, hinting at vision-capable agent modes, but there is no explicit documentation of a dedicated 'vision' or 'computer-use' action mode that operates purely on screenshots for canvases/UIs the DOM can't reach. Missing for 10: explicit computer-use/vision mode docs, screenshot-based click/type action primitives, and any example of handling canvas/non-DOM UI elements.

   • [claimed-docs] “Built in support for Claude, OpenAI, Gemini, Grok, and BrowserUse agents.”
   • [claimed-docs] “Fetches a web page and returns the content in various formats (HTML, Markdown, JSON, screenshot, etc.)”
   • [github] “`scrape_webpage` - Extract formatted (markdown, screenshot etc) content from any webpage”

   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
   Hyperbrowser✓fullprobed8/10

   Probe confirms a live, well-formed llms.txt at hyperbrowser.ai/llms.txt (HTTP 200) describing the product for agent consumption, and docs additionally expose an official MCP server that agents can connect to for structured access. missing for 10: no docs.md/full agent-oriented docs mirror (docs.md 404) and no OpenAPI spec discoverable, so agent-friendly docs coverage beyond llms.txt is incomplete.

   • [probe] “PROBE llms.txt: HTTP 200 at https://hyperbrowser.ai/llms.txt # Hyperbrowser > Hyperbrowser provides fast cloud browsers for AI agents and a…”
   • [probe] “PROBE docs-md: HTTP 404 at https://hyperbrowser.ai/docs.md”
   • [probe] “PROBE openapi: all candidate paths 404 (https://hyperbrowser.ai/openapi.json, https://hyperbrowser.ai/swagger.json, https://hyperbrowser.ai/…”
   • [claimed-docs] “The Hyperbrowser MCP server provides a standardized interface for AI models to access powerful web automation capabilities like scraping, st…”
   • [probe] “official MCP server documented at https://hyperbrowser.ai/docs/integrations/model-context-protocol”

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

   Hyperbrowser is fundamentally a headless, API/SDK/CLI-driven cloud browser service — sessions run in the cloud with no local browser needed, exposing WebSocket/CDP endpoints for Playwright/Puppeteer plus official SDKs and a CLI (`hx`), which is exactly the shape needed for CI/automation pipelines. Missing for 10: explicit CI pipeline examples (e.g., GitHub Actions docs) and independent hands-on confirmation of CI usage.

   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically. Each session gives you a WebSocket endpo…”
   • [claimed-docs] “Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs—no infrastructure management required.”
   • [claimed-docs] “Official SDKs for integrating Hyperbrowser into your applications”
   • [claimed-docs] “Set up the Hyperbrowser CLI (`hx`) and/or the SDKs to start working with sandboxes.”
   • [claimed-docs] “Connect your existing automation scripts to cloud browsers”
   • [claimed-docs] “The Scrape API allows you to get the data you want from web pages with a single call. You can scrape page content and capture its data in va…”
   • [claimed-docs] “The Crawl API allows you to crawl websites and get data from multiple pages in a single request. Starting from a URL, it can navigate throug…”

   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 Hyperbrowser
   Hyperbrowser✓fullprobed8/10

   Hyperbrowser ships an official MCP server (hyperbrowser.ai/docs/integrations/model-context-protocol) exposing tools like scrape_webpage, extraction, and crawling for AI agents to connect to, backed by a public GitHub repo listing the tool set. Missing for 10: independent/hands-on confirmation of the MCP server working with a real agent client and more detail on the full tool list/setup.

   • [claimed-docs] “The Hyperbrowser MCP server provides a standardized interface for AI models to access powerful web automation capabilities like scraping, st…”
   • [github] “`scrape_webpage` - Extract formatted (markdown, screenshot etc) content from any webpage”
   • [probe] “official MCP server documented at https://hyperbrowser.ai/docs/integrations/model-context-protocol”

   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
   Hyperbrowser~partialclaimed5/10

   Docs mention an official CLI called `hx` for setting up and working with sandboxes, confirming a first-party CLI exists, but the evidence pack gives no further detail on its command set, installation, or broader agentic workflow support beyond sandboxes. missing for 10: fuller CLI documentation (commands, usage examples), independent/hands-on confirmation, and evidence it covers more than just sandbox setup.

   • [claimed-docs] “Set up the Hyperbrowser CLI (`hx`) and/or the SDKs to start working with sandboxes.”

   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
   Hyperbrowser✓fullprobed8/10

   Hyperbrowser exposes a fully documented REST API (Scrape, Crawl, Extract, Sessions, Agents) plus official SDKs and a CLI, all covered in detailed first-party docs, and community comments confirm real developers have used the API/docs (even correcting a code sample). Missing for 10: a discoverable OpenAPI/swagger spec (probe found only 404s) and independent third-party validation of full API completeness.

   • [claimed-docs] “The Scrape API allows you to get the data you want from web pages with a single call. You can scrape page content and capture its data in va…”
   • [claimed-docs] “The Crawl API allows you to crawl websites and get data from multiple pages in a single request. Starting from a URL, it can navigate throug…”
   • [claimed-docs] “The Extract API allows you to extract structured data from web pages using AI. You can define a schema and prompt, and Hyperbrowser will ext…”
   • [claimed-docs] “Official SDKs for integrating Hyperbrowser into your applications”
   • [claimed-docs] “Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs—no infrastructure management required.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically. Each session gives you a WebSocket endpo…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://hyperbrowser.ai/llms.txt # Hyperbrowser > Hyperbrowser provides fast cloud browsers for AI agents and a…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://hyperbrowser.ai/openapi.json, https://hyperbrowser.ai/swagger.json, https://hyperbrowser.ai/…”
   • [community] “one quick nit on your docs: https://docs.hyperbrowser.ai/guides/scrape-site ... should be [corrected code with 'let' instead of 'const']”

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

   No evidence of scoped or least-privilege API key/credential management for agents — only mentions of a generic 'credits' usage-tracking system, not permission-scoped API keys or role-based access controls. missing for 10: any API key scoping/permission model, docs on creating restricted-scope credentials, or agent-specific credential issuance.

   • [claimed-docs] “Hyperbrowser tracks your usage via `credits` which can be acquired through a subscription or through a direct purchase.”

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

   Hyperbrowser documents official SDKs (hyperbrowser-docs-18) alongside a dedicated SDK introduction page, plus consistent references throughout docs to using SDKs (or Puppeteer/Playwright) to integrate programmatically (hyperbrowser-docs-19, hyperbrowser-docs-9, hyperbrowser-docs-29). Missing for 10: independent/hands-on developer confirmation of SDK quality or completeness across languages, and no direct OpenAPI spec found (probe-3) which would reinforce SDK-generation credibility.

   • [claimed-docs] “Official SDKs for integrating Hyperbrowser into your applications”
   • [claimed-docs] “Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs—no infrastructure management required.”
   • [claimed-docs] “Connect your existing automation scripts to cloud browsers”
   • [claimed-docs] “Set up the Hyperbrowser CLI (`hx`) and/or the SDKs to start working with sandboxes.”

   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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Hyperbrowser—none0/10

   No evidence pack item mentions webhooks or event subscription mechanisms; the product docs cover sessions, agents, scraping, extraction, MCP, and sandboxes but nothing about webhook notifications for events like task completion or crawl status. missing for 10: any documentation of webhook subscription/callback endpoints, event types, or webhook configuration.

   ⚑ flag

   Steel—none0/10

   No evidence anywhere in the pack mentions webhooks or event subscriptions; Steel's documented surfaces are Sessions API, CLI, MCP tools, and agent traces, none of which describe a webhook/event notification mechanism.

   ⚑ flag

Agentic features

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

   weight 2 · round to Hyperbrowser
   Hyperbrowser~partialclaimed4/10

   Hyperbrowser supports triggering agent tasks via API and cloud sessions, which could underlie automations, but there is no evidence of scheduling, triggers, or persistent background jobs that run autonomously without a caller invoking them each time. missing for 10: scheduled/triggered automation, background job orchestration, evidence of persistent autonomous runs, independent confirmation of unattended operation.

   • [claimed-docs] “Hyperbrowser lets you run powerful, AI-driven browser agents in managed cloud sessions... you can start tasks with a single API call and wat…”
   • [claimed-docs] “Hyperbrowser lets you run powerful, AI-driven browser agents in managed cloud sessions. Whether you prefer open-source frameworks or cutting…”
   • [claimed-docs] “Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs—no infrastructure management required.”
   • [claimed-docs] “Connect your existing automation scripts to cloud browsers”

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

   Hyperbrowser explicitly supports natural-language commands via page.ai() and HyperAgent ('Write natural language commands instead of complex selectors'), plus natural-language driven extraction (page.extract()/Extract API) and an MCP server exposing these to AI models. missing for 10: independent hands-on verification that NL commands reliably succeed across varied tasks, and broader third-party corroboration beyond vendor docs.

   • [claimed-docs] “await page.ai("search for flights from Miami to LAX, select the cheapest option");”
   • [claimed-docs] “HyperAgent is an open-source browser automation framework that extends Playwright with AI capabilities. Write natural language commands inst…”
   • [claimed-docs] “The `page.extract()` method pulls structured data from web pages. Define what you want using natural language and optionally enforce a schem…”
   • [claimed-docs] “The Hyperbrowser MCP server provides a standardized interface for AI models to access powerful web automation capabilities like scraping, st…”

   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
   Hyperbrowser~partialprobed3/10

   Hyperbrowser's docs include an api-reference section with code snippets (e.g., fetch-a-web-page.md) and quickstart examples like page.ai()/page.extract(), showing static example code, but there's no evidence of an interactive, runnable API console — probes for openapi/swagger specs all returned 404s, indicating no auto-generated interactive reference. missing for 10: evidence of an actual interactive/try-it API explorer, runnable code sandboxes, or OpenAPI-based interactive docs.

   • [claimed-docs] “Fetches a web page and returns the content in various formats (HTML, Markdown, JSON, screenshot, etc.)”
   • [claimed-docs] “await page.ai("search for flights from Miami to LAX, select the cheapest option");”
   • [claimed-docs] “The `page.extract()` method pulls structured data from web pages. Define what you want using natural language and optionally enforce a schem…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://hyperbrowser.ai/openapi.json, https://hyperbrowser.ai/swagger.json, https://hyperbrowser.ai/…”

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

   A direct probe for an OpenAPI/Swagger spec at all standard locations (openapi.json, swagger.json, etc.) returned 404s, and no docs page claims a downloadable machine-readable API spec exists — only human-readable API reference pages are present.

   • [probe] “PROBE openapi: all candidate paths 404 (https://hyperbrowser.ai/openapi.json, https://hyperbrowser.ai/swagger.json, https://hyperbrowser.ai/…”
   • [probe] “PROBE docs-md: HTTP 404 at https://hyperbrowser.ai/docs.md”
   • [claimed-docs] “Fetches a web page and returns the content in various formats (HTML, Markdown, JSON, screenshot, etc.)”

   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
   Hyperbrowser~partialclaimed6/10

   Hyperbrowser ships dedicated 'Sandboxes' (isolated exec environments with sub-50ms startup) and isolated cloud browser 'Sessions' that are separate from any user production environment, which aligns with testing in isolation. However, the docs never explicitly frame this as protecting 'production data' or describe production/staging separation guarantees, and there is no independent/hands-on confirmation of isolation guarantees. Missing for 10: explicit production-vs-sandbox data isolation claims, independent verification of sandbox isolation, and security/compliance detail on data leakage prevention.

   • [claimed-docs] “Hyperbrowser Sandboxes are the fastest sandboxes with less than 50ms startup time.”
   • [claimed-docs] “const result = await sandbox.exec("node -e 'console.log(\"hello world\")'");”
   • [claimed-docs] “Set up the Hyperbrowser CLI (`hx`) and/or the SDKs to start working with sandboxes.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically. Each session gives you a WebSocket endpo…”

   proof ↗⚑ 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
   Hyperbrowser—none0/10

   No evidence of API versioning scheme or documented deprecation policy; OpenAPI/spec probes returned 404 and no changelog or versioning docs appear in the pack. missing for 10: versioned API endpoints/headers, changelog, explicit deprecation policy documentation.

   • [probe] “PROBE openapi: all candidate paths 404 (https://hyperbrowser.ai/openapi.json, https://hyperbrowser.ai/swagger.json, https://hyperbrowser.ai/…”
   • [probe] “PROBE docs-md: HTTP 404 at https://hyperbrowser.ai/docs.md”

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

   Docs explicitly state sessions expose a WebSocket endpoint compatible with Playwright, Puppeteer, or any CDP-compatible tool, and the intro reiterates 'Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs.' This directly supports connecting existing automation code without rewriting it, plus profiles for persisting cookies/session state across sessions. Missing for 10: independent/hands-on developer confirmation of drop-in compatibility with existing large codebases and any noted friction points.

   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically. Each session gives you a WebSocket endpo…”
   • [claimed-docs] “Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs—no infrastructure management required.”
   • [claimed-docs] “Connect your existing automation scripts to cloud browsers”
   • [claimed-docs] “Profiles let you save and reuse browser state, which includes cookies, local storage, session storage, and cache, across multiple sessions.”

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

   Evidence shows session/profile persistence (cookies, storage) and stealth/captcha features, but nothing about a credentials vault, secret injection into login forms, or TOTP/2FA handling without exposing secrets to the model.

   • [claimed-docs] “Profiles let you save and reuse browser state, which includes cookies, local storage, session storage, and cache, across multiple sessions.”

   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 to Steel
   Hyperbrowser✓fullclaimed7/10

   Docs explicitly describe Profiles that persist cookies, local storage, session storage, and cache across multiple sessions, directly enabling agents to skip login walls on repeat runs. Missing for 10: no independent/hands-on confirmation that profile reuse actually bypasses login in practice, and no detail on profile lifecycle/management limits.

   • [claimed-docs] “Profiles let you save and reuse browser state, which includes cookies, local storage, session storage, and cache, across multiple sessions.”

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

   Hyperbrowser's Crawl API can traverse and extract from many pages in one request, and the Extract/Scrape APIs support structured data pulls, with community evidence of higher concurrency limits enabling parallel bulk sessions. However there's no explicit documented 'batch job over an arbitrary list of items/URLs' endpoint, and no first-party proof of large-scale bulk-run examples or rate/queue management for bulk workloads. missing for 10: explicit bulk/batch API for arbitrary item lists, documented large-scale throughput examples, independent benchmarks of bulk operation reliability.

   • [claimed-docs] “The Crawl API allows you to crawl websites and get data from multiple pages in a single request. Starting from a URL, it can navigate throug…”
   • [claimed-docs] “The Scrape API allows you to get the data you want from web pages with a single call. You can scrape page content and capture its data in va…”
   • [claimed-docs] “The Extract API allows you to extract structured data from web pages using AI. You can define a schema and prompt, and Hyperbrowser will ext…”
   • [community] “Just did a pricing check, and you give twice as much concurrency/browsing/data-transfer as Browserbase. Nice!”

   proof ↗⚑ 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
   Hyperbrowser—none0/10

   Hyperbrowser provides on-demand browser automation, scraping, extraction, and agent APIs, but there is no evidence of an event-driven rules/trigger engine (e.g., webhooks on page changes, scheduled triggers, condition-based automation) that would let a user define 'if X happens, do Y' automation. All capabilities described are invoked synchronously via API calls, not autonomously triggered by events. Missing for 10: rule/trigger definition mechanism, event listeners or webhooks, scheduling/condition-based automation execution.

   ⚑ 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

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Hyperbrowser—none0/10

   No evidence anywhere in the pack of scheduling, cron-like recurring jobs, or persistent workflow automation triggers; Hyperbrowser's docs cover on-demand sessions, agents, scraping, extraction, sandboxes and MCP integration but nothing about recurring/scheduled execution. Missing for 10: any scheduler/cron feature, recurring job API, or workflow trigger documentation.

   ⚑ flag

   Steel—none0/10

   Steel is a browser automation/session API for AI agents (sessions, stealth, proxies, CLI, MCP tools), but nothing in the evidence describes a scheduler, cron-like trigger, or recurring job/workflow orchestration feature; usage is invoked on-demand per session, not on a schedule.

   ⚑ 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
   Hyperbrowser—none0/10

   All evidence describes Hyperbrowser as a managed cloud-browser service — sessions are explicitly cloud-hosted with WebSocket/CDP endpoints, and control is via cloud sessions requiring credits/subscription, not local execution without a cloud account. No evidence of a local-browser dev mode or offline/no-account option exists.

   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically. Each session gives you a WebSocket endpo…”
   • [claimed-docs] “Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs—no infrastructure management required.”
   • [claimed-docs] “Hyperbrowser tracks your usage via `credits` which can be acquired through a subscription or through a direct purchase.”

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

   Evidence shows generic SDKs, an MCP server, and built-in support for AI models (Claude, OpenAI, Gemini, Grok, BrowserUse) plus Playwright/Puppeteer/CDP session control, but there is no documentation of adapters specifically for Claude Agent SDK, Vercel AI SDK, LangChain, or CrewAI framework integration as the story requires.

   • [claimed-docs] “Official SDKs for integrating Hyperbrowser into your applications”
   • [claimed-docs] “Built in support for Claude, OpenAI, Gemini, Grok, and BrowserUse agents.”
   • [claimed-docs] “The Hyperbrowser MCP server provides a standardized interface for AI models to access powerful web automation capabilities like scraping, st…”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically. Each session gives you a WebSocket endpo…”

   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 to Hyperbrowser
   Hyperbrowser✓fullclaimed7/10

   Hyperbrowser's docs explicitly state 'Built in support for Claude, OpenAI, Gemini, Grok, and BrowserUse agents,' indicating the agent framework is not locked to a single LLM vendor and can work with multiple providers. Missing for 10: independent/community confirmation of multi-provider use, and detailed docs on how to configure/swap providers or bring custom API keys.

   • [claimed-docs] “Built in support for Claude, OpenAI, Gemini, Grok, and BrowserUse agents.”
   • [claimed-docs] “HyperAgent is our open-source tool that supercharges Playwright with AI.”
   • [claimed-docs] “HyperAgent is an open-source browser automation framework that extends Playwright with AI capabilities. Write natural language commands inst…”

   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 to Hyperbrowser
   Hyperbrowser~partialprobed6/10

   Hyperbrowser's docs confirm a hosted HTTP API where AI agents can start browser tasks with a single API call and run them in managed cloud sessions (agents, scrape, crawl, extract), removing the need to manage a browser directly. However, the evidence pack never explicitly documents a polling endpoint or webhook callback mechanism for retrieving task results—only 'watch them execute live' and SDK/CDP connection details are mentioned. Missing for 10: explicit API documentation of a status/poll endpoint, explicit webhook/callback support, and independent confirmation of async result retrieval flow.

   • [claimed-docs] “Hyperbrowser lets you run powerful, AI-driven browser agents in managed cloud sessions... you can start tasks with a single API call and wat…”
   • [claimed-docs] “Hyperbrowser lets you run powerful, AI-driven browser agents in managed cloud sessions. Whether you prefer open-source frameworks or cutting…”
   • [claimed-docs] “Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs—no infrastructure management required.”
   • [claimed-docs] “Connect your existing automation scripts to cloud browsers”
   • [probe] “PROBE llms.txt: HTTP 200 at https://hyperbrowser.ai/llms.txt # Hyperbrowser > Hyperbrowser provides fast cloud browsers for AI agents and a…”

   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 to Hyperbrowser
   Hyperbrowser✓fullclaimed7/10

   Docs show HyperAgent's page.ai() executing natural-language multi-step goals (e.g., searching flights and selecting cheapest option) and a separate managed Agents API that starts autonomous browser-agent tasks with a single call, supporting navigation, clicking, and form interactions end-to-end. Missing for 10: independent/hands-on verification of complex multi-step task completion and success-rate data beyond first-party docs.

   • [claimed-docs] “await page.ai("search for flights from Miami to LAX, select the cheapest option");”
   • [claimed-docs] “Hyperbrowser lets you run powerful, AI-driven browser agents in managed cloud sessions... you can start tasks with a single API call and wat…”
   • [claimed-docs] “Hyperbrowser lets you run powerful, AI-driven browser agents in managed cloud sessions. Whether you prefer open-source frameworks or cutting…”
   • [claimed-docs] “HyperAgent is our open-source tool that supercharges Playwright with AI.”
   • [claimed-docs] “HyperAgent is an open-source browser automation framework that extends Playwright with AI capabilities. Write natural language commands inst…”
   • [claimed-docs] “Built in support for Claude, OpenAI, Gemini, Grok, and BrowserUse agents.”

   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 drawn
   Hyperbrowser—none0/10

   Hyperbrowser's docs describe single-call agent tasks, scraping/extraction, and Playwright/Puppeteer session control, but nothing describes a workflow builder or orchestration layer with loops, conditionals, or parameterized multi-step flows—automation is either one-shot AI prompts (page.ai, Extract API) or raw code you write yourself against Playwright, not a documented workflow composition feature.

   • [claimed-docs] “await page.ai("search for flights from Miami to LAX, select the cheapest option");”
   • [claimed-docs] “HyperAgent is our open-source tool that supercharges Playwright with AI.”
   • [claimed-docs] “HyperAgent is an open-source browser automation framework that extends Playwright with AI capabilities. Write natural language commands inst…”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically. Each session gives you a WebSocket endpo…”

   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 userDo everything through the API that I can do in the UI

   weight 2 · round to Hyperbrowser
   Hyperbrowser✓fullprobed7/10

   Hyperbrowser is API-first: sessions, scraping, crawling, extraction, agents, sandboxes, profiles, recordings, stealth/CAPTCHA solving are all exposed via API/SDK/CLI, and the dashboard is largely a viewer over the same session/agent primitives rather than a separate feature surface. missing for 10: no public OpenAPI spec was found (404s on probes), and no explicit statement confirming every dashboard-only setting (e.g., billing/team management) is API-controllable.

   • [claimed-docs] “Hyperbrowser lets you run powerful, AI-driven browser agents in managed cloud sessions... you can start tasks with a single API call and wat…”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically. Each session gives you a WebSocket endpo…”
   • [claimed-docs] “The Scrape API allows you to get the data you want from web pages with a single call. You can scrape page content and capture its data in va…”
   • [claimed-docs] “The Crawl API allows you to crawl websites and get data from multiple pages in a single request. Starting from a URL, it can navigate throug…”
   • [claimed-docs] “The Extract API allows you to extract structured data from web pages using AI. You can define a schema and prompt, and Hyperbrowser will ext…”
   • [claimed-docs] “Hyperbrowser Sandboxes are the fastest sandboxes with less than 50ms startup time.”
   • [claimed-docs] “Set up the Hyperbrowser CLI (`hx`) and/or the SDKs to start working with sandboxes.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://hyperbrowser.ai/openapi.json, https://hyperbrowser.ai/swagger.json, https://hyperbrowser.ai/…”

   proof ↗⚑ flag

   Steel~partialprobed6/10

   Steel is fundamentally API-first: the Sessions API, CAPTCHA/proxy/auth-reuse, human-in-the-loop debug URLs, agent traces, and even the CLI are all documented as thin wrappers over the same REST/OpenAPI surface (steel-docs-1..10, steel-probe-2, steel-probe-3), and the runtime probe confirms the API alone (no UI) can create/list live sessions end-to-end. However, there's no explicit evidence enumerating the dashboard/UI feature set and confirming 1:1 parity with the API — it's inferred rather than directly stated. Missing for 10: an explicit doc/comparison confirming every UI-only feature (e.g. dashboard analytics, trace viewer) is also exposed via API, and independent confirmation of full parity.

   • [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] “One flag covers detection, solving, and verification for the whole session”
   • [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”
   • [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.”
   • [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 openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
   • [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 userExport all of my data in open formats and leave

   weight 3 · round to Steel
   Hyperbrowser—none0/10

   No evidence of a data export/portability feature for user data (sessions, profiles, recordings, extracted data) in open formats, nor any account-deletion/data-takeout mechanism; profiles and recordings are stored server-side with no documented export path.

   ⚑ 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

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

   weight 2 · round to Steel
   Hyperbrowser—none0/10

   Hyperbrowser's core cloud service (sessions, scraping, sandboxes, MCP server) is presented purely as a closed commercial SaaS API/product with no license or public repo for the platform itself. The only open-source item mentioned, HyperAgent, is a separate client-side automation framework, not the Hyperbrowser product's own source code, so it doesn't satisfy this story.

   • [claimed-docs] “HyperAgent is our open-source tool that supercharges Playwright with AI.”
   • [claimed-docs] “HyperAgent is an open-source browser automation framework that extends Playwright with AI capabilities. Write natural language commands inst…”
   • [claimed-docs] “Hyperbrowser tracks your usage via `credits` which can be acquired through a subscription or through a direct purchase.”

   proof ↗⚑ 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

4. ai-native userSelf-host the core product

   weight 3 · round to Steel
   Hyperbrowser—none0/10

   Hyperbrowser is presented entirely as a managed cloud service (cloud browser sessions, sandboxes, MCP server) with no evidence of a self-hostable core product, open-source repo of the main platform, or on-prem deployment option; only HyperAgent (a client-side automation library) is open source, not the underlying cloud infrastructure. missing for 10: any docs or repo for self-hosting the core browser/session infrastructure, deployment/Docker instructions, or license terms permitting self-hosting.

   • [claimed-docs] “Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs—no infrastructure management required.”
   • [claimed-docs] “Hyperbrowser Sandboxes are the fastest sandboxes with less than 50ms startup time.”
   • [claimed-docs] “HyperAgent is our open-source tool that supercharges Playwright with AI.”

   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 to Hyperbrowser
   Hyperbrowser!disputedcontradicted4/10

   Hyperbrowser docs mention a credit-based pricing model (hyperbrowser-docs-27) but provide no explicit per-task/per-browser-hour cost table or concurrency/rate-limit documentation in the evidence pack. Community feedback directly contradicts the transparency claim: users report confusion over credit costs versus competitors (hyperbrowser-comm-2) and one user states it appears 'not possible to follow robots.txt or limit RPS as a user of this service' (hyperbrowser-comm-9), indicating undocumented or absent rate-limiting behavior. missing for 10: a concrete pricing/rate-limit page with per-hour or per-task cost breakdown, explicit concurrency caps, and independent confirmation that documented limits match real usage.

   • [claimed-docs] “Hyperbrowser tracks your usage via `credits` which can be acquired through a subscription or through a direct purchase.”
   • [community] “Your pricing is too confusing... You charge $100 for 60K credits... In comparison it costs $249 for 3 million credits in ScrapingBee which e…”
   • [community] “So, amusingly, they seem to have added an 'ethical scraping' page to their docs in between me looking at this a few hours ago and now... as …”
   • [community] “This looks cool. I looked at the pricing. Is search included in the price - (you just pay credits/browser time?)”

   proof ↗⚑ 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 Steel
   Hyperbrowser—none0/10

   No evidence in the pack mentions data residency, region selection, or geographic storage location for Hyperbrowser sessions/data; proxy/geo-routing docs relate to traffic egress, not data storage location. Missing for 10: any mention of data residency options, region selection controls, or storage location guarantees.

   ⚑ 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
   Hyperbrowser—none0/10

   Hyperbrowser is a browser automation/scraping infrastructure product; no evidence anywhere in the pack addresses a data-training opt-out or any AI-model training data policy. Even the community threads about ethical scraping/robots.txt concern outbound scraping behavior, not whether Hyperbrowser uses customer data to train models. Absence of evidence for this applicable privacy-posture axis means none.

   ⚑ 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
   Hyperbrowser—none0/10

   No evidence pack content addresses data retention policies, deletion controls, or privacy settings for stored session data, recordings, or profiles; community evidence even suggests scraping is done without regard to opt-out mechanisms like robots.txt, but this doesn't speak to retention/deletion controls directly. This is a fair axis for a cloud browser automation service handling user data (recordings, profiles, scraped data), so absence of evidence yields 'none' rather than 'na'.

   • [claimed-docs] “Profiles let you save and reuse browser state, which includes cookies, local storage, session storage, and cache, across multiple sessions.”
   • [claimed-docs] “Hyperbrowser supports both web recordings (using rrweb) that capture DOM changes and interactions in a lightweight format, and traditional M…”
   • [community] “They do not respect robots.txt, and publish a doc page dedicated to circumventing scraping countermeasures. I pointed their scraper at a url…”
   • [community] “So, amusingly, they seem to have added an 'ethical scraping' page to their docs in between me looking at this a few hours ago and now... as …”

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

   No evidence of any telemetry opt-out setting or privacy control; the only related mention is credit-based usage tracking for billing, which is a business metric, not telemetry, and no docs describe disabling analytics/tracking.

   • [claimed-docs] “Hyperbrowser tracks your usage via `credits` which can be acquired through a subscription or through a direct purchase.”

   proof ↗⚑ 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
   Hyperbrowser~partialclaimed4/10

   Hyperbrowser docs confirm you can 'watch tasks execute live' and supports session recordings (rrweb/video) for later replay/debugging, but there is no evidence of a mechanism for a human to take control mid-run and intervene when the agent gets stuck — no live handoff, pause/resume, or manual takeover feature is documented. Missing for 10: documented live human takeover/intervention controls during an active agent run, and independent confirmation this works in practice.

   • [claimed-docs] “Hyperbrowser lets you run powerful, AI-driven browser agents in managed cloud sessions... you can start tasks with a single API call and wat…”
   • [claimed-docs] “Hyperbrowser lets you run powerful, AI-driven browser agents in managed cloud sessions. Whether you prefer open-source frameworks or cutting…”
   • [claimed-docs] “Hyperbrowser supports both web recordings (using rrweb) that capture DOM changes and interactions in a lightweight format, and traditional M…”
   • [claimed-docs] “Record and replay your browser sessions to debug failures, analyze behavior, and share reproducible bug reports.”

   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
   Hyperbrowser~partialclaimed5/10

   Hyperbrowser documents session recordings (rrweb DOM-level recordings and MP4 video) which support visual replay of a browser session, and MCP/scrape tools mention screenshot capture, but there is no evidence of a dedicated step-by-step action/timeline log for agent runs or a debugging UI tied to failed runs specifically. missing for 10: explicit step-by-step action timeline artifact, agent-run failure/debug UI, independent hands-on confirmation of replay-based debugging workflow.

   • [claimed-docs] “Hyperbrowser supports both web recordings (using rrweb) that capture DOM changes and interactions in a lightweight format, and traditional M…”
   • [claimed-docs] “Hyperbrowser lets you run powerful, AI-driven browser agents in managed cloud sessions... you can start tasks with a single API call and wat…”
   • [github] “`scrape_webpage` - Extract formatted (markdown, screenshot etc) content from any webpage”

   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 drawn
   Hyperbrowser~partialcommunity6/10

   Hyperbrowser clearly supports programmatic, isolated cloud browser sessions controllable via Playwright/Puppeteer/SDKs (hyperbrowser-docs-10, hyperbrowser-docs-19), and community feedback indicates it offers more concurrency than competitors like Browserbase (hyperbrowser-comm-1), implying tiered concurrency limits exist. However, the evidence pack contains no first-party documentation page explicitly listing numeric concurrency limits per plan or fleet-scale orchestration guidance. Missing for 10: explicit documented concurrency-limit numbers/tiers, guidance on running many sessions in parallel, and independent verification of limits in practice.

   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically. Each session gives you a WebSocket endpo…”
   • [claimed-docs] “Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs—no infrastructure management required.”
   • [community] “Just did a pricing check, and you give twice as much concurrency/browsing/data-transfer as Browserbase. Nice!”
   • [claimed-docs] “Hyperbrowser tracks your usage via `credits` which can be acquired through a subscription or through a direct purchase.”

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

   No evidence anywhere in the pack mentions webhooks, callbacks, or push notifications for task/session completion; all documented status mechanisms appear to be live/polling-based (watch execution live, sessions, recordings). Absence of evidence for this applicable capability yields none.

   ⚑ 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
   Hyperbrowser!disputedcontradicted5/10

   Hyperbrowser explicitly documents an automatic CAPTCHA-solving stance (enabled at session creation) alongside stealth mode for anti-bot detection, giving automation engineers a documented policy rather than silent failures. However, a hands-on community report describes being 'instantly blocked by cloudflare' in a real automation use case, contradicting the claimed automatic bypass/solving reliability in practice. missing for 10: independent verification that CAPTCHA solving works reliably across real sites, clarification of behavior when solving fails (human fallback vs silent failure), and resolution of the Cloudflare-blocking report.

   • [claimed-docs] “Hyperbrowser can automatically detect and solve CAPTCHAs when you enable it during session creation.”
   • [claimed-docs] “Stealth mode applies anti-detection techniques to help your automated browser sessions bypass bot detection.”
   • [community] “had usecase of keeping visa appointments slots and instantly blocked by cloudflare :sad:”

   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 to Hyperbrowser
   Hyperbrowser!disputedcontradicted4/10

   Hyperbrowser doesn't publish a clear acceptable-use/anti-abuse policy in its docs, and when community members pressed on robots.txt/rate-limit compliance, the company added an 'ethical scraping' page reactively — but a hands-on tester found it still doesn't actually support respecting robots.txt or limiting request rate, and Hyperbrowser's own docs promote circumventing bot-detection countermeasures (stealth/CAPTCHA-solving) rather than governing their limits. Missing for 10: an actual published acceptable-use policy document, terms defining permitted use of stealth/CAPTCHA features, and evidence of enforcement matching any stated ethical posture.

   • [community] “Is there support for robots.txt so service operators can opt out of your mass scraping?”
   • [community] “They do not respect robots.txt, and publish a doc page dedicated to circumventing scraping countermeasures. I pointed their scraper at a url…”
   • [community] “So, amusingly, they seem to have added an 'ethical scraping' page to their docs in between me looking at this a few hours ago and now... as …”
   • [claimed-docs] “Stealth mode applies anti-detection techniques to help your automated browser sessions bypass bot detection.”
   • [claimed-docs] “Hyperbrowser can automatically detect and solve CAPTCHAs when you enable it during session creation.”
   • [claimed-docs] “Ultra Stealth Mode - The most advanced stealth mode for extra evasion from bot detection.”

   proof ↗⚑ 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
   Hyperbrowser!disputedcontradicted5/10

   Hyperbrowser explicitly documents Stealth Mode, an 'Ultra Stealth Mode', CAPTCHA solving, and proxy routing for geo-targeting/IP rotation, directly matching the story's anti-bot and geo-targeted proxy needs (hyperbrowser-docs-4, -12, -20, -5, -13). However, a first-hand community report describes being 'instantly blocked by cloudflare' despite using the service for an automation use case, and another user documents the scraper still exposing bot-like UA/IP patterns detectable by target sites, concretely contradicting the anti-detection claims in practice (hyperbrowser-comm-3, hyperbrowser-comm-8). missing for 10: independent benchmark showing stealth/proxy reliably evades modern bot defenses, explicit confirmation of 'residential' proxy type versus generic rotating proxies, and resolution of the Cloudflare-block report.

   • [claimed-docs] “Stealth mode applies anti-detection techniques to help your automated browser sessions bypass bot detection.”
   • [claimed-docs] “Stealth mode applies anti-detection techniques to help your automated browser sessions bypass bot detection. Use it when interacting with si…”
   • [claimed-docs] “Ultra Stealth Mode - The most advanced stealth mode for extra evasion from bot detection.”
   • [claimed-docs] “Hyperbrowser can automatically detect and solve CAPTCHAs when you enable it during session creation.”
   • [claimed-docs] “Route browser sessions through proxy servers to access geo-restricted content, rotate IPs, and distribute requests across different location…”
   • [community] “had usecase of keeping visa appointments slots and instantly blocked by cloudflare :sad:”
   • [community] “They do not respect robots.txt, and publish a doc page dedicated to circumventing scraping countermeasures. I pointed their scraper at a url…”

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

   Hyperbrowser documents both an Extract API and page.extract() method that support schema-based extraction with Zod, explicitly for type-safe structured results from visited pages, and this is available both in standalone scrape/crawl calls and agent workflows (HyperAgent). Missing for 10: no independent/hands-on verification of schema-validation correctness or Pydantic-specific support (docs only mention Zod), and no example showing enforcement failure/error handling.

   • [claimed-docs] “The `page.extract()` method pulls structured data from web pages. Define what you want using natural language and optionally enforce a schem…”
   • [claimed-docs] “The Extract API allows you to extract structured data from web pages using AI. You can define a schema and prompt, and Hyperbrowser will ext…”
   • [claimed-docs] “The `page.extract()` method pulls structured data from web pages. Define what you want using natural language and optionally”
   • [claimed-docs] “HyperAgent is our open-source tool that supercharges Playwright with AI.”

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

   The evidence pack details scraping, extraction, session recording, and sandbox exec, but nowhere mentions file download/upload handling on target sites or artifact retrieval mechanisms for such files. Since Hyperbrowser exposes raw Playwright/Puppeteer CDP endpoints, this axis is plausible for the product category, but no documentation or community evidence confirms the capability.

   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically. Each session gives you a WebSocket endpo…”
   • [claimed-docs] “Control Chrome browsers in the cloud using Puppeteer, Playwright, or our SDKs—no infrastructure management required.”
   • [claimed-docs] “Hyperbrowser supports both web recordings (using rrweb) that capture DOM changes and interactions in a lightweight format, and traditional M…”

   proof ↗⚑ 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