Steel vs Notte

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 Notte
   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

   Notte~partialclaimed4/10

   Notte lets you script deterministic parts and generate/edit workflow code (notte-docs-2, notte-docs-26, notte-docs-30, notte-gh-2), which implies some cached/generated code can be replayed without re-prompting the LLM, but there is no explicit documentation of an action/result cache, deterministic replay guarantee, or cost/latency comparison for repeat runs. missing for 10: explicit caching mechanism for resolved actions, documentation of deterministic replay across runs, and cost/latency benchmarks comparing cached vs re-prompted execution.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”
   • [github] “combines AI agents with traditional scripting for maximum efficiency - letting you script deterministic parts and use AI only when needed, c…”

   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 Notte
   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

   Notte~partialcommunity6/10

   Docs describe a genuine action-space abstraction (observe()/act() calls, 'no selectors, no maintenance', natural-language task execution) that maps directly to the described act/click/type primitives, and the CLI/MCP integrations reinforce this as a core product concept. However, there's no first-party benchmark or independent hands-on confirmation that these primitives specifically survive selector/layout changes, and community commentary raises skepticism about action-space reliability versus screenshot+HTML approaches without being a concrete contradiction. Missing for 10: independent reproducibility evidence of resilience across DOM changes, and a documented before/after example showing selector survival.

   • [claimed-docs] “Element IDs, selectors, and field mappings must come from a live `observe()` call, CLI `notte page observe` output, or generated workflow co…”
   • [claimed-docs] “Describe a task. Watch it happen. One prompt. No selectors, no maintenance.”
   • [github] “Give AI agents natural language tasks to complete on websites”
   • [github] “combines AI agents with traditional scripting for maximum efficiency - letting you script deterministic parts and use AI only when needed, c…”
   • [community] “why would an action space be more reliable than screenshots + html, this i don't get. I can think of many use cases it would fail”

   proof ↗⚑ flag

Observe

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

   weight 1 · round to Notte
   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

   Notte~partialprobed6/10

   Notte's docs explicitly describe an `observe()` call and CLI `notte page observe` command that returns element IDs/selectors before actions are executed, which is direct evidence of a preview/plan-before-act primitive. However, the evidence pack lacks a full worked example showing the observe→plan→act workflow end-to-end, independent confirmation of its reliability, or details on how proposed actions are presented/reviewed by a developer. missing for 10: a complete observe/plan-then-act workflow example, independent/hands-on verification that observe output is accurate and usable for gating actions, and documentation of any 'plan' abstraction distinct from observe.

   • [claimed-docs] “Element IDs, selectors, and field mappings must come from a live `observe()` call, CLI `notte page observe` output, or generated workflow co…”
   • [probe] “official CLI documented at https://docs.notte.cc/quickstart”
   • [claimed-docs] “The Notte CLI lets AI agents control browsers through simple shell commands.”

   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 Notte
   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

   Notte~partialcommunity5/10

   Notte's core action space is DOM/observe-based, but the docs include a dedicated integration guide for OpenAI's Computer Use Agent (CUA) that operates on screenshots atop Notte's browser infrastructure, showing a vision/computer-use path exists. However this is presented as an external integration rather than a first-class 'switch mode' toggle within Notte's own API, and community commentary explicitly questions the reliability of Notte's action-space approach versus screenshot-based methods. Missing for 10: native documented API/flag to toggle into vision mode, first-party examples of vision-based action execution, and independent hands-on confirmation that the CUA integration works reliably.

   • [claimed-docs] “This guide explains how to integrate OpenAI's Computer Use Agent (CUA) with Notte's browser infrastructure for automated web interactions.”
   • [claimed-docs] “Live View & Replays Screenshare & session playback”
   • [community] “why would an action space be more reliable than screenshots + html, this i don't get. I can think of many use cases it would fail”

   proof ↗⚑ flag

