Browser Use vs Steel
open-source · free-tier · usage-based
·open-source · free-tier · subscription · usage-based
Steel wins · 9–23 (16 drawn)
Action primitives — stories about action primitives in this arenaAction primitives
Stories about action primitives in this arena
Caching
developerCache resolved actions or generated code so repeat runs replay deterministically at lower cost and latency than re-prompting the LLM
weight 2 · round drawnBrowser Usenone0/10No evidence of caching resolved actions or generated code for deterministic, lower-cost replay; the product is LLM-driven agent automation with sessions/runs but nothing about caching or replay without re-invoking the model. missing for 10: any mention of action/code caching, deterministic replay mechanism, or cost/latency savings from skipping re-prompting.
Steelnone0/10Steel'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.
Dom
developerDrive the page through DOM-understanding action primitives (act/click/type on described elements) that survive selector and layout changes
weight 3 · round to Browser UseBrowser Use's core agent is built around natural-language task instructions (e.g. "Find the top Hacker News story", "Fill in this job application") executed via an LLM-driven agent that perceives the DOM/page state and decides actions, which is the essence of DOM-understanding, layout-resilient automation — this is corroborated by GitHub task examples and community hands-on use (LinkedIn automation, resume filling). However, the evidence pack lacks explicit documentation of discrete act/click/type primitives with described-element targeting or any stated guarantee/mechanism for surviving selector/layout changes; it's inferred from the agent's general design rather than directly documented. missing for 10: explicit API/primitive-level documentation of click/type/act-on-described-element functions, and direct evidence/testing showing resilience to selector or layout changes rather than just general LLM-driven task completion.
- [github] “Task: "Fill in this job application with my resume and information."”
- [github] “Task: "Extract structured data about my followers and export it as a CSV."”
- [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
Steelnone0/10Steel's evidence shows only traditional CDP/Puppeteer/Selenium-based control and CLI commands like click/fill/type (steel-docs-8, steel-gh-1), which are selector-based automation primitives, not AI/DOM-understanding 'act on described element' primitives that resolve targets semantically and survive selector/layout changes. No documentation or hands-on evidence describes a Stagehand-like natural-language action resolver.
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
Observe
developerPreview candidate actions on the current page (observe/plan) before committing the agent to act
weight 1 · round to SteelBrowser Usenone0/10Evidence shows live-preview URLs for human intervention during CAPTCHA/2FA and event polling for observability, but nothing about an explicit preview/plan step where candidate actions are surfaced for developer review before the agent commits to acting.
- [claimed-docs] “If the challenge remains, open the [live preview](/cloud/browser/live-preview) for human control.”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
- [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event]”
Steel exposes browser observation primitives (page-to-markdown/readability/screenshot extraction, agent traces/timeline, and a debug URL for human-in-the-loop review) that let a developer inspect page state or a human intervene mid-session, but there is no documented 'plan' or dry-run API that lets an agent preview a set of candidate actions before committing to execute them. missing for 10: an explicit plan/observe-then-act primitive or dry-run action preview API, evidence of independent developers using it specifically for pre-commit action review.
- [github] “Browser Tools: Exposes APIs to quick convert pages to markdown, readability, screenshots, or PDFs.”
- [claimed-docs] “Steel's debug URL feature allows you to implement human-in-the-loop workflows where users can directly interact with and control browser ses…”
- [claimed-docs] “It turns the run into a timeline of agent activity, so you can see what happened without scrubbing through the whole recording.”
Vision
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 drawnBrowser Usenone0/10Browser Use's docs describe DOM-based agent actions, live preview/human handoff for CAPTCHA/2FA, and CDP-based control, but there is no evidence of a dedicated vision or computer-use mode that acts directly on screenshots for canvas/UI elements the DOM can't reach.
Steelnone0/10Evidence shows Steel can capture screenshots, convert pages to markdown/PDF, and offers a debug URL for human-in-the-loop control, but there is no mention of a vision/computer-use action mode where an agent issues click/type actions based on screenshot coordinates instead of DOM selectors.
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
Agent access
ai-native userPoint an agent at llms.txt or agent-oriented docs
weight 2 · round to SteelBrowser Use publishes a discoverable llms.txt at docs.browser-use.com/llms.txt confirmed live via probe (HTTP 200), which is exactly the agent-oriented docs entry point an AI-native user could point an agent at, and the broader docs site is structured/markdown-friendly for agent consumption. Missing for 10: no evidence of additional structured formats like llms-full.txt or explicit guidance encouraging agents to consume it, and no independent community confirmation of agents successfully using it.
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.browser-use.com/llms.txt # Browser Use > Documentation for Browser Use Cloud Agent and Browser API…”
Probe confirms llms.txt is live at docs.steel.dev/llms.txt (HTTP 200) with agent-oriented framing, and the docs also expose an OpenAPI spec, making the docs machine/agent consumable. missing for 10: no independent third-party confirmation that agents actually consume the llms.txt file successfully in practice.
ai-native userRun the product headlessly / in CI for automation
weight 2 · round to SteelBrowser Use ships both an open-source Python library and a cloud API (client.runs.create) that are inherently script/automatable, implying headless/CI use, and gh-3 explicitly pitches automating the web 'from your own code, and with any LLM.' However, there is no explicit documentation of headless mode flags, Docker images, or CI pipeline examples/integration guides. Missing for 10: explicit headless-mode configuration docs, CI/CD pipeline examples (e.g., GitHub Actions), and independent confirmation of running unattended in CI.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
- [claimed-docs] “For a local agent, use the [open-source library](/open-source/quickstart).”
- [claimed-docs] “Launch a browser, connect to its CDP URL, then stop it”
Steel provides a documented CLI for end-to-end headless browser workflows from the terminal, a REST/SDK API for programmatic session creation, an open-source Docker image for self-hosting, and a verified probe confirming a keyless self-host roundtrip (docker run, health check, session creation via API, CLI install, SDK install) — all strongly supporting CI/headless automation use. missing for 10: no explicit first-party CI pipeline example (e.g., GitHub Actions template) or independent hands-on report of running Steel inside an actual CI system.
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [github] “Pre-built Docker Image (combined API + UI)”
- [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
- [probe] “official CLI documented at https://docs.steel.dev/overview/steel-cli”
- [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
ai-native userConnect an agent via an official MCP server
weight 3 · round to SteelBrowser Usedisputedcontradicted5/10Docs describe an official MCP server enabling Claude, Cursor, Windsurf or any MCP client to run Browser Use tasks (browser-use-docs-12, browser-use-probe-3), but a hands-on community report says the author had to switch tools because Browser Use 'doesn't support MCP integration' in Cursor (browser-use-comm-4), directly contradicting the documented claim. Missing for 10: independent corroboration that MCP connection actually works end-to-end, and resolution of the conflicting user report.
- [claimed-docs] “Run browser automation tasks from your AI coding assistant. Connect to Claude, Cursor, Windsurf, or any MCP client.”
- [probe] “official MCP server documented at https://docs.browser-use.com/cloud/guides/mcp-server”
- [community] “I want to use browser-use in Cursor but I am using another option because it doesn't support MCP integration which is the common language th…”
Steel's docs mention an integration with the Claude Agent SDK that 'exposes a cloud browser as in-process MCP tools,' showing some official MCP tool exposure for agents, but there's no evidence of a standalone, general-purpose official MCP server endpoint independent of this one SDK integration. missing for 10: a dedicated/standalone MCP server doc or endpoint usable by any agent framework, independent corroboration or hands-on proof of MCP connectivity.
- [claimed-docs] “The Steel integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the browser.”
ai-native userUse an official CLI
weight 2 · round to SteelBrowser Usenone0/10The evidence pack documents a Python SDK, cloud API, MCP server, and web dashboard, but never mentions an official standalone CLI tool for Browser Use. Since a browser-automation product could plausibly ship a CLI, absence of any such evidence means this axis is unmet.
Steel ships a documented official CLI (steel-docs-8) that supports end-to-end browser workflows from the terminal, and probe evidence confirms real installation via setup.steel.dev installing 'steel CLI 0.4.4' into a fresh environment (steel-probe-rt-1), corroborating the docs. Missing for 10: independent third-party reviews of the CLI's UX/reliability beyond the vendor-run probe, and more detail on advanced CLI subcommands/scripting capabilities.
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [probe] “official CLI documented at https://docs.steel.dev/overview/steel-cli”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
ai-native userDrive the product through a documented public API
weight 3 · round to SteelBrowser Use documents a public Cloud API (client.runs.create, sessions, events polling, structured output, CDP connection) across multiple docs pages, indicating a real programmatic interface beyond the UI. However, probes for a formal OpenAPI/swagger spec returned 404s, so there's no machine-readable API contract, only prose docs and SDK examples. Missing for 10: a published OpenAPI/spec artifact, independent third-party confirmation of API usage beyond vendor docs.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.browser-use.com/llms.txt # Browser Use > Documentation for Browser Use Cloud Agent and Browser API…”
Steel publishes a full OpenAPI spec (steel-probe-2), documented Sessions API with SDKs, and a CLI, all confirmed hands-on by a runtime probe showing session creation, health checks, and SDK usage working end-to-end. This is strong first-party documentation plus independent verification of a working public API. Missing for 10: no third-party community deep-dive validating API completeness beyond the probe.
- [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
- [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [probe] “official CLI documented at https://docs.steel.dev/overview/steel-cli”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
ai-native userIssue scoped/least-privilege API credentials for an agent
weight 2 · round drawnBrowser Usenone0/10No evidence of scoped or least-privilege API key/credential issuance (e.g., role-based tokens, permission scopes) for agents; docs mention API keys implicitly via client usage but no mention of scoping, restricted permissions, or credential management features. Community/GitHub evidence also silent on this.
ai-native userBuild against official SDKs
weight 2 · round to SteelBrowser Use ships an official open-source Python library (github, docs-19) and a cloud client SDK with documented usage patterns (client.runs.create, sessions, events polling) shown in docs-1/4/5/14, giving AI-native devs a concrete first-party SDK to build against. Missing for 10: evidence of SDKs beyond Python (e.g. JS/TS), and no OpenAPI spec was found (probe-2 all 404) or independent third-party corroboration of SDK usage.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “For a local agent, use the [open-source library](/open-source/quickstart).”
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”
Steel ships an official steel-sdk npm package (verified working via probe: exports a Steel client class), a documented OpenAPI spec, and an official CLI for full browser workflows, all covered in first-party docs and confirmed by a hands-on runtime probe. missing for 10: explicit multi-language SDK coverage (e.g., Python/other languages) and independent community confirmation of SDK usage beyond the CLI/API.
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
- [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
- [probe] “official CLI documented at https://docs.steel.dev/overview/steel-cli”
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [claimed-docs] “The Steel integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the browser.”
ai-native userSubscribe to events via webhooks
weight 2 · round drawnBrowser Usenone0/10The docs describe an event system based on polling `runs.events()` with a cursor, not webhook subscriptions; no evidence anywhere in the pack mentions webhooks, callback URLs, or push notifications.
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
Agentic features
ai-native userSet up automations that run autonomously in the background
weight 2 · round to Browser UseBrowser Use Cloud lets users kick off agent runs via API (client.runs.create) that execute asynchronously in a hosted browser, with session reuse and event polling to monitor progress without keeping a local process open, which supports a form of unattended background execution. However there is no documented scheduling, cron-like triggers, or webhook-based automation setup for recurring/background jobs, so it's unclear whether truly hands-off recurring automations are supported. Missing for 10: explicit scheduling/trigger mechanism, evidence of long-running unattended jobs beyond single API-invoked runs, and independent confirmation of background reliability.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
Steelnone0/10Steel provides on-demand browser sessions, CLI, SDK, and agent-trace tooling for agents to control browsers, but nothing in the evidence describes a scheduling/trigger mechanism or persistent background job runner that lets a user set up automations to run autonomously without invocation — sessions are explicitly spun up 'on demand' by an agent/script, not scheduled by Steel itself.
- [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
ai-native userOperate the product with natural-language commands
weight 2 · round to Browser UseBrowser Use is fundamentally natural-language driven: tasks are issued as plain-English strings like "Find the top Hacker News story" or "Fill in this job application with my resume and information", with the agent interpreting and executing them autonomously, corroborated by GitHub examples and community hands-on use for LinkedIn automation. missing for 10: independent benchmark of instruction-following accuracy, and clearer docs on limits/failure modes of natural-language parsing.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [github] “Task: "Fill in this job application with my resume and information."”
- [github] “Task: "Extract structured data about my followers and export it as a CSV."”
- [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
Steel exposes its browser control as MCP tools within agent SDKs (e.g., Claude Agent SDK) so an AI agent can translate natural-language user requests into Steel API calls, and the CLI/SDK/API allow full programmatic control — but there's no evidence of a native natural-language interface to Steel itself (e.g., a chat command layer); control still requires structured API/CLI calls or a separate agent framework. Missing for 10: a first-party NL command interface or chat-driven control surface, and independent confirmation that NL-driven agent use works end-to-end in production.
- [claimed-docs] “The Steel integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the browser.”
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
Api quality
ai-native userExplore an interactive API reference with runnable examples
weight 2 · round to SteelBrowser Usenone0/10Docs show static code snippets (e.g., client.runs.create examples) but no evidence of an interactive, runnable API console/reference; explicit probes for OpenAPI/Swagger specs at standard paths all returned 404, indicating no interactive API explorer exists.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.browser-use.com/llms.txt # Browser Use > Documentation for Browser Use Cloud Agent and Browser API…”
Steel publishes a full OpenAPI spec (docs.steel.dev/openapi.json) and an llms.txt, and a community commenter independently praised the docs/API reference quality, suggesting an interactive, well-documented API surface. However, there's no explicit evidence of an in-browser 'try it' / runnable-example console distinct from static docs. Missing for 10: direct confirmation of an interactive try-it console with live runnable code snippets, and independent hands-on verification of that specific feature.
- [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.steel.dev/llms.txt # Steel Documentation > Steel is the open-source browser API for AI agents — ma…”
- [community] “beautiful docs + api ref! what are you using? (cool that you're doing open-source browserbase also, excited to check this out)”
ai-native userDownload a machine-readable API spec (OpenAPI or equivalent)
weight 2 · round to SteelBrowser Usenone0/10A direct probe for OpenAPI/swagger spec files returned 404 on all candidate paths, and no documentation references a downloadable machine-readable API spec despite having a REST/cloud API.
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”
A probe confirms a live, valid OpenAPI JSON spec served at docs.steel.dev/openapi.json (HTTP 200 with 'openapi' key), directly satisfying the machine-readable spec requirement, complemented by an llms.txt index for discoverability. missing for 10: independent third-party corroboration beyond the automated probe.
ai-native userTest against a sandbox environment without touching production data
weight 1 · round to SteelBrowser Usenone0/10The evidence describes cloud browser sessions, live preview, and CDP connections, but nothing indicates a dedicated sandbox/staging mode that isolates test runs from production data or real accounts. Users are shown reusing real logged-in profiles (browser-use-comm-5) rather than isolated test environments, and no docs mention a sandbox distinct from production.
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [claimed-docs] “Log in once, save the profile, then reuse it to start future browsers already logged in.”
- [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
Steel's core Sessions API spins up isolated, on-demand browser instances each with their own state, cookies, and storage, and this isolation was independently verified via a self-hosted runtime probe that created a live, separate browser session from a throwaway Docker instance — effectively a sandbox with no shared production state. Missing for 10: explicit documentation framing sessions as a 'test vs production' environment, and no first-party guidance on staging/production data separation policies beyond session isolation.
- [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
- [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
- [github] “Pre-built Docker Image (combined API + UI)”
ai-native userRely on versioned APIs with a documented deprecation policy
weight 2 · round drawnBrowser Usenone0/10Evidence shows an API version label ("V4") in docs, but there is no documented deprecation policy, versioning changelog, or API stability guarantees anywhere in the pack; the OpenAPI spec probe also 404s, indicating no formal API contract is published.
- [claimed-docs] “V4 returns `run.result` as a string. Ask for JSON only, then validate it client-side”
- [claimed-docs] “Automatic CAPTCHA solving is enabled by default for API V4 Agent runs and standalone Cloud Browser sessions.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”
Auth session persistence — stories about auth session persistence in this arenaAuth session persistence
Stories about auth session persistence in this arena
Compat
developerConnect my existing Playwright, Puppeteer, or CDP automation code to the product's browsers instead of rewriting it
weight 2 · round to SteelDocs explicitly describe connecting existing Playwright/Puppeteer/CDP code to Browser Use's browsers via CDP URL, with a documented choice between Browser Use driving or the developer's own code connecting directly over CDP (docs-2, docs-18), and community reports confirm connecting to a real local Chrome profile via CDP for existing automation. missing for 10: independent hands-on validation specifically with Playwright/Puppeteer libraries (not just CDP raw), and more detail on session/auth persistence when using external code.
- [claimed-docs] “Launch a browser, connect to its CDP URL, then stop it”
- [claimed-docs] “Choose whether Browser Use drives the browser or your Playwright/Puppeteer code connects directly over CDP.”
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
Steel explicitly supports connecting existing Puppeteer, Playwright, or Selenium code via CDP to control its browser instances, and a runtime probe confirms live sessions expose websocket/debugger URLs consistent with CDP connectivity. Docs and SDK further corroborate first-class session management compatible with standard automation libraries. Missing for 10: independent third-party hands-on confirmation specifically of a rewritten Playwright/Puppeteer script running unmodified against Steel.
- [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
- [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
Credentials
automation-engineerStore credentials in a vault and have the agent complete logins including TOTP/2FA challenges without exposing secrets to the model
weight 2 · round to Browser UseBrowser Use supports saved/reused login profiles (docs-10) and a documented 2FA workflow where the run pauses at the challenge and a human enters the code via live view (docs-11/16), but there is no vault/secrets-manager integration for storing credentials and injecting them without model exposure, and TOTP is handled via human-in-the-loop rather than automated secret injection. missing for 10: a credential vault/secrets-manager integration, evidence that passwords/TOTP secrets are injected without ever passing through the model context, fully automated TOTP handling without human intervention, independent confirmation of the 2FA flow working in practice.
- [claimed-docs] “Log in once, save the profile, then reuse it to start future browsers already logged in.”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event]”
Steelnone0/10Steel's docs show session-level auth persistence (reusing cookies/storage across sessions) but no evidence of a credentials vault, secret injection without model exposure, or TOTP/2FA challenge automation — the core asks of this story are unaddressed.
- [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”
Profiles
developerPersist logged-in browser state in reusable profiles so agents skip the login wall on every subsequent run
weight 3 · round drawnDocs explicitly describe saving a login profile once and reusing it to start future browsers already logged in, plus a 2FA guide for handling the initial login flow, and community evidence confirms local profile reuse works for logged-in automation (e.g., LinkedIn). missing for 10: independent/hands-on corroboration specifically of the cloud profile-reuse feature (only local profile reuse is community-validated) and no detail on profile storage/security guarantees.
- [claimed-docs] “Log in once, save the profile, then reuse it to start future browsers already logged in.”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event]”
- [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
Steel docs explicitly document reusing auth context across sessions to let agents skip repeated logins, backed by session isolation, custom session IDs, and a real API/CLI/SDK confirmed via runtime probe. Missing for 10: independent third-party hands-on confirmation of the reuse-auth-context feature specifically (only vendor docs cite it) and no explicit profile-export/import UX details beyond the docs description.
- [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”
- [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
- [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
ai-native userPerform bulk operations across many items at once
weight 2 · round to SteelThe library is pitched for automating the web 'at scale' from custom code (gh-3) and cloud sessions can hold multiple runs, hinting at multi-task orchestration, but there is no explicit documentation of a batch/bulk API, parallel run submission, or looping over many items as a first-class feature. Missing for 10: dedicated bulk/batch endpoint or SDK pattern, concurrency limits/guidance, and hands-on evidence of running many items in one operation.
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
Steel's Sessions API allows spinning up isolated browser sessions on demand and reusing auth context across multiple sessions, which implies you could programmatically launch many sessions for parallel/bulk tasks, but there is no explicit documentation of a batch/bulk API, concurrency limits, or guidance for orchestrating many items at once. missing for 10: explicit bulk/batch API or documented pattern for running many operations concurrently, concurrency/rate limits, and independent evidence of large-scale parallel session usage.
- [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
- [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”
- [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
ai-native userDefine rules that trigger actions automatically on events
weight 3 · round drawnBrowser Usenone0/10Browser Use's evidence covers on-demand task runs, sessions, observability polling, CAPTCHA/stealth, and MCP integration, but nothing describes user-defined rules or triggers that fire actions automatically on external events (e.g., webhooks, schedules, conditional triggers). The product is presented as an agent you invoke to perform a task, not an event-driven automation/rules engine.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “Run browser automation tasks from your AI coding assistant. Connect to Claude, Cursor, Windsurf, or any MCP client.”
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
ai-native userSchedule recurring jobs or workflows
weight 2 · round drawnBrowser Usenone0/10The evidence pack covers runs, sessions, observability, stealth/proxy/CAPTCHA handling, auth profiles, and MCP integration, but nowhere mentions cron-like scheduling, recurring triggers, or workflow automation over time. No docs or community evidence describe a scheduler or recurring-job feature.
Deployment modes — stories about deployment modes in this arenaDeployment modes
Stories about deployment modes in this arena
Local
developerRun the agent against a local browser on my own machine for development, without any cloud account
weight 2 · round to SteelBrowser Use ships an open-source Python library explicitly positioned for local, code-driven automation ('For a local agent, use the open-source library'; 'automate the web at scale, from your own code, and with any LLM'), and community reports confirm running it locally against a real local Chrome browser/profile without a cloud account. missing for 10: no explicit walkthrough showing zero network/account calls during local runs, and no independent benchmark of purely offline/local operation.
- [claimed-docs] “For a local agent, use the [open-source library](/open-source/quickstart).”
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
- [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
- [claimed-docs] “Launch a browser, connect to its CDP URL, then stop it”
Steel Browser is open-source and can be self-hosted via Docker with no cloud account, confirmed by a runtime probe showing a local Docker container booting the browser API, creating live sessions, and working with the official CLI and SDK entirely locally. missing for 10: independent third-party (non-vendor) confirmation of long-term local dev workflow beyond the single recorded probe.
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
- [github] “Pre-built Docker Image (combined API + UI)”
- [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
- [probe] “official CLI documented at https://docs.steel.dev/overview/steel-cli”
Framework model support — stories about framework model support in this arenaFramework model support
Stories about framework model support in this arena
Frameworks
developerPlug the browser layer into agent frameworks (Claude Agent SDK, Vercel AI SDK, LangChain, CrewAI) through documented adapters
weight 2 · round to SteelBrowser Usenone0/10Evidence documents an MCP server for connecting to Claude, Cursor, or Windsurf, and a Python library for custom code, but there is no mention of documented adapters for Claude Agent SDK, Vercel AI SDK, LangChain, or CrewAI specifically.
- [claimed-docs] “Run browser automation tasks from your AI coding assistant. Connect to Claude, Cursor, Windsurf, or any MCP client.”
- [probe] “official MCP server documented at https://docs.browser-use.com/cloud/guides/mcp-server”
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
Steel documents a concrete integration with the Claude Agent SDK exposing its browser as in-process MCP tools (steel-docs-9), showing at least one first-party framework adapter exists. However, the evidence pack contains no documented adapters or integration guides for Vercel AI SDK, LangChain, or CrewAI, so the broader multi-framework claim is only partially substantiated. missing for 10: documented adapters for Vercel AI SDK, LangChain, and CrewAI, plus independent corroboration of any of these integrations working in practice.
- [claimed-docs] “The Steel integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the browser.”
Models
developerBring my own LLM provider — the framework is model-agnostic rather than locked to one vendor's models
weight 2 · round to Browser UseGitHub docs explicitly market the library as usable with any LLM ('Use the Python library ... with any LLM'), and independent community testing corroborates this by reporting successful use with Gemini models rather than being locked to one vendor. Missing for 10: a dedicated docs page enumerating specific supported providers/configuration examples and broader independent confirmation across multiple providers beyond Gemini.
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
- [community] “From the first glance, browser-use is compatible with more models, and has (much) more github stars. Coincidentally I played with it over th…”
Nl task execution — stories about nl task execution in this arenaNl task execution
Stories about nl task execution in this arena
Tasks
ai agentSubmit a browser task over a hosted HTTP API and receive the result by polling or webhook, without managing any browser myself
weight 2 · round to Browser UseDocs show a hosted Cloud API (client.runs.create) that creates runs, supports polling via runs.events() with cursors, and returns structured results without the caller managing browser infrastructure (stealth, proxies, CAPTCHA solving handled server-side). Missing for 10: no explicit webhook callback mechanism is documented (only polling is shown), and no public OpenAPI spec was found to confirm full REST surface.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [claimed-docs] “V4 returns `run.result` as a string. Ask for JSON only, then validate it client-side”
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
- [claimed-docs] “Every cloud browser session runs in a hardened Chromium fork with stealth enabled by default — no configuration needed.”
- [claimed-docs] “Residential proxies are enabled by default across 195+ countries.”
- [claimed-docs] “Every Browser Use Cloud browser enables automatic CAPTCHA solving.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”
Steelnone0/10Steel's docs describe a Sessions API that hands agents a raw, controllable browser (via CDP/Puppeteer/Playwright) plus a CLI for scripted step-by-step actions, but there is no evidence of a higher-level 'submit a task, poll or get a webhook for the result' abstraction — the agent still must drive the browser session itself rather than delegate a task and retrieve a finished output.
- [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
developerHand the product a natural-language goal and it completes a multi-step web task end to end — navigating, filling forms, and clicking through flows
weight 3 · round to Browser UseDocs and GitHub examples show natural-language goals (e.g., "Find the top Hacker News story", "Fill in this job application") driving an agent that navigates, logs in, handles 2FA/CAPTCHA, and completes multi-step flows end-to-end via both cloud API and open-source library; community reports corroborate real-world use (e.g., LinkedIn automation). Missing for 10: independent third-party benchmark of complex multi-step task success rates and more robust evidence of reliability at scale beyond anecdotal community reports.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [github] “Task: "Fill in this job application with my resume and information."”
- [github] “Task: "Extract structured data about my followers and export it as a CSV."”
- [claimed-docs] “Log in once, save the profile, then reuse it to start future browsers already logged in.”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
- [claimed-docs] “Every Browser Use Cloud browser enables automatic CAPTCHA solving.”
- [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
Steel provides the browser primitives (sessions, navigate/click/fill/extract via CLI or API, CDP control) that a multi-step web task requires, and its CLI/MCP integrations let external agent frameworks drive those actions from natural-language goals. However, Steel's own docs state the agent loop and NL reasoning are handled by the paired SDK (e.g., Claude Agent SDK), not by Steel itself — Steel 'handles the browser' while the SDK runs the reasoning loop, so Steel alone does not accept a raw NL goal and autonomously plan/execute it end to end. missing for 10: evidence of Steel natively parsing/planning from a raw NL instruction without an external agent/LLM orchestrating the steps, and independent hands-on proof of a full NL-driven multi-step flow completed unattended.
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [claimed-docs] “The Steel integration exposes a cloud browser as in-process MCP tools, so the SDK runs the agent loop and Steel handles the browser.”
- [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
Workflows
automation-engineerCompose repeatable multi-step workflows with loops, conditionals, and parameters instead of one-shot prompts
weight 2 · round drawnBrowser Usenone0/10Evidence shows Browser Use runs are essentially single natural-language task strings within a session/run model (create run, poll events, reuse session) with no documented constructs for loops, conditionals, or parameterized workflow templates; the Python library is described as scriptable but no workflow-composition API (branching, iteration, variables) is shown.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
Steelnone0/10Steel's docs describe browser session management, stealth, CLI scripting of sequential steps (create session → navigate → click/fill → extract → stop), and MCP tool exposure, but nothing in the evidence pack shows a workflow-composition layer with loops, conditionals, or parameterized branching — the CLI and SDK are linear step sequences, not a control-flow DSL. missing for 10: any documented loop/conditional constructs, parameterized workflow templates, or reusable multi-branch automation definitions.
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
- [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
ai-native userDo everything through the API that I can do in the UI
weight 2 · round drawnDocs show the API (client.runs.create, sessions, events polling, structured output, live_view_url for 2FA/CAPTCHA handoff, stealth/proxy defaults) mirrors most cloud UI capabilities, and there's an official MCP server for coding-agent access, suggesting broad but not explicitly confirmed feature parity with the dashboard/UI. However there's no discoverable OpenAPI/formal API spec (404s on all candidate paths) and no explicit vendor statement that 100% of UI functionality is API-reachable; missing for 10: a canonical API reference/OpenAPI spec, and explicit parity documentation confirming every UI action (e.g., live preview manual takeover) is independently scriptable via API rather than requiring the UI.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “If the challenge remains, open the [live preview](/cloud/browser/live-preview) for human control.”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
- [claimed-docs] “Run browser automation tasks from your AI coding assistant. Connect to Claude, Cursor, Windsurf, or any MCP client.”
- [probe] “PROBE openapi: all candidate paths 404 (https://docs.browser-use.com/openapi.json, https://docs.browser-use.com/swagger.json, https://docs.b…”
- [probe] “official MCP server documented at https://docs.browser-use.com/cloud/guides/mcp-server”
Steel is fundamentally API-first: the Sessions API, CAPTCHA/proxy/auth-reuse, human-in-the-loop debug URLs, agent traces, and even the CLI are all documented as thin wrappers over the same REST/OpenAPI surface (steel-docs-1..10, steel-probe-2, steel-probe-3), and the runtime probe confirms the API alone (no UI) can create/list live sessions end-to-end. However, there's no explicit evidence enumerating the dashboard/UI feature set and confirming 1:1 parity with the API — it's inferred rather than directly stated. Missing for 10: an explicit doc/comparison confirming every UI-only feature (e.g. dashboard analytics, trace viewer) is also exposed via API, and independent confirmation of full parity.
- [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
- [claimed-docs] “One flag covers detection, solving, and verification for the whole session”
- [claimed-docs] “This is particularly useful for maintaining authenticated states across multiple sessions, helping your AI agents access protected resources…”
- [claimed-docs] “Steel's debug URL feature allows you to implement human-in-the-loop workflows where users can directly interact with and control browser ses…”
- [claimed-docs] “It turns the run into a timeline of agent activity, so you can see what happened without scrubbing through the whole recording.”
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [probe] “PROBE openapi: HTTP 200 at https://docs.steel.dev/openapi.json — contains "openapi" key”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
ai-native userExport all of my data in open formats and leave
weight 3 · round to SteelBrowser Usenone0/10The evidence pack describes agent runs, sessions, CAPTCHA handling, and pricing, but nothing documents an account/data export feature (e.g., downloading all run history, sessions, or stored data in an open format) that would let a user leave the platform with their data intact; the open-source library allows self-hosting but that's a separate capability from exporting existing cloud account data.
Steel's agent-traces feature explicitly supports exporting run data as markdown, JSON, or a ZIP with markdown+screenshots (steel-docs-7), and the product itself is open-source and self-hostable (steel-gh-4, steel-probe-rt-1), meaning users are never locked into a proprietary cloud and can run/keep everything themselves. However, there's no documented comprehensive 'export all my data' capability covering sessions, auth contexts, or account-level data beyond traces. Missing for 10: a documented full-account data export/portability feature covering sessions, auth states, and configs, not just trace recordings.
- [claimed-docs] “Copy the run as markdown, download JSON, or grab a ZIP with markdown plus screenshots.”
- [github] “Pre-built Docker Image (combined API + UI)”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
ai-native userRead the product's source under an open license
weight 2 · round to SteelThe GitHub repo (browser-use/browser-use) and docs reference an 'open-source library' with a public quickstart, indicating the core Python library's source is publicly viewable, but no evidence explicitly states an open-source license (e.g., MIT/Apache) or shows license text. missing for 10: explicit license file/declaration, confirmation of license type, evidence of full source (vs. cloud API) being open.
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
- [claimed-docs] “For a local agent, use the [open-source library](/open-source/quickstart).”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.browser-use.com/llms.txt # Browser Use > Documentation for Browser Use Cloud Agent and Browser API…”
The product's llms.txt explicitly states 'Steel is the open-source browser API for AI agents,' there's a public GitHub repo (steel-dev/steel-browser) with feature docs, and a runtime probe confirms the self-hostable OSS image can be pulled and run via Docker — all consistent with source availability. However, no evidence pack item names or shows a specific OSS license (e.g., MIT/AGPL) or a LICENSE file, so the exact openness terms are unconfirmed. Missing for 10: explicit license file/type citation, independent confirmation of license terms.
- [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
- [github] “Pre-built Docker Image (combined API + UI)”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.steel.dev/llms.txt # Steel Documentation > Steel is the open-source browser API for AI agents — ma…”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
- [community] “beautiful docs + api ref! what are you using? (cool that you're doing open-source browserbase also, excited to check this out)”
ai-native userSelf-host the core product
weight 3 · round to SteelBrowser Use ships an open-source Python library (github.com/browser-use/browser-use) that runs locally and independently of the Cloud API, explicitly positioned as the option for self-hosted/local agents ("For a local agent, use the open-source library"), and community reports confirm running it locally connected to a real browser/profile. missing for 10: no first-party self-hosting guide covering infra/deployment (e.g. Docker, scaling), and no independent audit of parity between self-hosted and cloud feature sets (stealth, CAPTCHA solving, proxies are cloud-only per docs).
- [claimed-docs] “For a local agent, use the [open-source library](/open-source/quickstart).”
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
- [community] “If you run it locally, you can connect it to your real browser and user profile where you are already logged in. This works for me for Linke…”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.browser-use.com/llms.txt # Browser Use > Documentation for Browser Use Cloud Agent and Browser API…”
Steel is explicitly open-source with a pre-built Docker image (combined API + UI), and a runtime probe confirms a full keyless self-host roundtrip: docker-running the OSS image, health check succeeding, and creating/listing live browser sessions, corroborating vendor docs and GitHub claims.
- [github] “Pre-built Docker Image (combined API + UI)”
- [github] “Uses Puppeteer and CDP for complete control over Chrome instances -- allowing you to connect using Puppeteer, Playwright, or Selenium.”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
- [probe] “PROBE llms.txt: HTTP 200 at https://docs.steel.dev/llms.txt # Steel Documentation > Steel is the open-source browser API for AI agents — ma…”
Pricing limits — free-tier ceilings, usage caps, and rate limits before you have to payPricing limits
Free-tier ceilings, usage caps, and rate limits before you have to pay
Pricing
developerSee transparent per-task or per-browser-hour pricing and documented rate/concurrency limits before committing
weight 2 · round to Browser UsePricing page shows credits-based model ($5+ credits, no subscription, one-time $15 signup credit) but there is no documented per-task or per-browser-hour cost breakdown, and no documented rate/concurrency limits anywhere in the evidence. missing for 10: explicit per-task/per-browser-hour cost figures, documented rate limits, documented concurrency limits, any independent confirmation of pricing transparency.
- [claimed-docs] “One-time $15 credit for eligible Google, GitHub or Microsoft signups ... No card required”
- [claimed-docs] “Credits from $5. No subscription. No expiry.”
Steelnone0/10No first-party documentation in the evidence pack lays out per-task or per-browser-hour pricing or concurrency/rate limits; the only pricing-related evidence is a community report of inconsistency between the pricing page and docs pricing ($59 vs $99), which itself signals the opposite of transparent, dependable pricing rather than confirming it.
- [community] “Looking interesting, will definitely give it a go. Btw, there is inconsistency between pricing page and pricing on docs. Pricing page for de…”
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
ai-native userChoose where my data is stored (region/residency)
weight 2 · round to SteelBrowser Usenone0/10No evidence pack material addresses data residency, region selection, or storage location controls for cloud runs/sessions; the open-source library option avoids the cloud entirely but that's not the same as choosable region/residency within the product. missing for 10: any mention of data center regions, residency options, or storage location controls.
Steel offers a self-hostable open-source Docker image (steel-gh-4, steel-probe-rt-1) which lets users control where their data physically resides by hosting it themselves, but there is no explicit region/residency selection feature documented for the managed cloud offering. missing for 10: explicit region-selection UI/API for the managed cloud service, documentation on data residency guarantees or compliance certifications (e.g., GDPR/SOC2 region controls).
ai-native userPrevent my data from being used to train AI models
weight 3 · round drawnBrowser Usenone0/10No evidence in the pack addresses data usage for AI model training, opt-out policies, or privacy/data-retention commitments for Browser Use Cloud or the open-source library.
ai-native userControl data retention and deletion
weight 2 · round to SteelBrowser Usenone0/10No evidence of data retention controls, deletion APIs, or privacy/data-lifecycle policy documentation anywhere in the pack; only session/profile reuse and credit pricing are mentioned. missing for 10: retention policy documentation, data deletion API/UI, export/erasure controls, any privacy compliance statement.
Steel is open-source and self-hostable (steel-gh-4, steel-probe-rt-1), which gives users full control over where session data lives and how long it's retained, and session lifecycle docs show sessions can be created/stopped with custom IDs (steel-docs-10). However, there is no explicit documentation of a retention policy, data-deletion API, or GDPR-style controls for the managed cloud offering. Missing for 10: documented retention/deletion controls or policy for the hosted cloud service, explicit data-purge API, independent confirmation of retention behavior.
- [github] “Pre-built Docker Image (combined API + UI)”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
- [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
ai-native userOpt out of telemetry and usage tracking
weight 2 · round drawnBrowser Usenone0/10No evidence in the pack mentions telemetry, usage data collection, or any opt-out/privacy setting for Browser Use; the documentation and community items cover unrelated features like stealth browsing, CAPTCHA solving, and MCP integration.
Replay debugging — stories about replay debugging in this arenaReplay debugging
Stories about replay debugging in this arena
Live
automation-engineerWatch a session live and take human control mid-run when the agent gets stuck
weight 2 · round to SteelDocs describe a live_view_url/live preview that lets a human take control mid-run for cases like CAPTCHAs or 2FA, and events can be polled to monitor a run, which supports live-watch-and-intervene workflows. However, this is scoped to specific triggers (CAPTCHA/2FA) rather than a general 'agent gets stuck, operator takes over anytime' workflow, and there's no independent/hands-on evidence confirming smooth mid-run handoff in practice. missing for 10: general-purpose stuck-detection/handoff beyond CAPTCHA/2FA scenarios, independent hands-on confirmation of live takeover working reliably, clear UI/replay-debugging tooling details.
- [claimed-docs] “If the challenge remains, open the [live preview](/cloud/browser/live-preview) for human control.”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event]”
- [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
Steel's debug URL feature is explicitly documented for human-in-the-loop workflows enabling users to directly interact with and control a live browser session, and runtime proof confirms sessions expose a live debugger/websocket URL for real-time viewing/control. The agent-traces timeline feature complements this by letting engineers review what happened, though it's more post-hoc than live takeover. Missing for 10: explicit documentation of mid-run handoff back to the agent after human control, and independent/community corroboration of the human-in-the-loop debug feature specifically (vs. general product commentary).
- [claimed-docs] “Steel's debug URL feature allows you to implement human-in-the-loop workflows where users can directly interact with and control browser ses…”
- [claimed-docs] “It turns the run into a timeline of agent activity, so you can see what happened without scrubbing through the whole recording.”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
Replay
automation-engineerDebug a failed agent run from recorded replays — video, screenshots, step-by-step action timelines
weight 2 · round to SteelDocs describe an observability/events stream (runs.events()) for monitoring a run and a live_view_url for real-time human intervention, which could support building a step timeline, but there is no explicit mention of recorded video or screenshot capture for post-hoc replay debugging of failed runs. Missing for 10: documented video recording of sessions, screenshot capture per action, and a dedicated replay/timeline UI for past runs.
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event], and have the user enter the code. The…”
- [claimed-docs] “Ask the first run to stop at the 2FA screen, get its `live_view_url` from the [`browser.ready` event]”
Steel's Agent Traces feature explicitly turns a run into a timeline of agent activity with screenshots, and lets you export as markdown, JSON, or a ZIP with markdown+screenshots, directly matching the replay-debugging story for automation engineers. Missing for 10: explicit video recording/playback evidence and independent/hands-on corroboration of the traces UI beyond first-party docs.
- [claimed-docs] “It turns the run into a timeline of agent activity, so you can see what happened without scrubbing through the whole recording.”
- [claimed-docs] “Copy the run as markdown, download JSON, or grab a ZIP with markdown plus screenshots.”
- [claimed-docs] “Steel's debug URL feature allows you to implement human-in-the-loop workflows where users can directly interact with and control browser ses…”
Scale parallelism — running many jobs at once — concurrency, fleets, queueingScale parallelism
Running many jobs at once — concurrency, fleets, queueing
Fleets
automation-engineerRun a fleet of concurrent browser sessions with documented concurrency limits and programmatic session management
weight 2 · round to SteelDocs show programmatic session/run creation (client.runs.create, session IDs holding multiple runs) and event polling for observability, implying some ability to manage sessions programmatically, but there is no documented concurrency limit, no fleet/parallel-session guidance, and no scaling architecture described. missing for 10: documented concurrency limits, guidance/examples for running multiple concurrent sessions at scale, rate-limit or quota specs, and independent evidence of parallel session management working in practice.
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
- [github] “Want to automate the web at scale, from your own code, and with any LLM? Use the Python library”
Steel's Sessions API and CLI clearly support spinning up isolated on-demand browser sessions with custom session IDs, and a runtime probe confirms working session creation/listing via self-hosted API — solid programmatic session management. However, the evidence pack contains no documented concurrency limits, quotas, or fleet-scale guidance for running many sessions in parallel. Missing for 10: explicit documented concurrency/session limits, guidance or examples for orchestrating many simultaneous sessions, and independent corroboration of scale behavior.
- [claimed-docs] “the Sessions API lets your agents spin up isolated browser instances on demand. Each session maintains its own state, cookies, and storage”
- [claimed-docs] “Steel generates a session ID for you, but `create` also accepts one. Pass your own UUID when the ID has to exist before the browser does”
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
- [probe] “PROBE runtime (recorded 2026-09-04, see data/browser-agents/proofs/steel/): full keyless self-host roundtrip — `docker run ghcr.io/steel-dev…”
Lifecycle
developerGet webhook notifications when tasks and sessions finish instead of polling for status
weight 1 · round drawnBrowser Usenone0/10Docs explicitly describe polling patterns for run status (runs.events() with cursor, polling ordered V4 events) but no webhook or callback-based notification mechanism is mentioned anywhere in the evidence pack.
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”
Stealth captcha — stories about stealth captcha in this arenaStealth captcha
Stories about stealth captcha in this arena
Captcha
automation-engineerRely on a documented captcha stance — automatic solving, human fallback, or explicit non-support — instead of silent task failures
weight 2 · round drawnBrowser Use documents a clear captcha stance: automatic CAPTCHA solving is enabled by default for cloud Agent runs and standalone Cloud Browser sessions, with an explicit human-fallback path via the live preview if the challenge persists. This directly matches the story's requirement of a documented stance rather than silent failure. Missing for 10: independent/hands-on verification of captcha-solving success rates and explicit behavior/limits for the self-hosted open-source library (docs focus on Cloud).
- [claimed-docs] “Every Browser Use Cloud browser enables automatic CAPTCHA solving.”
- [claimed-docs] “If the challenge remains, open the [live preview](/cloud/browser/live-preview) for human control.”
- [claimed-docs] “Automatic CAPTCHA solving is enabled by default for API V4 Agent runs and standalone Cloud Browser sessions.”
Steel documents a single explicit flag covering captcha detection, solving, and verification for the whole session, plus a separate human-in-the-loop debug URL feature for manual takeover when needed — giving automation engineers a documented stance rather than silent failures. Missing for 10: independent/hands-on verification that automatic captcha solving actually succeeds on real-world captchas, and clearer documentation of failure/fallback behavior when auto-solve fails.
- [claimed-docs] “One flag covers detection, solving, and verification for the whole session”
- [claimed-docs] “Steel's debug URL feature allows you to implement human-in-the-loop workflows where users can directly interact with and control browser ses…”
Posture
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 drawnBrowser Usenone0/10The evidence pack documents stealth, proxy, and CAPTCHA-solving features in detail, but there is no published acceptable-use policy, terms of service, or anti-abuse statement governing what these stealth/automation features may or may not be used for; community discussion even raises security/abuse concerns without any vendor policy response cited.
Steelnone0/10The evidence pack documents Steel's stealth/captcha-solving, proxy, and CAPTCHA features extensively, but contains no published acceptable-use policy, terms of service, or anti-abuse statement governing what these stealth capabilities may be used for. No AUP, ToS, or anti-abuse page is cited or referenced anywhere in the docs, GitHub repo, or community discussion. Missing for 10: a published acceptable-use policy, anti-abuse/misuse guidelines, or ToS language specifically addressing stealth/captcha feature usage.
Stealth
automation-engineerEnable stealth fingerprinting and residential or geo-targeted proxies so legitimate automations aren't blocked as bots
weight 2 · round to SteelDocs explicitly state cloud browsers run in a hardened Chromium fork with stealth enabled by default and residential proxies across 195+ countries, directly matching the story's stealth+proxy ask, with automatic CAPTCHA solving as a complementary layer. Missing for 10: explicit control/documentation for selecting a specific geo-target rather than automatic 195+ country rotation, and independent/hands-on evidence confirming bot-detection evasion actually works in practice.
- [claimed-docs] “Every cloud browser session runs in a hardened Chromium fork with stealth enabled by default — no configuration needed.”
- [claimed-docs] “Residential proxies are enabled by default across 195+ countries.”
- [claimed-docs] “Every Browser Use Cloud browser enables automatic CAPTCHA solving.”
- [claimed-docs] “Automatic CAPTCHA solving is enabled by default for API V4 Agent runs and standalone Cloud Browser sessions.”
Steel's docs explicitly document stealth mode (single flag covering detection evasion, captcha solving, and verification) plus both Managed Residential Proxies and Bring-Your-Own-Proxy (BYOP) for geo-targeting, directly matching the story, and community comment confirms custom proxy support works in practice. Missing for 10: no independent/hands-on evidence quantifying bot-detection bypass success rates or geo-targeting granularity, and no first-party benchmark showing reduced block rates.
- [claimed-docs] “One flag covers detection, solving, and verification for the whole session”
- [claimed-docs] “Steel offers two powerful ways to use proxies: our built-in **Managed Residential Proxies** or connecting to your own proxy provider with ou…”
- [community] “It appears you can set your own proxies to not use their cloud.”
Structured extraction — stories about structured extraction in this arenaStructured extraction
Stories about structured extraction in this arena
Extraction
developerExtract typed, schema-validated data (Zod/Pydantic-style) from pages the agent visits, not just raw text
weight 3 · round to Browser UseDocs mention structured output but V4 returns `run.result` as a plain string with a recommendation to 'ask for JSON only, then validate it client-side' — there's no native Zod/Pydantic schema binding or first-party typed-schema extraction feature shown. This is a workaround rather than a built-in schema-validated extraction pipeline. missing for 10: no evidence of a documented schema/type-binding API (e.g., passing a Pydantic/Zod schema directly to the agent), no SDK-level validation helpers, no independent/hands-on confirmation that structured JSON output reliably conforms to a given schema.
- [claimed-docs] “V4 returns `run.result` as a string. Ask for JSON only, then validate it client-side”
- [github] “Task: "Extract structured data about my followers and export it as a CSV."”
Steelnone0/10Steel's docs/GitHub only show raw content extraction utilities (markdown, readability, screenshots, PDF conversion) and generic 'extract content' CLI commands, with no mention of Zod/Pydantic-style schema validation or typed structured outputs. The axis is fair for a browser-automation API since competitors offer schema-based extraction, but no evidence shows Steel provides this.
- [github] “Browser Tools: Exposes APIs to quick convert pages to markdown, readability, screenshots, or PDFs.”
- [claimed-docs] “The Steel CLI lets you run full browser workflows from the terminal, end-to-end. You can start a browser session, navigate pages, click/fill…”
Files
developerMy agent can download files from and upload files to the sites it operates, with the artifacts retrievable afterwards
weight 1 · round drawnBrowser Usenone0/10The evidence pack has no documentation of file upload/download handling or of artifacts being stored and retrievable after a run — GH task examples merely reference a resume being filled in and CSV export, but no confirmation these are handled as retrievable files via any API or session mechanism. Missing for 10: explicit file upload API/tooling, download/save-to-cloud-storage feature, and an artifact retrieval endpoint or docs section.
Steelnone0/10The evidence covers session artifacts (traces, screenshots, page-to-markdown conversion) and CLI-driven browser control, but nothing documents actual file upload to web forms or downloading files from a site with persistent artifact retrieval — a distinct capability from trace export.
Not comparable on these axes
ai-native userPlug MCP servers into this product so it can use their tools
weight 3 · not comparableBrowser Usen/aBrowser Use is itself an agent/automation product; evidence (browser-use-docs-12) shows it ships as an MCP *server* that other clients (Claude, Cursor, Windsurf) connect to, not as an MCP *client* that consumes external MCP servers' tools. Per the agent-role exception, this client-side 'plug in MCP servers' story is out of scope for a product that is itself an agent unless it explicitly runs as an MCP client, which no evidence shows.
- [claimed-docs] “Run browser automation tasks from your AI coding assistant. Connect to Claude, Cursor, Windsurf, or any MCP client.”
- [probe] “official MCP server documented at https://docs.browser-use.com/cloud/guides/mcp-server”
Steeln/aSteel is a cloud browser infrastructure/API product, not an agent or orchestrator that would consume external MCP servers' tools. The evidence shows the opposite direction — Steel itself is exposed as MCP tools to other agent frameworks (e.g., Claude Agent SDK) — meaning Steel plays the tool-provider role, not the MCP-client role this story describes.
- [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.”
ai-native userGet AI-generated insights and suggestions from my data inside the product
weight 2 · not comparableBrowser Use's agent can extract and return structured data/results from web tasks (e.g., extracting follower data to CSV, structured JSON output), which counts as AI-generated output from data it gathers, but there is no evidence of proactive 'insights and suggestions' generated from a user's own stored data inside a product dashboard — it's task-driven extraction, not analytics-style suggestion generation. missing for 10: dedicated insights/suggestions surface, evidence of proactive recommendations, analysis of user's own historical data corpus rather than ad-hoc scraped web data.
- [github] “Task: "Extract structured data about my followers and export it as a CSV."”
- [claimed-docs] “V4 returns `run.result` as a string. Ask for JSON only, then validate it client-side”
- [claimed-docs] “run = client.runs.create("Find the top Hacker News story")”
Steeln/aSteel is browser automation/session infrastructure for AI agents, not a product holding a user's own dataset to analyze; its agent-traces feature is a raw activity timeline/export, not AI-generated insights or suggestions over user data. This axis is a category mismatch for an infra API rather than a data/analytics product.
- [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.”
ai-native userDelegate tasks to a built-in AI assistant inside the product
weight 3 · not comparableBrowser Usen/aBrowser Use is itself an agent/automation product (the AI acting inside the browser), not a host application that delegates to a separate built-in assistant — this is the agent-role exception where the axis does not apply. It ships as a library/cloud API/MCP server for developers to build agents with, not as an end-user app containing an embedded assistant.
Steeln/aSteel is browser infrastructure/API tooling for AI agents (session management, stealth, proxies, CLI, MCP tool exposure) — it is consumed by external AI agents, not itself a product with a built-in AI assistant a user delegates tasks to. This story is a category error for an infrastructure/API product like Steel.
ai-native userVersion, review, and roll back my automations
weight 1 · not comparableBrowser Usenone0/10Browser Use documents runs, sessions, event polling, and observability, but there is no evidence of versioning automation definitions, reviewing changes, or rolling back to prior versions of a task/automation. Missing for 10: version history/diffing of automations, review/approval workflow, rollback mechanism.
- [claimed-docs] “A **session** holds the agent’s conversation and can reuse its live browser. One session ID can contain multiple runs.”
- [claimed-docs] “Poll `runs.events()` with the previous cursor to receive only new events”
- [claimed-docs] “Poll ordered V4 events to monitor a run or build a custom UI.”