Steel vs Smooth

Caching

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

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

   Smooth—none0/10

   Smooth is a browser-automation/agent-execution product; nothing in the evidence describes caching resolved actions or generated code for deterministic, cheaper replay. Structured outputs (docs-5/19) enable deterministic parsing of results but not caching/replay of prior runs to avoid re-prompting the LLM.

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

   Smooth~partialcommunity6/10

   Smooth is fundamentally a natural-language task/agent runner ("run this task," "extract this schema," "navigate complex forms") rather than exposing explicit act/click/type primitives on described elements, so selector-resilience is implied by its AI-driven, description-based navigation but not framed as discrete DOM action primitives like click/type. Docs show it handles form filling, data extraction, and navigation robustly via natural-language description (docs-26, docs-31), which supports layout/selector resilience, but there's no explicit low-level action API or documentation of survival across selector/layout changes, and one community comment notes agent-browser (a competitor) 'doesn't completely close the gap' versus Playwright, suggesting these AI-driven approaches aren't fully proven equivalents to primitive-level control. missing for 10: explicit act/click/type primitive API documentation, independent evidence of survival across selector/layout changes, and direct comparison data validating robustness claims.

   • [claimed-docs] “Your agent can extract structured data from any webpage and return it in a format you can work with. No parsing HTML, no writing selectors -…”
   • [claimed-docs] “Your agent can navigate complex multi-step forms, handle dropdowns and checkboxes, and submit data - saving you from repetitive data entry.”
   • [claimed-docs] “task = smooth_client.run("Go to google flights and find the cheapest flight from London to Paris today")”
   • [community] “agent-browser helped a lot over playwright but doesn't completely close the gap.”

   proof ↗⚑ flag