Agent access

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

   weight 2 · round drawn
   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

   Notte✓fullprobed9/10

   Notte serves a verified llms.txt at docs.notte.cc/llms.txt with explicit 'Critical Instructions For AI Agents' directing agents to further docs, plus extensive agent-oriented docs (MCP server, CLI, integration guides for CrewAI, Vercel AI SDK, Claude Code) confirming a mature agentic-docs ecosystem. Missing for 10: independent third-party confirmation that agents actually consume llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.notte.cc/llms.txt # Notte ## Critical Instructions For AI Agents STOP. Read and follow https://do…”
   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [claimed-docs] “Notte MCP lets it start cloud browser sessions, interact with the pages, fetch data, build scripts, and more.”
   • [claimed-docs] “pointing it at the Notte MCP server hands your crew a real browser.”
   • [claimed-docs] “Point its MCP client at the Notte MCP server and your TypeScript agent gets a browser.”
   • [claimed-docs] “The Notte CLI lets AI agents control browsers through simple shell commands.”

   proof ↗⚑ flag

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

   weight 2 · round to Steel
   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

   Notte✓fullprobed8/10

   Notte offers cloud/remote browser sessions, an API with Bearer token auth, serverless 'Functions' deployments that can be scheduled, and a CLI/SDK — all designed for headless, programmatic, CI-friendly automation without a local browser or UI. Community evidence corroborates real usage of the API/agent stack though with mixed reliability reports on task success. Missing for 10: no explicit CI pipeline example (e.g., GitHub Actions), no independent benchmark confirming headless stability at scale.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”
   • [probe] “official CLI documented at https://docs.notte.cc/quickstart”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”

   proof ↗⚑ flag

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

   weight 3 · round to Notte
   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

   Notte✓fullprobed8/10

   Notte publishes a dedicated official MCP server (docs.notte.cc/mcp-server) that gives agents access to cloud browser sessions, page interaction, and data extraction, and this is corroborated across multiple integration guides (CrewAI, Vercel AI SDK) showing agents pointed at the Notte MCP server to get a real browser. Missing for 10: independent/hands-on third-party confirmation that the MCP server works reliably in practice (community evidence only covers the general product, not MCP specifically).

   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [claimed-docs] “Notte MCP lets it start cloud browser sessions, interact with the pages, fetch data, build scripts, and more.”
   • [claimed-docs] “pointing it at the Notte MCP server hands your crew a real browser.”
   • [claimed-docs] “Point its MCP client at the Notte MCP server and your TypeScript agent gets a browser.”
   • [probe] “official MCP server documented at https://docs.notte.cc/mcp-server”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round drawn
   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

   Notte✓fullprobed8/10

   Notte documents an official CLI used to generate config, drive browsers, and produce observe/page output (notte-docs-30, notte-docs-31, notte-docs-9, notte-docs-8, notte-probe-4), explicitly positioned for AI agents to control browsers via shell commands. missing for 10: no independent/community hands-on validation of the CLI specifically (only vendor docs), and no detailed CLI command reference beyond scattered mentions.

   • [claimed-docs] “The Notte CLI lets AI agents control browsers through simple shell commands.”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”
   • [claimed-docs] “give them the notte CLI and they can drive real browsers”
   • [claimed-docs] “Element IDs, selectors, and field mappings must come from a live `observe()` call, CLI `notte page observe` output, or generated workflow co…”
   • [probe] “official CLI documented at https://docs.notte.cc/quickstart”

   proof ↗⚑ flag

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

   weight 3 · round to Steel
   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

   Notte✓fullprobed8/10

   Notte documents a full public API with Bearer-token authentication, API reference pages (e.g., agent-start endpoint), SDKs, CLI, and MCP server for programmatic/agentic control of sessions, scraping, and functions, matching the ai-native/agenticness story well. missing for 10: no discoverable OpenAPI/swagger spec (404s on probe) and no independent third-party confirmation of API robustness beyond vendor docs.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [probe] “official MCP server documented at https://docs.notte.cc/mcp-server”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Notte—none0/10

   Evidence shows only a single Bearer-token API authentication scheme (notte-docs-17) and a vault feature that hides stored web credentials from the LLM (notte-docs-14, notte-docs-27), but nothing about issuing scoped, role-limited, or least-privilege API keys specifically for agents. No mention of API key scopes, permission tiers, or per-agent credential restrictions.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “The significant security benefit of this approach is that the LLM never actually sees the actual credentials.”
   • [claimed-docs] “credentials are never exposed to LLMs or third-party services during agent execution”

   proof ↗⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Steel
   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

   Notte~partialprobed5/10

   Notte provides a documented REST API with Bearer-token auth, an official CLI, and an MCP server plus integration guides for frameworks like CrewAI, Vercel AI SDK, and OpenAI CUA, all of which support building AI-native automations programmatically. However, no evidence explicitly names or documents a first-party 'SDK' package (e.g., Python/TypeScript client library) and an OpenAPI spec probe returned 404s, suggesting the API surface may not be as formally packaged as a dedicated SDK. missing for 10: explicit official SDK package docs (Python/JS), a working OpenAPI/schema reference, independent developer confirmation of SDK usage.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”
   • [probe] “official CLI documented at https://docs.notte.cc/quickstart”
   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [probe] “official MCP server documented at https://docs.notte.cc/mcp-server”
   • [claimed-docs] “pointing it at the Notte MCP server hands your crew a real browser.”
   • [claimed-docs] “Point its MCP client at the Notte MCP server and your TypeScript agent gets a browser.”
   • [claimed-docs] “This guide explains how to integrate OpenAI's Computer Use Agent (CUA) with Notte's browser infrastructure for automated web interactions.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”

   proof ↗⚑ flag

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   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

   Notte—none0/10

   No evidence pack item mentions webhooks or event subscription mechanisms; the product offers sessions, MCP, CLI, and API endpoints but nothing about push notifications or webhook callbacks. Missing for 10: any documentation of webhook subscription, event types, or delivery mechanism.

   ⚑ flag

