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 own docs describe CLI-level click/fill/type and CDP/Puppeteer control (steel-gh-1, steel-docs-8), which is standard selector-based automation, not a DOM-understanding 'act on described element' primitive that survives layout/selector changes. Semantic action-taking is delegated to third-party integrations (Claude/OpenAI/Gemini Computer Use, Browser-Use) rather than being a native Steel capability.

   • [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.”
   • [claimed-docs] “Use Gemini Computer Use with Steel Browser.”
   • [claimed-docs] “Use Claude Computer Use with Steel Browser.”
   • [claimed-docs] “The OpenAI Computer Use integration runs OpenAI's vision-based agent loop on a Steel browser session.”
   • [claimed-docs] “Use Browser-Use to interact with a Steel browser.”

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

   Steel exposes session snapshot/extract/screenshot tools and a human-in-the-loop debug URL (steel-docs-5, steel-docs-39), but there is no evidence of an explicit preview/plan primitive that lets a developer see candidate actions on a page before committing the agent to execute them — it's an observability/handoff feature, not an action-preview mechanism.

   • [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] “The Steel integration runs each tool against a Steel cloud session (open, navigate, snapshot, extract, return typed results)”
   • [github] “Browser Tools: Exposes APIs to quick convert pages to markdown, readability, screenshots, or PDFs.”

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

   Steel documents dedicated integrations for OpenAI, Claude, and Gemini Computer Use that run vision-based agent loops (operating on screenshots) atop a Steel browser session, directly enabling a vision/computer-use mode alongside its DOM-based Sessions API and CLI actions. missing for 10: independent/hands-on corroboration of vision mode working on canvas-heavy UIs, and detail on switching seamlessly between DOM and vision modes within one session.

   • [claimed-docs] “Use Gemini Computer Use with Steel Browser.”
   • [claimed-docs] “Use Claude Computer Use with Steel Browser.”
   • [claimed-docs] “The OpenAI Computer Use integration runs OpenAI's vision-based agent loop on a Steel browser session.”
   • [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~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

   Steel serves a live llms.txt file at docs.steel.dev/llms.txt (HTTP 200, confirmed via probe) summarizing its docs, which an agent can be pointed at directly, plus a full agent-oriented docs site with skills, MCP, and SDK integration guides. Missing for 10: no independent/community 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…”
   • [claimed-docs] “Steel is the open-source browser API for AI agents — managed cloud browsers with stealth, residential proxies, CAPTCHA solving, persistent p…”
   • [claimed-docs] “Expose a Steel browser to any MCP client”

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

   Steel is API-first and ships a CLI, Docker image (API+UI), and Sessions API that spins up isolated cloud browsers on demand, all designed to be driven programmatically with no GUI required — exactly the shape needed for CI/headless automation. It also supports standard automation clients (Puppeteer/Playwright/Selenium via CDP) which are routinely run headlessly in CI pipelines. Missing for 10: an explicit CI/CD example (e.g., GitHub Actions workflow) or independent report confirming real-world headless CI usage.

   • [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 Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
   • [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✓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✓fullclaimed6/10

   Steel is a browser-API platform (not itself an agent), so the axis applies, and its docs explicitly describe exposing a Steel browser as an MCP server/tool set ('Expose a Steel browser to any MCP client' and 'exposes a cloud browser as in-process MCP tools' for the Claude Agent SDK integration), letting external agents connect via MCP. Missing for 10: deeper standalone MCP-server setup docs/config reference, and independent/hands-on confirmation beyond a single cookbook and integration mention.

   • [claimed-docs] “Expose a Steel browser to any MCP client”
   • [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 integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the brow”

   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 to Notte
   Steel✓fullprobed7/10

   Steel ships an official CLI (documented at docs.steel.dev/overview/steel-cli) that lets users run full browser workflows from the terminal—start sessions, navigate, click/fill/type, extract content, and stop sessions—directly serving agentic/AI-native use cases. missing for 10: independent/hands-on community corroboration of the CLI itself, and detail on CLI scripting/composability beyond the basic workflow description.

   • [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”
   • [claimed-docs] “Install Steel CLI and the steel-browser skill so your agent can control a browser.”

   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 exposes a fully documented public REST API (Sessions, CAPTCHA, Credentials, Files, Agent Traces) confirmed by a live openapi.json spec, plus an official CLI and SDK/agent-framework integrations (CrewAI, OpenAI Agents SDK, AI SDK, Claude Agent SDK, AgentKit, Pydantic AI) that let AI-native users drive it programmatically. Community comments corroborate the API/docs quality and usability. Missing for 10: independent hands-on benchmarking of the API's reliability/limits beyond docs and one HN thread.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
   • [claimed-docs] “Explore API endpoints for building on Steel.”
   • [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 runs each agent's browser actions on a Steel cloud session, so AgentKit handles the orchestration and Steel handles th…”
   • [claimed-docs] “The Steel integration exposes a Steel browser as a CrewAI tool, so your crew can search, navigate, fill forms, extract data, and validate re…”
   • [claimed-docs] “The Steel integration runs each tool against a Steel cloud session, so you can stand up a typed browser agent that opens a session, navigate…”
   • [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✓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

   The evidence pack shows a general API key/auth model (referenced implicitly by API usage) and a 'Credentials' endpoint, but that endpoint is for storing website login credentials for browser sessions (steel-docs-15, steel-docs-24), not for issuing scoped/least-privilege API keys to control agent access to Steel's own platform. No docs mention role-based access control, permission scopes, or restricted API key issuance for the Steel API itself.

   • [claimed-docs] “Explore API endpoints for managing Steel Credentials.”
   • [claimed-docs] “Reusing Context & Auth | Steel Docs”

   proof ↗⚑ 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✓fullprobed7/10

   Steel exposes a documented REST API (OpenAPI spec, steel-probe-2), an official CLI (steel-docs-8, steel-probe-3), and native connectivity via Puppeteer/Playwright/Selenium (steel-gh-1), plus first-party integrations with major agent frameworks (AI SDK, CrewAI, OpenAI Agents SDK, Claude Agent SDK, Pydantic AI, AgentKit) that act as official SDK-level bindings for AI-native development. Missing for 10: explicit named client-library SDKs (e.g., dedicated Python/Node package docs) and independent/hands-on developer confirmation of SDK ergonomics beyond vendor docs.

   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
   • [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] “official CLI documented at https://docs.steel.dev/overview/steel-cli”
   • [claimed-docs] “The Steel integration runs each tool against a Steel cloud session (open, navigate, snapshot, extract, return typed results)”
   • [claimed-docs] “The Steel integration exposes a Steel browser as a CrewAI tool, so your crew can search, navigate, fill forms, extract data, and validate re…”
   • [claimed-docs] “Build a Pydantic AI browser agent on Steel cloud browsers: provider-agnostic, typed Python agents with dependency injection and real web acc…”
   • [claimed-docs] “The Steel integration runs each tool against a Steel cloud session, so you can stand up a typed browser agent that opens a session, navigate…”
   • [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 brow”
   • [claimed-docs] “The Steel integration runs each agent's browser actions on a Steel cloud session, so AgentKit handles the orchestration and Steel handles th…”

   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 pack mentions webhooks or event subscriptions anywhere in Steel's docs, CLI, API, or integrations; Steel's observability is presented via agent traces/session replays rather than push-based webhook events.

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

   Steel provides infrastructure that agents can call programmatically (Sessions API, CLI, and integrations with agent frameworks like CrewAI, OpenAI Agents SDK, Claude Agent SDK) to run browser automations without human intervention, and sessions can be created on-demand for autonomous agent workflows. However, there is no evidence of a native scheduler, cron/trigger mechanism, or persistent background job runner within Steel itself — autonomy and 'background' execution depend entirely on the calling agent/framework, not a Steel-native automation scheduler. Missing for 10: native scheduling/triggers, evidence of long-running/persistent background jobs managed by Steel, and independent confirmation of autonomous unattended runs.

   • [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] “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 integration runs each agent's browser actions on a Steel cloud session, so AgentKit handles the orchestration and Steel handles th…”
   • [claimed-docs] “The Steel integration exposes a Steel browser as a CrewAI tool, so your crew can search, navigate, fill forms, extract data, and validate re…”
   • [claimed-docs] “The Steel integration runs each tool against a Steel cloud session, so you can stand up a typed browser agent that opens a session, navigate…”

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

   Steel is a browser-automation infrastructure API for agents/developers, not itself an interface that accepts natural-language commands from a user; the CLI (steel-docs-8) is a scriptable command-line tool with structured commands, not NL input, and no evidence shows a chat/NL interface for operating Steel directly. missing for 10: any documented NL command interface, chatbot/assistant front-end, or evidence that end users type plain-English instructions to control Steel.

   • [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] “Install Steel CLI and the steel-browser skill so your agent can control a browser.”

   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~partialprobed5/10

   Steel documents dedicated API-reference pages ('Explore API endpoints for...') and exposes a live OpenAPI spec (openapi.json), and a community commenter independently praised the 'beautiful docs + api ref', suggesting a solid reference exists. However, there's no explicit evidence of interactive 'try it now' / runnable-example functionality within that reference (e.g., embedded request builders or live code execution) — missing for 10: confirmation of in-browser runnable/try-it examples, independent hands-on demonstration of executing calls directly from the docs.

   • [claimed-docs] “Explore API endpoints for managing Steel Captchas.”
   • [claimed-docs] “Explore API endpoints for building on Steel.”
   • [claimed-docs] “Explore API endpoints for managing Steel Credentials.”
   • [claimed-docs] “Explore API Endpoints for managing Files on Steel.”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
   • [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

   Steel exposes a live, machine-readable OpenAPI spec confirmed via probe (HTTP 200 with valid 'openapi' key), and docs reference extensive API endpoint documentation (steel-docs-13 through steel-docs-16) built on this spec. Missing for 10: no independent/community confirmation of the OpenAPI spec's completeness or third-party tooling built against it.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
   • [claimed-docs] “Explore API endpoints for building on Steel.”
   • [claimed-docs] “Explore API endpoints for managing Steel Captchas.”
   • [claimed-docs] “Explore API endpoints for managing Steel Credentials.”
   • [claimed-docs] “Explore API Endpoints for managing Files on Steel.”

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

   Steel's Sessions API explicitly provisions isolated browser instances, each with its own state, cookies, and storage, letting an agent test without affecting other sessions or shared/production data, and session lifecycle docs show sessions can be created/torn down independently (steel-docs-1, steel-docs-10, steel-docs-33). Self-hosted Docker image and CLI further support standing up isolated test environments (steel-gh-4, steel-docs-8). Missing for 10: independent/hands-on verification that isolation holds in practice, and no explicit framing of 'sandbox vs production' terminology in the docs.

   • [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] “Session Lifecycle | Steel Docs”
   • [github] “Pre-built Docker Image (combined API + UI)”
   • [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~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

   Evidence shows an OpenAPI spec and extensive API documentation, but nothing addresses API versioning scheme or a documented deprecation policy. missing for 10: versioning scheme documentation, deprecation policy, changelog/migration guides for breaking changes.

   • [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
   • [claimed-docs] “Explore API endpoints for building on Steel.”

   proof ↗⚑ 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✓fullclaimed8/10

   GitHub docs explicitly state Steel exposes CDP endpoints that let developers connect using Puppeteer, Playwright, or Selenium, meaning existing automation code can target Steel's browsers with minimal rewrite, and the Sessions API/session lifecycle docs support this connection model. Missing for 10: independent hands-on developer reports confirming drop-in compatibility and more detail on any required code changes beyond endpoint swapping.

   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
   • [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] “Session Lifecycle | Steel Docs”

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

   Steel documents a 'Credentials' API endpoint and separate 'Reusing Auth Context' feature for persisting authenticated sessions/cookies across runs, which addresses avoiding repeated logins, but there is no evidence describing a credential vault workflow, TOTP/2FA handling, or explicit guarantees that secrets are withheld from the model during login. missing for 10: dedicated vault/secrets-manager docs, TOTP/2FA challenge handling, explicit model-isolation guarantee for credentials, independent corroboration.

   • [claimed-docs] “Explore API endpoints for managing Steel Credentials.”
   • [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”
   • [claimed-docs] “Reusing Context & Auth | Steel Docs”

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

   Steel's docs explicitly describe reusing auth context/persistent profiles across sessions so agents can access protected resources without repeating login flows, backed by a dedicated docs page and general session state/cookie persistence via the Sessions API. Missing for 10: independent/hands-on developer confirmation that reused profiles reliably skip login walls in practice, and more detail on profile creation/management UX.

   • [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”
   • [claimed-docs] “Reusing Context & Auth | Steel Docs”
   • [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 is the open-source browser API for AI agents — managed cloud browsers with stealth, residential proxies, CAPTCHA solving, persistent p…”

   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 supports spinning up many isolated browser sessions concurrently (Sessions API, CLI, SDK integrations) which enables running many browser tasks in parallel, but there is no explicit documentation of a bulk/batch operations API (e.g., batch session creation, bulk item processing, or queue-based multi-item automation) — the evidence only shows single-session workflows orchestrated one at a time via various agent frameworks. missing for 10: explicit bulk/batch API or documented pattern for orchestrating many items at once, concurrency limits/guidance, and any hands-on 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] “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…”
   • [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”

   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 infrastructure product (sessions, proxies, CAPTCHA solving, agent traces, integrations) with no evidence of any scheduling, cron, or recurring-workflow trigger mechanism; jobs must be invoked externally rather than scheduled by Steel itself.

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

   Steel is explicitly open-source with a pre-built Docker image combining the API and UI, letting a developer self-host the browser locally, and it exposes CDP so Puppeteer/Playwright/Selenium can connect directly to a local instance without any cloud account (steel-gh-4, steel-gh-1, steel-gh-5). This directly satisfies running an agent against a local browser for development. Missing for 10: a dedicated 'local dev quickstart' doc walking through docker-compose setup and confirmation that no cloud sign-in/telemetry is required, plus independent hands-on confirmation of local-only usage.

   • [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.”
   • [github] “Steel.dev is an open-source browser API that makes it easy to build AI apps and agents that interact with the web. Instead of building autom…”

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

   Steel documents dedicated integration guides for Claude Agent SDK, Vercel AI SDK, LangChain-adjacent (CrewAI), and other frameworks, each describing how Steel's cloud browser plugs in as a tool/MCP server for the agent loop (steel-docs-9/43, steel-docs-39, steel-docs-40, plus AgentKit, OpenAI Agents SDK, Pydantic AI). Missing for 10: explicit LangChain-named adapter page (only CrewAI/AgentKit/AI SDK/Claude named) and independent/hands-on confirmation beyond vendor docs.

   • [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 integration runs each tool against a Steel cloud session (open, navigate, snapshot, extract, return typed results)”
   • [claimed-docs] “The Steel integration exposes a Steel browser as a CrewAI tool, so your crew can search, navigate, fill forms, extract data, and validate re…”
   • [claimed-docs] “The Steel integration runs each agent's browser actions on a Steel cloud session, so AgentKit handles the orchestration and Steel handles th…”
   • [claimed-docs] “The Steel integration runs each tool against a Steel cloud session, so you can stand up a typed browser agent that opens a session, navigate…”
   • [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 brow”
   • [claimed-docs] “Expose a Steel browser to any MCP client”

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

   Steel documents integrations across many LLM/agent ecosystems — OpenAI Computer Use, Claude Computer Use, Gemini Computer Use, Browser-Use, CrewAI, Pydantic AI (explicitly 'provider-agnostic'), OpenAI Agents SDK, AI SDK, Claude Agent SDK — showing it is not locked to a single vendor's models and can be paired with whichever LLM the developer chooses. Missing for 10: an explicit first-party 'model-agnostic' positioning statement and independent/community corroboration of using Steel with a non-default LLM provider.

   • [claimed-docs] “Use Gemini Computer Use with Steel Browser.”
   • [claimed-docs] “Use Claude Computer Use with Steel Browser.”
   • [claimed-docs] “The OpenAI Computer Use integration runs OpenAI's vision-based agent loop on a Steel browser session.”
   • [claimed-docs] “Use Browser-Use to interact with a Steel browser.”
   • [claimed-docs] “Build a Pydantic AI browser agent on Steel cloud browsers: provider-agnostic, typed Python agents with dependency injection and real web acc…”
   • [claimed-docs] “The Steel integration runs each agent's browser actions on a Steel cloud session, so AgentKit handles the orchestration and Steel handles th…”
   • [claimed-docs] “The Steel integration runs each tool against a Steel cloud session (open, navigate, snapshot, extract, return typed results)”
   • [claimed-docs] “The Steel integration runs each tool against a Steel cloud session, so you can stand up a typed browser agent that opens a session, navigate…”
   • [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 brow”

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

   Steel's Sessions API lets an agent spin up a hosted, isolated browser via HTTP without managing browser infrastructure (steel-docs-1, steel-docs-33), and its agent-trace/timeline features (steel-docs-6, steel-docs-27, steel-docs-29) could support polling for run results. But there is no evidence of a discrete 'submit task, get result via polling/webhook' primitive — the model shown is that the agent (or a partner SDK like AgentKit/CrewAI) still drives actions step-by-step over CDP/Puppeteer/Playwright or the CLI (steel-gh-1, steel-docs-8), not a single task-submission endpoint. Missing for 10: an explicit task/job endpoint, webhook-based completion notification, and confirmation that the calling agent need not issue any browser actions 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] “Session Lifecycle | Steel 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] “Agent Traces: Observability for Browser Agents | Steel Docs”
   • [claimed-docs] “Agent Traces API | Steel Docs”
   • [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
   • [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~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~partialclaimed6/10

   Steel provides the browser infrastructure (sessions, navigation, click/fill/extract via CLI or API) and integrates with third-party agent loops (Claude/OpenAI Computer Use, browser-use, CrewAI, OpenAI Agents SDK) that can take a natural-language goal and drive multi-step web flows end-to-end, but Steel itself explicitly delegates the 'agent loop'/reasoning to these other SDKs rather than natively interpreting NL goals itself (e.g. 'the SDK runs the agent loop and Steel handles the browser'). The CLI supports scripted end-to-end browser workflows but not NL-goal parsing on its own. missing for 10: a native Steel agent loop that itself parses an NL goal and autonomously plans/executes steps without pairing with an external agent SDK; independent hands-on evidence of a full NL-to-task run succeeding.

   • [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.”
   • [claimed-docs] “The OpenAI Computer Use integration runs OpenAI's vision-based agent loop on a Steel browser session.”
   • [claimed-docs] “Use Browser-Use to interact with a Steel browser.”
   • [claimed-docs] “The Steel integration exposes a Steel browser as a CrewAI tool, so your crew can search, navigate, fill forms, extract data, and validate re…”
   • [claimed-docs] “The Steel integration runs each tool against a Steel cloud session, so you can stand up a typed browser agent that opens a session, navigate…”
   • [claimed-docs] “Use Gemini Computer Use with Steel Browser.”
   • [claimed-docs] “Use Claude Computer Use with Steel Browser.”

   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 CLI and Sessions API support running sequential browser steps (navigate, click, extract, stop) via terminal or SDK, but nothing in the evidence describes composing workflows with loops, conditionals, or parameterized reusable flows — that logic is left to whichever orchestrating agent framework (CrewAI, AgentKit, etc.) sits on top of Steel. Missing for 10: any documentation of control-flow constructs (loops/branches), workflow parameters, or a workflow builder/editor within Steel itself.

   • [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.”
   • [claimed-docs] “The Steel integration runs each agent's browser actions on a Steel cloud session, so AgentKit handles the orchestration and Steel handles th…”
   • [claimed-docs] “The Steel integration exposes a Steel browser as a CrewAI tool, so your crew can search, navigate, fill forms, extract data, and validate re…”

   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 drawn
   Steel~partialprobed7/10

   Steel is API-first (Sessions API, CAPTCHA, proxies, agent traces, credentials, files all documented as API endpoints with an OpenAPI spec), and the UI features (debug URL, embed sessions, human-in-the-loop) are explicitly built to expose live sessions that are themselves API-created, suggesting strong parity. However, there's no explicit statement or independent confirmation that every UI-only feature (e.g., dashboard analytics, skill management, billing/team settings) has a documented API equivalent. missing for 10: explicit doc mapping UI dashboard features 1:1 to API endpoints, independent/hands-on confirmation of full parity, and detail on any UI-only settings lacking API access.

   • [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 is the open-source browser API for AI agents — managed cloud browsers with stealth, residential proxies, CAPTCHA solving, persistent p…”
   • [claimed-docs] “Explore API endpoints for building on Steel.”
   • [claimed-docs] “Agent Traces: Observability for Browser Agents | Steel Docs”
   • [claimed-docs] “Session Lifecycle | Steel Docs”
   • [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
   • [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] “Embed Sessions](/overview/sessions-api/embed-sessions)”

   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~partialclaimed4/10

   Steel documents exporting agent trace/session run data in open formats (markdown, JSON, ZIP with screenshots) and is itself open-source/self-hostable via Docker, giving users a path to leave the managed cloud. However there is no documentation of exporting other data types (credentials, files, session history/metadata, account data) in open formats, nor any explicit 'export everything and leave' workflow. missing for 10: full-account data export (credentials, files, session records) in open formats, documented data-portability/deletion workflow, independent confirmation of successful export/migration.

   • [claimed-docs] “Copy the run as markdown, download JSON, or grab a ZIP with markdown plus screenshots.”
   • [claimed-docs] “Agent Traces: Observability for Browser Agents | Steel Docs”
   • [github] “Pre-built Docker Image (combined API + UI)”
   • [github] “Steel.dev is an open-source browser API that makes it easy to build AI apps and agents that interact with the web. Instead of building autom…”
   • [claimed-docs] “Steel is the open-source browser API for AI agents — managed cloud browsers with stealth, residential proxies, CAPTCHA solving, persistent p…”

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

   Steel is explicitly described as an open-source browser API with a public GitHub repository (steel-dev/steel-browser) containing the source code, docs, and Docker image, confirming readable open-source code. Missing for 10: explicit statement of the license type (e.g., MIT/Apache) in the evidence pack and 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)”
   • [github] “Steel.dev is an open-source browser API that makes it easy to build AI apps and agents that interact with the web. Instead of building autom…”
   • [claimed-docs] “Steel is the open-source browser API for AI agents — managed cloud browsers with stealth, residential proxies, CAPTCHA solving, persistent p…”
   • [claimed-docs] “Steel is an open source browser API that lets you control fleets of browsers in the cloud.”

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

   Steel is explicitly open-source (steel-dev/steel-browser repo) and ships a pre-built combined API+UI Docker image, letting an AI-native user self-host the core product; community comments corroborate its open-source nature. Missing for 10: detailed self-host deployment/config docs (scaling, storage, auth setup) beyond the single Docker image mention, and no independent hands-on report of a successful self-hosted deployment.

   • [github] “Pre-built Docker Image (combined API + UI)”
   • [github] “Steel.dev is an open-source browser API that makes it easy to build AI apps and agents that interact with the web. Instead of building autom…”
   • [claimed-docs] “Steel is the open-source browser API for AI agents — managed cloud browsers with stealth, residential proxies, CAPTCHA solving, persistent p…”
   • [claimed-docs] “Steel is an open source browser API that lets you control fleets of browsers in the cloud.”
   • [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

   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 drawn
   Steel!disputedcontradicted3/10

   There is a pricing page implied but no documented rate/concurrency limits in the evidence pack, and community evidence directly contradicts pricing transparency: a user reports the pricing page shows $59 while the docs show $99 for the developer tier, indicating inconsistent/undocumented pricing rather than clear transparent pricing. missing for 10: documented per-task or per-browser-hour rate card, documented concurrency/rate limits, resolution of the pricing discrepancy, independent confirmation of consistent current pricing.

   • [community] “Looking interesting, will definitely give it a go. Btw, there is inconsistency between pricing page and pricing on docs. Pricing page for de…”
   • [claimed-docs] “Steel is the open-source browser API for AI agents — managed cloud browsers with stealth, residential proxies, CAPTCHA solving, persistent p…”

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

   No evidence in the pack mentions data residency, region selection, or geographic hosting options for Steel's cloud browser sessions; docs cover proxies, sessions, stealth, and integrations but never data storage location controls. Missing for 10: any mention of region selection, data residency options, or geographic data storage controls.

   ⚑ 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

   No evidence pack item addresses AI training data usage or opt-out policies for Steel; the docs focus on browser automation, sessions, proxies, and integrations with no mention of a data-training privacy commitment.

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

   While Steel manages sessions, credentials, and files (which could involve data retention concerns), no evidence describes user-facing controls for data retention periods, deletion policies, or GDPR-style data purging.

   ⚑ 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, usage analytics, or an opt-out/opt-in setting for data collection; Steel is open-source and self-hostable which could make this a fair question, but no documentation addresses it.

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

   Steel's debug URL / human-in-the-loop feature explicitly enables watching a live session and taking direct control when an agent gets stuck, and embed-sessions support live viewing in an app context. Missing for 10: independent/hands-on verification of the live handoff experience and no detail on how control reverts to the agent after human intervention.

   • [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] “Implement Human-in-the-Loop Controls | Steel Docs”
   • [claimed-docs] “Embed Sessions](/overview/sessions-api/embed-sessions)”

   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 step-by-step timeline of agent activity, and lets you export the run as markdown, JSON, or a ZIP with markdown plus screenshots, directly supporting replay debugging; session replays and debug URLs (live session view) are also documented. Missing for 10: independent/hands-on corroboration of the replay/timeline UI actually working, and explicit detail on 'video' replay format beyond the general 'session replays' tagline.

   • [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] “Agent Traces: Observability for Browser Agents | Steel Docs”
   • [claimed-docs] “Timeline and exports | Steel Docs”
   • [claimed-docs] “Agent Traces API | Steel Docs”
   • [claimed-docs] “Steel is the open-source browser API for AI agents — managed cloud browsers with stealth, residential proxies, CAPTCHA solving, persistent p…”
   • [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~partialclaimed5/10

   Steel's Sessions API supports spinning up isolated on-demand browser sessions with programmatic lifecycle management (create, custom session IDs, session lifecycle docs) and a CLI/SDK for scripting sessions, which supports parallel automation use cases. However, there is no documented concurrency limit, fleet-level quota, or explicit guidance on running many sessions concurrently (rate limits, max parallel sessions per plan, autoscaling behavior) in the evidence provided. missing for 10: documented concurrency/session limits per plan, explicit fleet-scale orchestration guidance, benchmarks or independent confirmation of concurrent session handling at scale.

   • [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] “Session Lifecycle | Steel Docs”
   • [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~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 anywhere in the pack of a webhook or event-notification system for session/task completion; Steel's docs focus on session lifecycle, agent traces, and API endpoints but never mention webhooks or push notifications for status changes.

   ⚑ 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 an explicit CAPTCHA stance: automatic solving is built into the stealth mode (one flag covers detection/solving/verification) with a dedicated captcha-solving doc and API endpoints, plus human-in-the-loop debug URLs for manual takeover as fallback, avoiding silent failures. Missing for 10: independent/hands-on confirmation that captcha solving actually succeeds in practice and clearer documentation of failure/error signaling when solving fails.

   • [claimed-docs] “One flag covers detection, solving, and verification for the whole session”
   • [claimed-docs] “What Is a CAPTCHA Solver? Automatic CAPTCHA Solving API | Steel Docs”
   • [claimed-docs] “Explore API endpoints for managing Steel Captchas.”
   • [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] “Implement Human-in-the-Loop Controls | Steel Docs”
   • [claimed-docs] “Steel is the open-source browser API for AI agents — managed cloud browsers with stealth, residential proxies, CAPTCHA solving, persistent p…”

   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 contains extensive documentation of Steel's stealth, captcha-solving, and proxy features, but no published acceptable-use policy, anti-abuse guidelines, or terms governing what these features may legally/ethically be used for. No AUP, ToS excerpt, or abuse-prevention statement is cited anywhere in the pack.

   ⚑ 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 describe stealth mode (bot-detection evasion + CAPTCHA solving in one flag) and both Managed Residential Proxies and Bring-Your-Own-Proxy options, directly matching the story; a community comment corroborates that custom proxies work. Missing for 10: explicit geo-targeting/country-selection documentation and independent hands-on verification that stealth actually reduces bot-blocking in production.

   • [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…”
   • [claimed-docs] “Steel is the open-source browser API for AI agents — managed cloud browsers with stealth, residential proxies, CAPTCHA solving, persistent p…”
   • [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 Steel
   Steel~partialclaimed4/10

   Steel doesn't natively expose a Zod/Pydantic-style schema-validated extraction API, but several ecosystem integrations reference typed extraction — the AI SDK integration explicitly does 'extract, return typed results' and the Pydantic AI integration builds 'typed Python agents' on Steel sessions, implying schema validation is handled by those frameworks atop Steel's browser access rather than by Steel itself. Missing for 10: first-party Steel API/SDK documentation showing a defined schema (Zod or Pydantic model) passed directly to a Steel extraction endpoint, and independent confirmation that this pattern works reliably.

   • [claimed-docs] “The Steel integration runs each tool against a Steel cloud session (open, navigate, snapshot, extract, return typed results)”
   • [claimed-docs] “Build a Pydantic AI browser agent on Steel cloud browsers: provider-agnostic, typed Python agents with dependency injection and real web acc…”
   • [claimed-docs] “The Steel integration runs each tool against a Steel cloud session, so you can stand up a typed browser agent that opens a session, navigate…”
   • [github] “Browser Tools: Exposes APIs to quick convert pages to markdown, readability, screenshots, or PDFs.”

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

   Steel documents a Files API endpoint for managing files on Steel sessions (steel-docs-16), plus agent traces that can be downloaded as JSON/ZIP/markdown artifacts (steel-docs-7), suggesting some upload/download and artifact retrieval capability. However, there's no detailed documentation of the file upload/download workflow itself (e.g., how an agent uploads a file to a site form or downloads a file from a page and retrieves it via API), no code examples, and no independent verification of this working end-to-end. missing for 10: detailed docs/examples of agent-initiated file upload to sites and file download from sites, confirmation of artifact retrieval workflow, independent/hands-on corroboration.

   • [claimed-docs] “Explore API Endpoints for managing Files on Steel.”
   • [claimed-docs] “Copy the run as markdown, download JSON, or grab a ZIP with markdown plus screenshots.”
   • [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—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