Observe

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

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

   Smooth—none0/10

   Smooth's docs describe live viewing of an agent already running (live_url, live-view) and a pause-and-wait mechanism for custom tools, but nothing lets a developer preview/list candidate actions and approve a plan before the agent commits to acting on the page — no dry-run, plan-preview, or action-approval primitive is documented.

   ⚑ 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

   Smooth—none0/10

   Smooth's docs describe task-based, session-based, and CLI browser automation with structured extraction, but nowhere mention a vision/computer-use mode operating on screenshots for canvases or non-DOM UI elements. This is a fair axis for a browser-automation product, but no evidence supports it. Missing for 10: any mention of vision-based/computer-use action mode, screenshot-driven interaction, or canvas/non-DOM element handling.

   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”
   • [claimed-docs] “Browser sessions allow you to run multiple sequential tasks in a single browser instance. This enables you to break complex workflows into s…”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”
   • [claimed-docs] “Extract structured data from the current page by providing a schema.”
   • [github] “The Smooth CLI is a browser for AI agents, enabling tools like Claude Code to navigate the web quickly, cheaply, and reliably.”

   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

   Smooth✓fullprobed9/10

   A direct probe confirms llms.txt is live and returns HTTP 200 with a structured docs index, and Smooth's docs are extensively agent-oriented (CLI usage guides for Claude Code/other agents, .md-suffixed doc pages for machine consumption). Missing for 10: no independent/community confirmation that agents actually consume the llms.txt successfully in practice.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.smooth.sh/llms.txt # Smooth ## Docs - [Introduction](https://docs.smooth.sh/index.md): Welcome to…”
   • [claimed-docs] “Smooth CLI works with any agent that can run CLI commands.”
   • [claimed-docs] “Ask Claude to do something on the web. It will use Smooth automatically.”

   proof ↗⚑ flag

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

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

   Smooth~partialprobed6/10

   Smooth exposes a REST API, Python SDK, and CLI that can run tasks headlessly (4-line quickstart, polling-based task list/cancel/event endpoints, CLI usable by 'any agent that can run CLI commands'), all consistent with CI-style automation. However there is no explicit CI/CD example, no mention of headless flags, containerization, or GitHub Actions integration, and community feedback focuses on live-view/human-in-the-loop demos rather than pure automation. missing for 10: explicit CI/CD pipeline example, headless-mode documentation/flags, independent confirmation of unattended automation use.

   • [claimed-docs] “Plug-and-play: Run a task in just 4 lines of code, making it easy to integrate into your workflow.”
   • [claimed-docs] “task = smooth_client.run("Go to google flights and find the cheapest flight from London to Paris today")”
   • [claimed-docs] “The Smooth API enables programmatic browser automation through REST endpoints. You can run AI-powered tasks, create interactive browser sess…”
   • [claimed-docs] “The API uses polling rather than webhooks or WebSockets for several reasons: Simplicity - No need to set up webhook endpoints or maintain We…”
   • [claimed-docs] “List all tasks for the authenticated user.”
   • [claimed-docs] “Cancel a running task by its ID.”
   • [claimed-docs] “Smooth CLI works with any agent that can run CLI commands.”
   • [probe] “official CLI documented at https://docs.smooth.sh/cli/overview”

   proof ↗⚑ flag

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

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

   Smooth—none0/10

   Smooth is a browser-automation service (not itself an agent), so an official MCP server is a plausible ask, but the docs explicitly say custom tools are offered 'similar to MCP... but without having to deal with servers or additional infrastructure' — indicating no MCP server is provided. No evidence of an official MCP server integration exists anywhere in the pack.

   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool. This is similar to MCP (Model Context Protocol) but without having t…”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool.”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

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

   Smooth✓fullprobed8/10

   Smooth ships an official CLI documented extensively (overview, integrations with Claude Code/OpenClaw/other agents, localhost tunneling, data extraction, auth, file handling, live view) and is explicitly framed as 'a browser for AI agents' per GitHub docs. missing for 10: independent/hands-on verification of the CLI itself (community discussion focuses on the API/product broadly, not CLI-specific experience) and no changelog/version history showing CLI maturity.

   • [claimed-docs] “Give your AI agent a browser that actually works”
   • [claimed-docs] “Ask Claude to do something on the web. It will use Smooth automatically.”
   • [claimed-docs] “Ask your agent to do something on the web. It will use Smooth automatically.”
   • [claimed-docs] “Smooth CLI works with any agent that can run CLI commands.”
   • [claimed-docs] “Your agent can access localhost and your local network through a secure tunnel. This is perfect for testing local apps, accessing internal t…”
   • [claimed-docs] “Every session comes with a live view URL where you can watch your agent browse in real-time. You can also take over and interact with the br…”
   • [github] “The Smooth CLI is a browser for AI agents, enabling tools like Claude Code to navigate the web quickly, cheaply, and reliably.”
   • [probe] “official CLI documented at https://docs.smooth.sh/cli/overview”

   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

   Smooth✓fullprobed8/10

   Smooth documents a full REST API with programmatic task running, sessions, custom tools, structured outputs, and event endpoints (smooth-docs-20, 34, 35, 37-39), plus a quickstart SDK code example (smooth-docs-13). This is a well-documented public API clearly aimed at AI-native/agentic use cases. Missing for 10: no formal OpenAPI/swagger spec found (smooth-probe-2 shows 404s on all candidate paths) and no independent third-party corroboration of API robustness beyond docs.

   • [claimed-docs] “The Smooth API enables programmatic browser automation through REST endpoints. You can run AI-powered tasks, create interactive browser sess…”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”
   • [claimed-docs] “Custom tools allow you to extend the agent's capabilities by registering functions that it can call during execution. When the agent needs t…”
   • [claimed-docs] “List all tasks for the authenticated user.”
   • [claimed-docs] “Cancel a running task by its ID.”
   • [claimed-docs] “Send an event to a running task. This is used for: - **Session actions**: `run_task`, `goto`, `extract`, `evaluate_js`, `close`”
   • [claimed-docs] “task = smooth_client.run("Go to google flights and find the cheapest flight from London to Paris today")”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.smooth.sh/openapi.json, https://docs.smooth.sh/swagger.json, https://docs.smooth.sh/api…”

   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

   Smooth—none0/10

   No evidence of scoped/least-privilege API credential issuance for agents; Smooth uses standard API keys/auth but there's no mention of scoped permissions, role-based access, or credential minimization features for agents.

   ⚑ flag

7. ai-native userBuild against official SDKs

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

   Smooth✓fullprobed7/10

   Docs show a Python-style client (`smooth_client.run(...)`), a full REST API reference (tasks, sessions, events, custom tools), and a CLI positioned for agent integration (Claude Code, generic agents), demonstrating an official SDK/API surface for building AI-native workflows. Missing for 10: an OpenAPI/swagger spec (probe found all candidate paths 404), explicit multi-language SDK coverage beyond the single quickstart snippet, and independent hands-on corroboration of SDK developer experience beyond community demo reactions.

   • [claimed-docs] “task = smooth_client.run("Go to google flights and find the cheapest flight from London to Paris today")”
   • [claimed-docs] “The Smooth API enables programmatic browser automation through REST endpoints. You can run AI-powered tasks, create interactive browser sess…”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool.”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool. This is similar to MCP (Model Context Protocol) but without having t…”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”
   • [claimed-docs] “Custom tools allow you to extend the agent's capabilities by registering functions that it can call during execution. When the agent needs t…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.smooth.sh/openapi.json, https://docs.smooth.sh/swagger.json, https://docs.smooth.sh/api…”
   • [github] “The Smooth CLI is a browser for AI agents, enabling tools like Claude Code to navigate the web quickly, cheaply, and reliably.”

   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

   Smooth—none0/10

   The docs explicitly state Smooth's API uses polling instead of webhooks or WebSockets, and no evidence anywhere describes a webhook subscription mechanism for task/session events.

   • [claimed-docs] “The API uses polling rather than webhooks or WebSockets for several reasons: Simplicity - No need to set up webhook endpoints or maintain We…”

   proof ↗⚑ flag