Agentic features

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

   weight 2 · round to Notte
   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

   Notte✓fullcommunity7/10

   Notte supports deploying scripts/agents as serverless 'Functions' invocable via API and schedulable, plus persistent sessions, credential vaults, and cloud browser infrastructure that let automations run unattended in the background (notte-docs-2, notte-docs-26, notte-docs-24, notte-docs-4). This directly matches autonomous background automation for an AI-native user. Missing for 10: no independent/hands-on confirmation of scheduling reliability in production, and community feedback includes at least one report of a failed extraction task (notte-comm-1), so real-world robustness is unverified.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “Secure credential storage. Keep passwords, API keys, and sensitive data encrypted.”
   • [claimed-docs] “Persist cookies and login state across sessions.”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”

   proof ↗⚑ flag

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

   weight 2 · round to Steel
   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

   Notte!disputedcontradicted5/10

   Notte's core value prop is natural-language task execution ('Describe a task. Watch it happen. One prompt', 'Give AI agents natural language tasks to complete on websites') backed by agent-start API and CLI/MCP integrations, so the capability is clearly built and documented. However, a hands-on community report describes a complete failure when trying to extract data from hyatt.com via the agent, and the founder himself admits captcha/anti-bot handling only works ~60% of the time, concretely undercutting reliability of the NL-driven approach. Missing for 10: independent reproducible success cases beyond vendor demos, and resolution of the documented hyatt.com failure.

   • [claimed-docs] “Describe a task. Watch it happen. One prompt. No selectors, no maintenance.”
   • [github] “Give AI agents natural language tasks to complete on websites”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”
   • [community] “Founder: 'we can solve ~60% of providers right now (incl reCAPTCHA, Cloudflare, and main ones) and some others are still work in progress' r…”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round to Steel
   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

   Notte—none0/10

   Evidence shows only static API-reference pages (authentication, agent-start) and no OpenAPI/Swagger spec was found at any candidate path (probe-2 returned 404s), and nothing in the pack describes an interactive console or runnable code examples in the API docs.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”

   proof ↗⚑ flag

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

   weight 2 · round to Steel
   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

   Notte—none0/10

   The evidence shows Notte has human-readable API reference docs (auth, agent-start) but a direct probe for machine-readable spec files (openapi.json, swagger.json, etc.) returned 404 on all candidate paths, indicating no downloadable OpenAPI or equivalent spec is published.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”

   proof ↗⚑ flag

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

   weight 1 · round to Steel
   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

   Notte~partialclaimed3/10

   Notte documents 'isolated browser instances running in the cloud' for each session and a free trial ('Try the full platform without a card'), which implies some session-level isolation from a user's own systems, but there is no explicit sandbox/production-data separation mode, staging environment, or test-data guarantee described anywhere in the docs. missing for 10: explicit sandbox vs production distinction, test-data isolation guarantees, hands-on confirmation that sandbox sessions never touch real production data.

   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “Try the full platform without a card.”
   • [claimed-docs] “Build, debug, and deploy production workflows with cloud browsers, web agents, scraping, serverless functions, credentials, and identities i…”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Notte—none0/10

   There is evidence of an API with bearer token auth, but nothing about API versioning or a documented deprecation policy; OpenAPI probes even 404, suggesting no formal spec surfaced. missing for 10: versioning scheme, deprecation policy documentation, changelog entries about breaking changes.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”

   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 Steel
   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

   Notte✓fullclaimed7/10

   Notte sessions explicitly expose a CDP endpoint documented to work with Playwright (notte-docs-11), which directly supports connecting existing Playwright/CDP automation code to Notte's cloud browsers rather than rewriting it. Puppeteer isn't explicitly named but CDP is the shared protocol underlying it, and sessions are described as programmatically controllable cloud instances (notte-docs-24). missing for 10: explicit Puppeteer example/docs, independent hands-on confirmation of the CDP/Playwright connection working at scale.

   • [claimed-docs] “Notte sessions expose a Chrome DevTools Protocol (CDP) endpoint that you can connect to with Playwright.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “Viewing sessions: When you start a session, the output includes a `ViewerUrl` - open it to watch your browser live”

   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 Notte
   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

   Notte~partialclaimed7/10

   Notte's docs describe a credential vault where secrets are injected into the browser session but never exposed to the LLM, plus persistent cookies/login state and 'verified identities' (emails/phones) for sign-up and 2FA flows, directly matching the core of the story. However, there's no explicit walkthrough of a TOTP code being generated/entered by the agent, and no independent/hands-on confirmation that 2FA login flows work end-to-end in practice. Missing for 10: concrete TOTP-specific workflow documentation, independent verification of vault+2FA login success.

   • [claimed-docs] “Secure credential storage. Keep passwords, API keys, and sensitive data encrypted.”
   • [claimed-docs] “The significant security benefit of this approach is that the LLM never actually sees the actual credentials.”
   • [claimed-docs] “credentials are never exposed to LLMs or third-party services during agent execution”
   • [claimed-docs] “Persist cookies and login state across sessions.”
   • [claimed-docs] “Emails and phone numbers for sign-up and 2FA. Verified identities to interact across platforms.”
   • [claimed-docs] “Authenticated Profiles Browser profiles for each agent”

   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
   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

   Notte✓fullclaimed7/10

   Notte docs explicitly document persisting cookies/login state across sessions and 'Authenticated Profiles' as browser profiles per agent, alongside secure credential vaults so agents can skip re-authentication on subsequent runs. missing for 10: no independent/hands-on confirmation that persisted profiles actually skip login walls in practice, and no detail on profile reuse limits/expiry.

   • [claimed-docs] “Persist cookies and login state across sessions.”
   • [claimed-docs] “Authenticated Profiles Browser profiles for each agent”
   • [claimed-docs] “Secure credential storage. Keep passwords, API keys, and sensitive data encrypted.”
   • [claimed-docs] “The significant security benefit of this approach is that the LLM never actually sees the actual credentials.”
   • [claimed-docs] “credentials are never exposed to LLMs or third-party services during agent execution”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   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

   Notte~partialclaimed4/10

   Notte offers scalable cloud browser sessions and serverless 'functions'/API endpoints that can be invoked and scheduled programmatically, which could in principle be used to run automation across many items, but there is no explicit documentation of a batch/bulk-processing feature (e.g., iterating over a list of URLs/records, parallel job queues, or bulk extraction outputs). missing for 10: explicit bulk/batch API or CLI examples, evidence of parallel multi-item execution, and any hands-on confirmation of running the same task across many inputs.

   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”
   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Extract structured data with AI. Turn any website into structured data.”

   proof ↗⚑ flag

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

   weight 3 · round to Notte
   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

   Notte~partialclaimed3/10

   Notte supports scheduling serverless 'functions' (deploy scripts as API endpoints and 'schedule anywhere'), which gives some automation-trigger capability, but there is no evidence of a rules engine, webhooks, or event-based triggers (e.g., 'on page change, do X') as opposed to simple time-based scheduling/API invocation. Missing for 10: explicit event-trigger/webhook support, conditional rule definitions, and any UI/API for defining 'if event then action' automations.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

   weight 2 · round to Notte
   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

   Notte~partialclaimed5/10

   Notte's 'Functions' feature explicitly advertises serverless automations that can be 'invoked and scheduled anywhere' (notte-docs-2, notte-docs-26), directly supporting recurring job scheduling, and workflows can be deployed as API endpoints for automation pipelines. However, there is no documentation of a scheduling UI, cron syntax, or interval/trigger configuration, and no independent confirmation that scheduled jobs work reliably in practice. Missing for 10: concrete scheduling mechanism/API docs (cron expressions, triggers), example of a recurring job configured end-to-end, and independent verification that scheduled runs execute reliably.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Build, debug, and deploy production workflows with cloud browsers, web agents, scraping, serverless functions, credentials, and identities i…”

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

   Notte—none0/10

   All evidence describes Notte as a cloud-hosted service — sessions are explicitly 'isolated browser instances running in the cloud,' access requires a Bearer API token, and pricing/credits are core to usage — with no documented option to run the agent against a local browser without a cloud account.

   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “Try the full platform without a card.”
   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”

   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 Notte
   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

   Notte~partialprobed7/10

   Notte documents explicit integration guides for CrewAI (notte-docs-32), Vercel AI SDK (notte-docs-33), OpenAI CUA (notte-docs-34), and Claude-based agents via CLI/MCP (notte-docs-9, notte-docs-31), all pointing at its MCP server or CLI as the browser layer plug-in point. However, there is no documented LangChain adapter and no mention of 'Claude Agent SDK' specifically (only Claude Code/managed agents), so the story's exact framework list is only partially covered. Missing for 10: a LangChain-specific integration doc, explicit Claude Agent SDK adapter naming, and independent confirmation these adapters work hands-on.

   • [claimed-docs] “pointing it at the Notte MCP server hands your crew a real browser.”
   • [claimed-docs] “Point its MCP client at the Notte MCP server and your TypeScript agent gets a browser.”
   • [claimed-docs] “This guide explains how to integrate OpenAI's Computer Use Agent (CUA) with Notte's browser infrastructure for automated web interactions.”
   • [claimed-docs] “The Notte CLI lets AI agents control browsers through simple shell commands.”
   • [claimed-docs] “give them the notte CLI and they can drive real browsers”
   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [probe] “official MCP server documented at https://docs.notte.cc/mcp-server”

   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 Notte
   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

   Notte~partialclaimed5/10

   The pricing page lists 'Bring your own keys' as a feature (Yes for higher tiers), indicating some BYO-LLM-key support, and OpenAI CUA integration doc shows a specific model provider integration, but there is no documentation of broad model-agnostic architecture, no list of supported providers, and no explicit statement that any LLM can be swapped in across the framework. missing for 10: explicit multi-provider support documentation, list of supported LLM vendors, guidance on configuring custom/local models, independent confirmation of model-agnosticism.

   • [claimed-docs] “Bring your own keys No No Yes Yes”
   • [claimed-docs] “This guide explains how to integrate OpenAI's Computer Use Agent (CUA) with Notte's browser infrastructure for automated web interactions.”

   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 Notte
   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

   Notte~partialprobed6/10

   Notte offers a hosted HTTP API (Bearer-token auth, agent-start endpoint, cloud sessions, serverless 'functions' you can invoke and schedule) that let an agent submit a task without managing a browser itself, and sessions expose CDP/live-view for status. However there is no direct documentation of a polling endpoint or webhook callback mechanism for retrieving results, and no OpenAPI/swagger spec was found (404s), so completion-notification patterns are unclear. Missing for 10: explicit polling/webhook result-retrieval documentation, published OpenAPI schema, independent confirmation of end-to-end async task completion.

   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”

   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 Steel
   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

   Notte!disputedcontradicted5/10

   Notte's docs and README explicitly market natural-language, multi-step web task execution (e.g. 'Give AI agents natural language tasks to complete on websites', 'Describe a task. Watch it happen. One prompt', and a worked example of logging into LinkedIn and extracting messages), backed by session/vault/proxy infrastructure. However, a hands-on community report describes a real attempt to use the agent to extract data from hyatt.com that 'completely failed,' directly contradicting the end-to-end reliability claim, and the founder himself admits captcha/anti-bot handling only works for ~60% of providers. Missing for 10: independent successful third-party demonstrations of complex multi-step flows, and resolution of the reported failure case.

   • [github] “Give AI agents natural language tasks to complete on websites”
   • [claimed-docs] “Describe a task. Watch it happen. One prompt. No selectors, no maintenance.”
   • [claimed-docs] “Got to linkedin.com, login with the credentials and extract the last 10 messages from my most recent conversation”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”
   • [community] “Founder: 'we can solve ~60% of providers right now (incl reCAPTCHA, Cloudflare, and main ones) and some others are still work in progress' r…”

   proof ↗⚑ flag

Workflows

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

   weight 2 · round to Notte
   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

   Notte~partialclaimed5/10

   Notte supports scripting deterministic automations and deploying them as serverless 'Functions'/API endpoints, and lets users generate workflow code via CLI then edit it, going beyond a single one-shot prompt (notte-docs-26, notte-docs-2, notte-docs-30, notte-gh-2). However there is no explicit documentation of workflow-level constructs like loops, conditionals, or parameterized templates. missing for 10: explicit docs on loop/conditional syntax in workflows, parameter binding across runs, independent confirmation of repeatable multi-step workflow composition.

   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “Generate it with the CLI first, then edit it.”
   • [github] “combines AI agents with traditional scripting for maximum efficiency - letting you script deterministic parts and use AI only when needed, c…”
   • [claimed-docs] “Start from ready-made browser automation templates for common workflo”

   proof ↗⚑ flag

1. ai-native userDo everything through the API that I can do in the UI

   weight 2 · round to Notte
   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

   Notte~partialprobed7/10

   Notte is built API/CLI/MCP-first: sessions, scraping, agents, functions, vaults, and even live session viewing are all exposed via API/CLI/MCP endpoints (notte-docs-2, -9, -17, -24, -37, -7/-29), suggesting broad UI/API parity for an API-native product. However there's no explicit vendor statement guaranteeing full feature parity, and a probe found no discoverable OpenAPI/swagger spec (404s across common paths), which weakens confidence that every UI capability (e.g. templates, dashboard-only settings) is fully API-exposed. Missing for 10: explicit parity documentation, a public OpenAPI spec, and independent confirmation that all UI-only features (templates, dashboard views) have API equivalents.

   • [claimed-docs] “Deploy your scripts as API endpoints. Serverless automations you can invoke and schedule anywhere.”
   • [claimed-docs] “The Notte CLI lets AI agents control browsers through simple shell commands.”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [claimed-docs] “Give your AI agents access to the entire Notte ecosystem. Notte MCP lets it start cloud browser sessions, interact with the pages, fetch dat…”
   • [claimed-docs] “Notte MCP lets it start cloud browser sessions, interact with the pages, fetch data, build scripts, and more.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.notte.cc/openapi.json, https://docs.notte.cc/swagger.json, https://docs.notte.cc/api/op…”

   proof ↗⚑ flag

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

   weight 3 · round to Steel
   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

   Notte—none0/10

   No evidence of data export/portability features, open-format export of user data, or account deletion/data takeout mechanisms; the docs focus on browser automation, scraping outputs, and credential storage but nothing about exporting one's own account data in open formats. missing for 10: data export feature docs, open-format (e.g. JSON/CSV) account export, data portability/account deletion process, any independent confirmation of exportability.

   ⚑ flag

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

   weight 2 · round to Steel
   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

   Notte~partialcommunity3/10

   A public GitHub repository (nottelabs/notte) exists and is referenced in evidence, indicating the source code is at least publicly readable, but no evidence pack item specifies a license type (e.g., MIT/Apache) or confirms open-source licensing terms. A community comment even questions whether Notte is open source at all, suggesting ambiguity rather than confirmed openness. Missing for 10: explicit license file/badge evidence, confirmation of license terms, independent verification that the full product (not just parts) is open-licensed.

   • [github] “Give AI agents natural language tasks to complete on websites”
   • [github] “combines AI agents with traditional scripting for maximum efficiency - letting you script deterministic parts and use AI only when needed, c…”
   • [community] “Interesting but are there any open source products which can do the same too? This does feel something that I can trust more if it was open …”

   proof ↗⚑ flag