Agentic features

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

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

   Smooth~partialclaimed5/10

   Smooth lets users kick off tasks via API/CLI that then run asynchronously (task run, live_url to watch progress, polling for status, persistent sessions/auth) and can be invoked by agents like Claude Code, so there is some background/async execution. However there is no evidence of scheduling, triggers, or recurring/autonomous automation setup — the API explicitly relies on client polling rather than webhooks, and every task appears to be manually initiated rather than self-triggering. Missing for 10: scheduling/cron or trigger-based automation setup, evidence of tasks running without a user/agent explicitly starting them, and independent confirmation of unattended long-running automations.

   • [claimed-docs] “task = smooth_client.run("Go to google flights and find the cheapest flight from London to Paris today")”
   • [claimed-docs] “When running a task, you will receive a `live_url`, which can be used to view the agent actions live.”
   • [claimed-docs] “Log in once, then reuse that authentication for future tasks.”
   • [claimed-docs] “The API uses polling rather than webhooks or WebSockets for several reasons: Simplicity - No need to set up webhook endpoints or maintain We…”
   • [claimed-docs] “Ask Claude to do something on the web. It will use Smooth automatically.”
   • [claimed-docs] “List all tasks for the authenticated user.”

   proof ↗⚑ flag

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

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

   Smooth✓fullclaimed8/10

   Docs show the core interaction model is natural-language task strings (e.g. smooth_client.run("Go to google flights and find the cheapest flight...")) and CLI integrations where you simply 'ask Claude to do something on the web' and Smooth executes it automatically, confirming NL-driven operation across SDK, API, and CLI. Missing for 10: independent hands-on validation of NL command reliability/robustness on complex tasks (community comments focus on speed/pricing/security, not NL fidelity) and no published evals confirming consistent natural-language task success.

   • [claimed-docs] “task = smooth_client.run("Go to google flights and find the cheapest flight from London to Paris today")”
   • [claimed-docs] “Ask Claude to do something on the web. It will use Smooth automatically.”
   • [claimed-docs] “Ask your agent to do something on the web. It will use Smooth automatically.”
   • [claimed-docs] “Smooth CLI works with any agent that can run CLI commands.”
   • [claimed-docs] “Give your AI agent a browser that actually works”
   • [github] “The Smooth CLI is a browser for AI agents, enabling tools like Claude Code to navigate the web quickly, cheaply, and reliably.”

   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

   Smooth—none0/10

   Docs include an API reference section (smooth-docs-20, smooth-docs-34–39) and quickstart code snippets, but there is no evidence of an interactive reference with runnable/try-it examples — the openapi probe found no spec at any standard location (smooth-probe-2), and no docs page mentions a live console or executable code sandbox.

   • [claimed-docs] “The Smooth API enables programmatic browser automation through REST endpoints. You can run AI-powered tasks, create interactive browser sess…”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”
   • [claimed-docs] “List all tasks for the authenticated user.”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.smooth.sh/openapi.json, https://docs.smooth.sh/swagger.json, https://docs.smooth.sh/api…”

   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

   Smooth—none0/10

   Smooth has an API reference documented as prose (endpoints like list-tasks, cancel-task, send-event) but a direct probe for OpenAPI/Swagger spec files at all standard paths returned 404, and no evidence shows a downloadable machine-readable spec.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.smooth.sh/openapi.json, https://docs.smooth.sh/swagger.json, https://docs.smooth.sh/api…”
   • [claimed-docs] “The Smooth API enables programmatic browser automation through REST endpoints. You can run AI-powered tasks, create interactive browser sess…”
   • [claimed-docs] “List all tasks for the authenticated user.”

   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

   Smooth—none0/10

   Smooth is a browser-automation/agent tool for navigating the live web; there is no evidence of a sandbox/staging environment or test-data isolation feature to avoid touching production data. missing for 10: any mention of sandbox mode, test/staging environment, or production-data isolation.

   ⚑ 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

   Smooth—none0/10

   No evidence of API versioning scheme (e.g., /v1/ paths) or any documented deprecation policy; OpenAPI spec probe returned 404s and docs mention no versioning/deprecation guidance.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.smooth.sh/openapi.json, https://docs.smooth.sh/swagger.json, https://docs.smooth.sh/api…”

   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

   Smooth—none0/10

   Smooth's docs describe a task/prompt-driven API (run natural-language tasks, sessions, extract, custom tools) and a CLI for AI agents, but nowhere mention exposing a CDP endpoint, Playwright `connectOverCDP`, or Puppeteer compatibility that would let developers point existing automation scripts at Smooth's browsers. The product's interface is agent/task-based rather than a raw remote-browser protocol.

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

   Smooth—none0/10

   Smooth documents session/profile persistence (log in once, reuse cookies for future tasks) but there is no evidence of a credential vault, TOTP/2FA handling, or any mechanism ensuring secrets are never exposed to the underlying model — the story's core requirements are unaddressed.

   • [claimed-docs] “Log in once, then reuse that authentication for future tasks.”
   • [claimed-docs] “Browser profiles allow you to persist cookies and authentication across sessions. Log in once, then reuse that authentication for future tas…”
   • [claimed-docs] “Browser profiles save your login state so your agent can access authenticated content. Log in once manually, then your agent can work with t…”

   proof ↗⚑ flag