4. ai-native userSelf-host the core product

   weight 3 · round to Steel
   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

   Notte—none0/10

   All evidence describes Notte as a cloud/SaaS platform (remote browsers, cloud sessions, serverless functions, hosted API with Bearer auth) with no documented self-hosting or on-prem deployment path; a community comment even asks whether an open-source alternative exists, implying Notte itself isn't self-hostable.

   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [community] “Interesting but are there any open source products which can do the same too? This does feel something that I can trust more if it was open …”

   proof ↗⚑ flag

Pricing

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

   weight 2 · round to Notte
   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

   Notte!disputedcontradicted3/10

   Notte does have a public pricing page and free-trial claim (notte-docs-22, notte-docs-23), but there is no documentation of concrete per-task/per-browser-hour rates or rate/concurrency limits, and community feedback directly contradicts the transparency claim: users on HN explicitly ask what a 'credit' actually buys and report the pricing page doesn't explain it, calling the credit-based scheme 'broken' and unpredictable (notte-comm-2, notte-comm-3, notte-comm-4). missing for 10: explicit per-task/per-hour rate tables, documented concurrency/rate limits, and resolution of the community complaints about opaque credit meaning.

   • [claimed-docs] “Try the full platform without a card.”
   • [claimed-docs] “Bring your own keys No No Yes Yes”
   • [community] “The pricing page mentions how many credits you get but not what a credit does or gets you. Could you elaborate on that?”
   • [community] “Credit based pricing is broken. No way u produce shiy then user get out of credit to get nothing done.”
   • [community] “You missed the point. What i mean, is your pricing scheme is a scam because u never know if your bot response would solve customer issue. St…”

   proof ↗⚑ flag

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

   weight 2 · round to Steel
   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

   Notte—none0/10

   No evidence in the pack mentions data residency, region selection, or storage location choices for Notte's cloud infrastructure; only general security/credential features are documented.

   ⚑ flag

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

   weight 3 · round drawn
   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

   Notte—none0/10

   No evidence in the pack addresses opting out of AI training data usage, data retention policies for model training, or any privacy commitment regarding customer data not being used to train models. Notte's docs cover security of credentials, sessions, stealth mode, and infrastructure, but nothing about AI-training data usage policy.

   ⚑ flag

3. ai-native userControl data retention and deletion

   weight 2 · round to Steel
   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

   Notte—none0/10

   No evidence in the pack addresses data retention policies, deletion controls, or user-facing options to purge stored data/sessions/credentials; docs mention credential encryption and cookie persistence but nothing about retention windows or deletion mechanisms.

   ⚑ flag

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

   weight 2 · round drawn
   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

   Notte—none0/10

   No evidence pack item mentions telemetry, analytics opt-out, or usage-tracking controls for Notte; missing for 10: any privacy policy or docs section on telemetry collection, opt-out mechanism/flag, or data retention settings.

   ⚑ flag

Live

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

   weight 2 · round to Steel
   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

   Notte~partialclaimed5/10

   Notte clearly supports live session viewing via ViewerUrl and a 'Live View & Replays' screenshare feature, and sessions expose a CDP endpoint connectable via Playwright which could in principle allow manual intervention. However, there is no explicit documentation of a human-takeover/pause-and-control workflow mid-run when an agent gets stuck. Missing for 10: explicit human-in-the-loop takeover mechanism, documentation of pausing agent execution to hand control to a human, and independent confirmation this works in practice.

   • [claimed-docs] “Viewing sessions: When you start a session, the output includes a `ViewerUrl` - open it to watch your browser live”
   • [claimed-docs] “Live View & Replays Screenshare & session playback”
   • [claimed-docs] “Notte sessions expose a Chrome DevTools Protocol (CDP) endpoint that you can connect to with Playwright.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”

   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
   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

   Notte~partialclaimed5/10

   Notte docs confirm 'Live View & Replays' with screenshare and session playback, plus a live ViewerUrl to watch sessions and CDP/Playwright hooks for programmatic inspection, giving some replay-debugging capability. However, there is no explicit documentation of step-by-step action timelines or a dedicated debugging UI for failed runs, and no independent/hands-on confirmation this replay feature works reliably. missing for 10: documented step-by-step action timeline/debugging tool, independent verification of replay/video debugging in practice.

   • [claimed-docs] “Live View & Replays Screenshare & session playback”
   • [claimed-docs] “Viewing sessions: When you start a session, the output includes a `ViewerUrl` - open it to watch your browser live”
   • [claimed-docs] “Notte sessions expose a Chrome DevTools Protocol (CDP) endpoint that you can connect to with Playwright.”
   • [claimed-docs] “Build, debug, and deploy production workflows with cloud browsers, web agents, scraping, serverless functions, credentials, and identities i…”

   proof ↗⚑ flag