Profiles

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

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

   Smooth✓fullclaimed8/10

   Docs explicitly describe browser profiles that persist cookies/authentication so agents can 'log in once' and reuse that session indefinitely, both in the API/SDK docs and CLI docs. This directly matches the story, though there's no independent/hands-on verification of the feature working in practice. Missing for 10: independent/community confirmation of persistent-session reliability, details on profile management/rotation across multiple agents.

   • [claimed-docs] “Log in once, then reuse that authentication for future tasks.”
   • [claimed-docs] “Browser profiles allow you to persist cookies and authentication across sessions. Log in once, then reuse that authentication for future tas…”
   • [claimed-docs] “Browser profiles save your login state so your agent can access authenticated content. Log in once manually, then your agent can work with t…”

   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

   Smooth~partialclaimed4/10

   Smooth supports multi-step sequential task execution within a persistent browser session (docs-7, docs-14, docs-34) and a task-list/cancel API (docs-37, docs-38), which lets a workflow process several items one after another, but there is no documented bulk/batch endpoint, parallel execution, or 'run against N items' primitive. missing for 10: explicit batch/bulk API or parallel multi-item execution, evidence of throughput at scale, independent confirmation of bulk workflows.

   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”
   • [claimed-docs] “Browser sessions allow you to run multiple sequential tasks in a single browser instance. This enables you to break complex workflows into s…”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”
   • [claimed-docs] “List all tasks for the authenticated user.”
   • [claimed-docs] “Cancel a running task by its ID.”

   proof ↗⚑ flag

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

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

   Smooth—none0/10

   Smooth is a browser-automation SDK/CLI that runs tasks on demand or in sequential sessions, but there is no evidence of a rules/trigger engine that fires actions automatically on external events — it explicitly uses polling rather than webhooks/WebSockets (smooth-docs-36) and 'monitoring' is described as on-demand checks (smooth-docs-33), not autonomous event-driven rules.

   • [claimed-docs] “The API uses polling rather than webhooks or WebSockets for several reasons: Simplicity - No need to set up webhook endpoints or maintain We…”
   • [claimed-docs] “Your agent can check websites on demand, monitor for changes, or gather status updates from various sources.”
   • [claimed-docs] “Send an event to a running task. This is used for: - **Session actions**: `run_task`, `goto`, `extract`, `evaluate_js`, `close`”

   proof ↗⚑ flag