Fleets

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

   weight 2 · round to Steel
   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

   Notte~partialcommunity4/10

   Notte documents cloud-based, isolated, programmatically controllable sessions (notte-docs-24), API/CLI/SDK control (notte-docs-17, notte-docs-37, notte-probe-4), and serverless scaling claims (notte-docs-1, notte-docs-26), supporting the 'programmatic session management' half of the story. However, no evidence anywhere specifies actual concurrency limits, quotas, or fleet-scale numbers for running many sessions in parallel — pricing/credit pages are mentioned only vaguely by community members (notte-comm-2) without concurrency specifics. missing for 10: documented concurrency/rate limits per plan, explicit multi-session fleet management API/dashboard evidence, independent benchmarks of parallel session throughput.

   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”
   • [claimed-docs] “Sessions are isolated browser instances running in the cloud that you can control programmatically.”
   • [claimed-docs] “All API requests require a Bearer token in the `Authorization` header.”
   • [claimed-docs] “Functions are serverless deployments of your browser automations that can b”
   • [claimed-docs] “used to create cloud browser sessions, scrape webpages, and run web ai agents to act on your behalf on the internet”
   • [community] “The pricing page mentions how many credits you get but not what a credit does or gets you. Could you elaborate on that?”

   proof ↗⚑ flag