3. ai-native userSchedule recurring jobs or workflows

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

   Smooth—none0/10

   Smooth is a browser-automation/agent-tool product for running and orchestrating tasks, sessions, and workflows, but nothing in the evidence mentions scheduling, cron-like recurrence, or triggering jobs on a recurring basis; the API instead relies on synchronous task runs and polling with no scheduler mentioned.

   ⚑ 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

   Smooth—none0/10

   Smooth is architected as a cloud service — tasks run via API/CLI against Smooth's hosted browser infrastructure, requiring sign-in (e.g. Google SSO) and producing a live_url on Smooth's servers; the closest local feature is a tunnel that lets the *cloud* agent reach your localhost (smooth-docs-12, smooth-docs-25), not the agent itself running locally without an account. Community feedback explicitly asks for self-hosting because it currently isn't available ("Make it self-hostable, the conversation can change" — smooth-comm-10) and flags discomfort sending data to Smooth's third-party servers (smooth-comm-11, smooth-comm-13), confirming no local/no-cloud-account mode exists.

   • [claimed-docs] “Set to `"self"` to create a P2P tunnel through your machine, routing traffic via your IP and enabling access to localhost.”
   • [claimed-docs] “Your agent can access localhost and your local network through a secure tunnel. This is perfect for testing local apps, accessing internal t…”
   • [community] “Is there a way to sign up without Google SSO?”
   • [community] “I'm unwilling to send my data to a 3rd party that is so new on the scene... Make it self-hostable, the conversation can change”
   • [community] “My first question was whether I could use this for sensitive tasks, given that it's not running on our machines. And after poking around for…”
   • [community] “You describe problems I don't have. I'm happy with Playwright and other scraping tools. Certainly not frustrated enough to pay to send my da…”

   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

   Smooth~partialclaimed4/10

   Smooth documents integration with Claude Code and generic CLI agents, and offers custom-tools/API hooks that could be wired into agent frameworks, but there is no documented adapter for Vercel AI SDK, LangChain, or CrewAI specifically. missing for 10: named/documented adapters for Claude Agent SDK, Vercel AI SDK, LangChain, and CrewAI; independent confirmation of framework integrations.

   • [claimed-docs] “Ask Claude to do something on the web. It will use Smooth automatically.”
   • [claimed-docs] “Ask your agent to do something on the web. It will use Smooth automatically.”
   • [claimed-docs] “Smooth CLI works with any agent that can run CLI commands.”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool. This is similar to MCP (Model Context Protocol) but without having t…”
   • [claimed-docs] “Custom tools allow you to extend the agent's capabilities by registering functions that it can call during execution. When the agent needs t…”

   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

   Smooth—none0/10

   Smooth's docs describe it as using its own internal 'small and efficient AI models' (smooth-docs-11) with no mention anywhere in the docs, API reference, or CLI guides of a way to configure or swap in a different LLM provider — the product is presented as a fixed browser-automation service, not a model-agnostic framework.

   • [claimed-docs] “Smooth uses small and efficient AI models, making it 7x more affordable than browser-use.”
   • [claimed-docs] “The Smooth API enables programmatic browser automation through REST endpoints. You can run AI-powered tasks, create interactive browser sess…”
   • [claimed-docs] “Give your AI agent a browser that actually works”

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

   Smooth✓fullprobed8/10

   Smooth's REST API lets an agent submit a task (smooth_client.run), poll task status/list tasks, cancel tasks, and send events, with docs explicitly describing polling as the primary mechanism (and webhooks mentioned as an alternative rejected in favor of polling for simplicity) — all without the caller managing a browser itself. missing for 10: no independent/hands-on confirmation of webhook support or polling reliability at scale, and no public OpenAPI spec was found to verify full REST contract.

   • [claimed-docs] “task = smooth_client.run("Go to google flights and find the cheapest flight from London to Paris today")”
   • [claimed-docs] “The Smooth API enables programmatic browser automation through REST endpoints. You can run AI-powered tasks, create interactive browser sess…”
   • [claimed-docs] “The API uses polling rather than webhooks or WebSockets for several reasons: Simplicity - No need to set up webhook endpoints or maintain We…”
   • [claimed-docs] “List all tasks for the authenticated user.”
   • [claimed-docs] “Cancel a running task by its ID.”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.smooth.sh/openapi.json, https://docs.smooth.sh/swagger.json, https://docs.smooth.sh/api…”

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

   Smooth✓fullcommunity8/10

   Docs give a concrete quickstart example ("Go to google flights and find the cheapest flight...") plus dedicated use-case docs for form-filling, multi-step session workflows, navigation, and data extraction, and community feedback confirms real-world use ("wrote a complex prompt and it did a good job", "impressive demo"). Missing for 10: independent reproducible benchmarks/evals (community explicitly asks for this and it's unanswered) and no hands-on failure reports to corroborate reliability at scale.

   • [claimed-docs] “task = smooth_client.run("Go to google flights and find the cheapest flight from London to Paris today")”
   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”
   • [claimed-docs] “Your agent can navigate complex multi-step forms, handle dropdowns and checkboxes, and submit data - saving you from repetitive data entry.”
   • [claimed-docs] “Your agent can browse the web, visit multiple sources, and compile research on any topic. It handles the tedious clicking and reading while …”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”
   • [community] “Super impressive demo. Seems a lot faster than alternatives. How did you achieve that?”
   • [community] “I just wrote a complex prompt and it did a good job. How do you do evals or testing of your project?”
   • [community] “are your evals / comparisons publicly/3rd party reproducible? If it's 'trust me, I did a fair comparison', that's not going to fly today.”

   proof ↗⚑ flag

Workflows

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

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

   Smooth~partialclaimed5/10

   Smooth supports composing multi-step workflows via persistent browser 'sessions' where you can chain sub-tasks, navigate, and extract data (smooth-docs-7, smooth-docs-14, smooth-docs-34), plus custom tools and structured outputs that let developers write deterministic branching code around agent calls (smooth-docs-5, smooth-docs-6, smooth-docs-35). However, this is achieved by the developer scripting loops/conditionals in their own code around Smooth's session/task API rather than Smooth providing a native workflow DSL with built-in loop/conditional/parameter constructs. Missing for 10: a first-class declarative workflow definition language (loops, conditionals, parameters) documented as a Smooth feature, and independent evidence of complex repeatable workflows being built this way.

   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”
   • [claimed-docs] “Browser sessions allow you to run multiple sequential tasks in a single browser instance. This enables you to break complex workflows into s…”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”
   • [claimed-docs] “Structured outputs allow you to write deterministic code based on the agent's output. To activate structured outputs, set the `response_mode…”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool.”
   • [claimed-docs] “Custom tools allow you to extend the agent's capabilities by registering functions that it can call during execution. When the agent needs t…”

   proof ↗⚑ flag

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

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

   Smooth~partialclaimed5/10

   Smooth's primary interface is the API (task run, sessions, custom tools, extraction, event sending) with the CLI acting as a thin wrapper on top of it, suggesting the API is close to feature-complete. However, there's no dashboard/UI described beyond a live-view/take-over feature, and no explicit statement confirming that UI-only actions (like manually taking over a live browser session) are also achievable via the API. missing for 10: explicit UI vs API parity statement, evidence of a full dashboard whose features are all API-accessible, confirmation that live-view interactive takeover can be done programmatically.

   • [claimed-docs] “The Smooth API enables programmatic browser automation through REST endpoints. You can run AI-powered tasks, create interactive browser sess…”
   • [claimed-docs] “Every session comes with a live view URL where you can watch your agent browse in real-time. You can also take over and interact with the br…”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”
   • [claimed-docs] “Send an event to a running task. This is used for: - **Session actions**: `run_task`, `goto`, `extract`, `evaluate_js`, `close`”
   • [claimed-docs] “Smooth CLI works with any agent that can run CLI commands.”

   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

   Smooth—none0/10

   Smooth's docs cover task lists, structured outputs, and a Zero Data Retention deletion feature, but nowhere mention exporting user data (tasks, sessions, extracted data) in open/portable formats or account data export. Since Smooth stores task history and outputs via its API, this axis is a fair question, but no evidence of an export capability exists.

   • [claimed-docs] “Zero Data Retention is an enterprise feature that provides enhanced data privacy by allowing you to delete all data associated with complete…”
   • [claimed-docs] “List all tasks for the authenticated user.”

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

   Smooth—none0/10

   While a GitHub repo (smooth-sdk) exists for the CLI, there is no evidence of an open-source license covering the product's core source, and a community comment explicitly requests Smooth 'make it self-hostable' implying the core service is closed. No docs or GitHub evidence confirm an open license for the full product source.

   • [github] “The Smooth CLI is a browser for AI agents, enabling tools like Claude Code to navigate the web quickly, cheaply, and reliably.”
   • [community] “I'm unwilling to send my data to a 3rd party that is so new on the scene... Make it self-hostable, the conversation can change”
   • [community] “Way too expensive, I'll wait for a free/open source browser optimized to be used by agents.”

   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

   Smooth—none0/10

   Smooth is exclusively offered as a hosted cloud API/CLI service; no docs mention any self-hosted deployment option, and community feedback explicitly requests self-hosting as a missing feature ('Make it self-hostable, the conversation can change' and a plea for a 'free/open source browser' alternative), indicating it does not exist.

   • [community] “I'm unwilling to send my data to a 3rd party that is so new on the scene... Make it self-hostable, the conversation can change”
   • [community] “Way too expensive, I'll wait for a free/open source browser optimized to be used by agents.”
   • [claimed-docs] “The Smooth API enables programmatic browser automation through REST endpoints. You can run AI-powered tasks, create interactive browser sess…”

   proof ↗⚑ flag

Pricing

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

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

   Smooth—none0/10

   Evidence includes only a vague marketing claim of being '7x more affordable than browser-use' and a community complaint calling it 'way too expensive,' but no documented per-task/per-browser-hour pricing table, rate limits, or concurrency limits are found anywhere in the docs or API reference.

   • [claimed-docs] “Smooth uses small and efficient AI models, making it 7x more affordable than browser-use.”
   • [community] “Way too expensive, I'll wait for a free/open source browser optimized to be used by agents.”

   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

   Smooth—none0/10

   No evidence of any data residency/region selection feature; Smooth only mentions Zero Data Retention as an enterprise privacy feature, and community feedback even notes an absence of clear security/data-handling info.

   • [claimed-docs] “Zero Data Retention is an enterprise feature that provides enhanced data privacy by allowing you to delete all data associated with complete…”
   • [community] “My first question was whether I could use this for sensitive tasks, given that it's not running on our machines. And after poking around for…”

   proof ↗⚑ flag

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

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

   Smooth~partialcommunity4/10

   Smooth offers a 'Zero Data Retention' enterprise feature that lets users delete all task-associated data, which implicitly limits data being retained/used afterward, but there is no explicit statement that data is excluded from AI model training, and this protection is gated behind an enterprise tier. Community feedback (smooth-comm-10, smooth-comm-11) shows users are skeptical about data handling and found no clear security/privacy documentation beyond vague marketing claims. Missing for 10: explicit training-data-usage policy, default (non-enterprise) opt-out, and independent verification of the retention/deletion claim.

   • [claimed-docs] “Zero Data Retention is an enterprise feature that provides enhanced data privacy by allowing you to delete all data associated with complete…”
   • [community] “I'm unwilling to send my data to a 3rd party that is so new on the scene... Make it self-hostable, the conversation can change”
   • [community] “My first question was whether I could use this for sensitive tasks, given that it's not running on our machines. And after poking around for…”

   proof ↗⚑ flag

3. ai-native userControl data retention and deletion

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

   Smooth~partialcommunity5/10

   Smooth documents a 'Zero Data Retention' feature letting customers delete all data tied to completed tasks, directly addressing retention/deletion control, but it is explicitly gated as an 'enterprise' feature rather than a default/self-serve capability for all AI-native users. Community feedback (smooth-comm-11) also notes a broader lack of visible security/data-handling documentation on the product, though this doesn't concretely contradict the ZDR feature itself. Missing for 10: default (non-enterprise) retention policy details, self-service deletion/export controls for standard users, and independent verification that ZDR works as claimed.

   • [claimed-docs] “Zero Data Retention is an enterprise feature that provides enhanced data privacy by allowing you to delete all data associated with complete…”
   • [community] “My first question was whether I could use this for sensitive tasks, given that it's not running on our machines. And after poking around for…”

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

   Smooth—none0/10

   No evidence of a telemetry/usage-tracking opt-out setting; the only related feature is an enterprise Zero Data Retention option for deleting completed task data, which is not the same as opting out of telemetry/usage tracking. Community comments even raise unresolved concerns about data being sent to a third party with no security details, but no dispute of an explicit opt-out claim since none is made.

   • [claimed-docs] “Zero Data Retention is an enterprise feature that provides enhanced data privacy by allowing you to delete all data associated with complete…”
   • [community] “My first question was whether I could use this for sensitive tasks, given that it's not running on our machines. And after poking around for…”

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

   Smooth~partialclaimed6/10

   Docs confirm live_url/live-view to watch an agent session in real time and explicitly state users can 'take over and interact with the browser yourself' when needed, directly matching the story. However, there's no documented workflow for detecting when the agent is 'stuck', no hands-on/independent confirmation of the handoff mechanics, and no replay/debugging tooling described beyond live viewing. missing for 10: independent verification of the takeover UX, stuck-detection/alerting mechanism, and session replay/debugging after handoff.

   • [claimed-docs] “When running a task, you will receive a `live_url`, which can be used to view the agent actions live.”
   • [claimed-docs] “Every session comes with a live view URL where you can watch your agent browse in real-time. You can also take over and interact with the br…”

   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

   Smooth—none0/10

   Smooth documents only a real-time 'live_url'/live-view for watching an agent browse as it happens (smooth-docs-2, smooth-docs-29), with no evidence of recorded video/screenshot replays or a post-hoc step-by-step action timeline for debugging failed runs after the fact.

   • [claimed-docs] “When running a task, you will receive a `live_url`, which can be used to view the agent actions live.”
   • [claimed-docs] “Every session comes with a live view URL where you can watch your agent browse in real-time. You can also take over and interact with the br…”

   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

   Smooth—none0/10

   Smooth's docs describe programmatic task/session APIs (create, list, cancel tasks) but nowhere document concurrency limits, fleet-level orchestration, or guidance for running many parallel sessions at scale.

   • [claimed-docs] “The Smooth API enables programmatic browser automation through REST endpoints. You can run AI-powered tasks, create interactive browser sess…”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”
   • [claimed-docs] “List all tasks for the authenticated user.”
   • [claimed-docs] “Cancel a running task by its ID.”

   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

   Smooth—none0/10

   Smooth's docs explicitly state the API uses polling instead of webhooks or WebSockets, and no evidence anywhere in the pack shows a webhook notification feature for task/session completion. missing for 10: webhook/callback support, event subscription mechanism, any push-based notification alternative to polling.

   • [claimed-docs] “The API uses polling rather than webhooks or WebSockets for several reasons: Simplicity - No need to set up webhook endpoints or maintain We…”

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

   Smooth✓fullcommunity6/10

   Smooth explicitly documents an automatic captcha-solving stance ('Auto-CAPTCHA solvers: Bypass CAPTCHA challenges automatically, allowing for uninterrupted task execution'), giving automation engineers a clear documented behavior rather than silent failure. Community reaction (smooth-comm-3) criticizes the ethics/marketing of this feature but does not present a hands-on failure showing the solver doesn't work, so this remains a documented claim rather than a disputed one. Missing for 10: independent/hands-on verification that auto-solving actually succeeds in practice, and no documentation of fallback behavior (e.g., what happens if a captcha can't be auto-solved).

   • [claimed-docs] “Auto-CAPTCHA solvers: Bypass CAPTCHA challenges automatically, allowing for uninterrupted task execution.”
   • [community] “So you're shamelessly selling spambots? The marketing here is wild... "proxy rotation"... "auto-CAPTCHA solvers"”

   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

   Smooth—none0/10

   Smooth markets auto-CAPTCHA bypass, proxy rotation, and stealth automation (smooth-docs-9, smooth-docs-18) but no evidence pack item shows any published acceptable-use policy, terms of service, or anti-abuse stance governing these features. Community feedback even calls out the lack of such framing ('shamelessly selling spambots' — smooth-comm-3) and flags absence of any security/data-handling disclosure (smooth-comm-11), reinforcing the gap rather than filling it.

   • [claimed-docs] “Auto-CAPTCHA solvers: Bypass CAPTCHA challenges automatically, allowing for uninterrupted task execution.”
   • [claimed-docs] “Using proxies with Smooth allows you to run tasks from a different IP address, which can be useful for web scraping and automation tasks.”
   • [community] “So you're shamelessly selling spambots? The marketing here is wild... "proxy rotation"... "auto-CAPTCHA solvers"”
   • [community] “My first question was whether I could use this for sensitive tasks, given that it's not running on our machines. And after poking around for…”

   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

   Smooth~partialcommunity5/10

   Docs confirm proxy support ("specify the proxy server details in your task parameters") and auto-CAPTCHA solving, which support anti-blocking automation, but there is no documentation of stealth/fingerprint spoofing techniques or explicitly residential/geo-targeted proxy pools — only generic proxy configuration. Missing for 10: explicit stealth fingerprinting mechanism, residential proxy pool/geo-targeting options, and independent verification that these features actually avoid bot detection.

   • [claimed-docs] “To use a proxy with Smooth, you need to specify the proxy server details in your task parameters.”
   • [claimed-docs] “Using proxies with Smooth allows you to run tasks from a different IP address, which can be useful for web scraping and automation tasks.”
   • [claimed-docs] “Auto-CAPTCHA solvers: Bypass CAPTCHA challenges automatically, allowing for uninterrupted task execution.”
   • [community] “So you're shamelessly selling spambots? The marketing here is wild... "proxy rotation"... "auto-CAPTCHA solvers"”

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

   Smooth✓fullclaimed8/10

   Smooth's docs explicitly describe structured/typed extraction via a `response_model` schema field and a dedicated `session-extract` method that extracts structured data from the current page using a provided schema, directly matching the story's requirement for schema-validated extraction beyond raw text. Missing for 10: independent/hands-on confirmation that the schema validation behaves like Zod/Pydantic (e.g., error handling on validation failure) and no third-party review of this specific feature.

   • [claimed-docs] “Structured outputs allow you to write deterministic code based on the agent's output. To activate structured outputs, set the `response_mode…”
   • [claimed-docs] “Structured outputs allow you to write deterministic code based on the agent's output.”
   • [claimed-docs] “Extract structured data from the current page by providing a schema.”
   • [claimed-docs] “Extract structured data from the current page by providing a schema. The extraction uses the current page state, making it ideal for capturi…”
   • [claimed-docs] “Your agent can extract structured data from any webpage and return it in a format you can work with. No parsing HTML, no writing selectors -…”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”

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

   Smooth✓fullclaimed7/10

   Docs explicitly state the agent can upload files to sites and download files from the web, with structured/session-based workflows and live_url/task retrieval implying artifacts remain accessible afterward. missing for 10: independent/hands-on confirmation of file upload/download working in practice, and explicit detail on how downloaded artifacts are retrieved/stored post-task.

   • [claimed-docs] “Your agent can work with files in both directions - you can give it files to upload to websites, and it can download files from the web for …”
   • [claimed-docs] “When running a task, you will receive a `live_url`, which can be used to view the agent actions live.”
   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”
   • [claimed-docs] “Sessions allow you to maintain a persistent browser instance and perform multiple actions sequentially. This is useful for complex workflows…”

   proof ↗⚑ flag