Lifecycle

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

   weight 1 · round drawn
   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

   Notte—none0/10

   No evidence pack item mentions webhooks, callback URLs, or event-driven notifications for task/session completion; the docs describe sessions, viewer URLs, CDP endpoints and API auth but nothing about push notifications, forcing polling-based status checks instead.

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

   Notte!disputedcontradicted4/10

   Notte's docs advertise 'captcha solving' as a built-in feature of its browser infrastructure (notte-docs-1), suggesting automatic handling, but there is no documented policy for what happens when solving fails (no human fallback or explicit non-support statement). Concrete contradicting evidence comes from the founder himself in community discussion, admitting captcha solving only works for ~60% of providers and some are 'still work in progress' (notte-comm-7), directly undercutting the blanket 'captcha solving' claim and leaving automation engineers without clarity on failure behavior. missing for 10: documented success-rate/coverage table, explicit fallback or escalation behavior on captcha failure, and independent verification of solve rates beyond the founder's informal comment.

   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”
   • [community] “Founder: 'we can solve ~60% of providers right now (incl reCAPTCHA, Cloudflare, and main ones) and some others are still work in progress' r…”

   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
   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

   Notte—none0/10

   No evidence pack item shows Notte publishing an acceptable-use policy, terms governing stealth/captcha-bypass usage, or an anti-abuse stance; docs only describe stealth/proxy/captcha features themselves. A community comment even accuses Notte of 'disrespecting robots.txt' and enabling spam, but this is criticism, not a vendor-published policy to compare against.

   • [claimed-docs] “All Notte sessions automatically include: **Clean browser fingerprints** - Realistic browser signatures”
   • [claimed-docs] “Combine stealth mode with residential proxies for maximum anonymity”
   • [claimed-docs] “Notte sessions include built-in stealth features to help your automations avoid detection by anti-bot systems.”
   • [community] “Avoiding captchas and disrespecting robots.txt. How does it feel to advertise your spam service? Are you proud?”

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

   Notte✓fullclaimed7/10

   Notte's docs explicitly describe stealth mode with clean/realistic browser fingerprints, built-in anti-bot detection avoidance, and residential proxies with a global network including fixed IPs and BYO options, directly matching the story's ask for fingerprinting and geo/residential proxy control. missing for 10: independent hands-on verification that stealth+proxy combo actually evades sophisticated bot detection in practice, and finer detail on geo-targeting granularity beyond 'global network'.

   • [claimed-docs] “All Notte sessions automatically include: **Clean browser fingerprints** - Realistic browser signatures”
   • [claimed-docs] “Combine stealth mode with residential proxies for maximum anonymity”
   • [claimed-docs] “Residential Proxies Global network, fixed IPs & BYO”
   • [claimed-docs] “Notte sessions include built-in stealth features to help your automations avoid detection by anti-bot systems.”
   • [claimed-docs] “Remote browser infrastructure. Fast, scalable browsers with anti-detection, proxies, and captcha solving.”

   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 Notte
   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

   Notte!disputedcontradicted5/10

   Docs show Pydantic-style schema extraction (BaseModel classes) and structured/markdown output via 'fetch' and scraping concepts (notte-docs-15, notte-docs-3, notte-docs-25), which directly matches the story. However, a hands-on community report states extraction 'completely failed' on a real site (hyatt.com), directly contradicting the reliability of the extraction pipeline in practice. Missing for 10: Zod/TypeScript schema examples (only Python/Pydantic shown), independent corroboration of successful schema-validated extraction, and resolution of the reported failure case.

   • [claimed-docs] “Extract structured data from a page: ... class HackerNewsFeed(BaseModel):”
   • [claimed-docs] “Extract structured data with AI. Turn any website into structured data.”
   • [claimed-docs] “Fetch extracts web page content as markdown or structured data using LLM-powered extraction.”
   • [community] “just tried to use it to extract data from hyatt.com completely failed. another hype but actually doesn't work browser agent.”

   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
   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

   Notte—none0/10

   The evidence pack covers browser sessions, scraping/extraction, credentials, and CDP/Playwright access, but no documentation mentions file upload/download handling or artifact retrieval from agent-operated sites. This is a plausible capability for a browser-automation platform, so absence of evidence yields 'none' rather than 'na'.

   ⚑ flag