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

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

   ⚑ flag

   Smooth—none0/10

   No evidence of caching resolved actions/generated code for deterministic, cheaper replay; docs mention persistent sessions (auth reuse), structured outputs, and cost efficiency via small models, but nothing about caching or replay of prior task executions to skip re-prompting the LLM. Missing for 10: any mention of action/result caching, replay mechanism, or cost/latency comparison for repeat runs.

   • [claimed-docs] “Log in once, then reuse that authentication for future tasks.”
   • [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] “Smooth uses small and efficient AI models, making it 7x more affordable than browser-use.”

   proof ↗⚑ flag

Dom

1. developerDrive the page through DOM-understanding action primitives (act/click/type on described elements) that survive selector and layout changes

   weight 3 · round to Browser Use
   Browser Use~partialcommunity6/10

   Browser 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")”

   proof ↗⚑ flag

   Smooth~partialcommunity5/10

   Smooth's docs describe a 'Session Workflow' that lets you orchestrate smaller tasks, navigate to URLs, and extract data within a persistent session, and the whole product is framed as an AI browser agent that understands pages rather than relying on brittle selectors (smooth-docs-7, smooth-gh-1). However, there is no explicit documentation of discrete act/click/type primitives on described elements, nor any evidence/testing showing these survive selector or layout changes — community comments even note it doesn't fully close the gap versus Playwright-style tools (smooth-comm-8). Missing for 10: explicit act/click/type API reference, documented resilience testing against DOM/selector changes, independent verification of robustness claims.

   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”
   • [github] “The Smooth CLI is a browser for AI agents, enabling tools like Claude Code to navigate the web quickly, cheaply, and reliably.”
   • [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
   Browser Use—none0/10

   Evidence 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]”

   proof ↗⚑ flag

   Smooth—none0/10

   Smooth's docs describe live viewing of actions as they execute (live_url) and data extraction, but there is no evidence of a distinct observe/plan step that lets a developer preview candidate actions before committing the agent to act.

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

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

   ⚑ flag

   Smooth—none0/10

   The evidence pack covers Smooth's session workflows, extraction, custom tools, proxies, and CAPTCHA solving, but nowhere mentions a vision/computer-use mode operating on screenshots for canvases or non-DOM UI elements. This axis is plausible for a browser-automation agent, but no documentation or community report confirms such a capability exists.

   • [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] “Extract structured data from the current page by providing a schema.”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool.”
   • [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
   Browser Use✓fullprobed8/10

   Browser 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…”

   proof ↗⚑ flag

   Smooth✓fullprobed8/10

   A direct probe confirms docs.smooth.sh/llms.txt returns HTTP 200 with a structured index of docs pages, and the docs themselves are mirrored as .md files (e.g. live-share.md, proxies.md) enabling agent-friendly consumption. One community comment notes the docs pages aren't fully token-efficient, a minor caveat. Missing for 10: independent verification that agents actually consume llms.txt effectively, and no evidence of additional agent-specific doc formats beyond the single llms.txt file.

   • [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] “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.”
   • [community] “Ironically, the landing page and docs pages of Smooth aren't all that token-efficient!”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Browser Use~partialclaimed6/10

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

   proof ↗⚑ flag

   Smooth~partialprobed6/10

   Smooth is explicitly designed as an SDK/API and CLI for programmatic browser automation, with 'plug-and-play' 4-line-of-code task execution and custom tools/session workflows suited to unattended automation, and a documented CLI (smooth-gh-1, smooth-docs-1, smooth-probe-3). However there is no explicit documentation or example of running it inside a CI pipeline (e.g., GitHub Actions), headless flags, or exit-code/automation-specific guidance. Missing for 10: explicit CI/CD integration docs or examples, confirmation of non-interactive/headless auth flow for pipelines, independent confirmation of CI usage.

   • [claimed-docs] “Plug-and-play: Run a task in just 4 lines of code, making it easy to integrate into your workflow.”
   • [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”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool.”
   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”

   proof ↗⚑ flag

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

   weight 3 · round to Browser Use
   Browser Use!disputedcontradicted5/10

   Docs 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…”

   proof ↗⚑ flag

   Smooth—none0/10

   Smooth is a browser-automation SDK/CLI used by agents like Claude Code, but the evidence pack contains no mention of an official MCP server or MCP protocol integration anywhere in its docs, GitHub repo, or community discussion — only generic SDK/CLI methods and custom tool functions are documented.

   • [github] “The Smooth CLI is a browser for AI agents, enabling tools like Claude Code to navigate the web quickly, cheaply, and reliably.”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.smooth.sh/llms.txt # Smooth ## Docs - [Introduction](https://docs.smooth.sh/index.md): Welcome to…”
   • [probe] “official CLI documented at https://docs.smooth.sh/cli/overview”

   proof ↗⚑ flag

4. ai-native userUse an official CLI

   weight 2 · round to Smooth
   Browser Use—none0/10

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

   ⚑ flag

   Smooth✓fullprobed7/10

   GitHub repo describes Smooth CLI explicitly as 'a browser for AI agents, enabling tools like Claude Code to navigate the web' and a docs probe confirms an official CLI overview page exists, showing a first-party CLI built for AI-agent workflows. Missing for 10: independent hands-on confirmation of the CLI's usage/reliability and more detailed CLI documentation content beyond the overview link.

   • [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 Browser Use
   Browser Use~partialprobed7/10

   Browser 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…”

   proof ↗⚑ flag

   Smooth~partialprobed6/10

   Smooth provides documented SDK/API methods (task execution, session workflows, structured outputs, custom tools, proxies) and an llms.txt docs index plus a CLI, showing a documented programmatic interface for AI-native use. However, no formal OpenAPI/REST spec was found (404s on all standard paths), and there is no independent corroboration of API robustness beyond vendor docs. missing for 10: a discoverable OpenAPI/REST spec, independent/hands-on verification of API completeness and stability.

   • [claimed-docs] “Plug-and-play: Run a task in just 4 lines of code, making it easy to integrate into your workflow.”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool.”
   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.smooth.sh/llms.txt # Smooth ## Docs - [Introduction](https://docs.smooth.sh/index.md): Welcome to…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.smooth.sh/openapi.json, https://docs.smooth.sh/swagger.json, https://docs.smooth.sh/api…”
   • [probe] “official CLI documented at https://docs.smooth.sh/cli/overview”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Browser Use—none0/10

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

   ⚑ flag

   Smooth—none0/10

   No evidence of scoped or least-privilege API credential issuance, API key scoping, or permission management for agents; docs cover task execution, sessions, proxies, and privacy features but nothing about credential scoping. missing for 10: scoped API key/token generation, permission/role controls, credential revocation or least-privilege access management.

   ⚑ flag

7. ai-native userBuild against official SDKs

   weight 2 · round to Browser Use
   Browser Use✓fullprobed7/10

   Browser 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…”

   proof ↗⚑ flag

   Smooth~partialprobed6/10

   Smooth documents SDK-style integration (4-line task execution, custom tools, structured outputs, session workflows) and a CLI positioned as "a browser for AI agents" usable with tools like Claude Code, indicating official first-party SDK/CLI support for AI-native workflows. However, there is no OpenAPI spec, no evidence of multi-language SDKs, and no independent/hands-on confirmation of SDK reliability beyond docs and a GitHub repo. missing for 10: OpenAPI/API spec availability, multi-language SDK coverage, independent developer corroboration of SDK usage/quality.

   • [claimed-docs] “Plug-and-play: Run a task in just 4 lines of code, making it easy to integrate into your workflow.”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool.”
   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”
   • [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”
   • [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

8. ai-native userSubscribe to events via webhooks

   weight 2 · round drawn
   Browser Use—none0/10

   The 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.”

   proof ↗⚑ flag

   Smooth—none0/10

   No evidence pack item mentions webhooks or event subscriptions; Smooth's documented features (live_url, structured outputs, custom tools, sessions) do not include a webhook/event notification mechanism.

   ⚑ flag

Agentic features

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

   weight 2 · round drawn
   Browser Use~partialclaimed5/10

   Browser 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.”

   proof ↗⚑ flag

   Smooth~partialclaimed5/10

   Smooth lets users kick off browser-agent tasks programmatically that run autonomously (navigating, extracting data, solving CAPTCHAs) and provides a live_url to monitor progress, which supports hands-off execution once started. However there's no evidence of scheduling, triggers, webhooks, or persistent 'set it and forget it' background jobs that run without an explicit API call — the model shown is synchronous task invocation, not autonomous background automation setup. Missing for 10: scheduling/cron or event-trigger support, evidence of long-running unattended jobs, and independent confirmation of background execution beyond a single task call.

   • [claimed-docs] “Plug-and-play: Run a task in just 4 lines of code, making it easy to integrate into your workflow.”
   • [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] “Auto-CAPTCHA solvers: Bypass CAPTCHA challenges automatically, allowing for uninterrupted task execution.”

   proof ↗⚑ flag

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

   weight 2 · round to Browser Use
   Browser Use✓fullcommunity8/10

   Browser 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…”

   proof ↗⚑ flag

   Smooth~partialclaimed6/10

   Smooth's core interaction model is task-based: you give it a task description that an agent executes in a browser (session workflow, extract, navigate), and it is explicitly positioned as "a browser for AI agents" usable by tools like Claude Code, implying natural-language task instructions. However, no evidence shows an explicit example of a natural-language prompt/command syntax or confirms this is exposed to end-users beyond agent-to-agent orchestration. Missing for 10: explicit example of a natural-language task string/command, confirmation of human-facing NL command interface, independent corroboration of NL usability.

   • [claimed-docs] “Plug-and-play: Run a task in just 4 lines of code, making it easy to integrate into your workflow.”
   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”
   • [github] “The Smooth CLI is a browser for AI agents, enabling tools like Claude Code to navigate the web quickly, cheaply, and reliably.”
   • [claimed-docs] “Extract structured data from the current page by providing a schema.”

   proof ↗⚑ flag

Api quality

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

   weight 2 · round drawn
   Browser Use—none0/10

   Docs 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…”

   proof ↗⚑ flag

   Smooth—none0/10

   The evidence pack shows only static markdown docs (llms.txt, feature pages) and explicitly shows the openapi.json/swagger endpoints returning 404, indicating no interactive API reference or runnable-example playground exists. No mention of a Swagger UI, Postman collection, or in-browser code runner is present anywhere in docs or community discussion.

   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.smooth.sh/llms.txt # Smooth ## Docs - [Introduction](https://docs.smooth.sh/index.md): Welcome to…”
   • [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 drawn
   Browser Use—none0/10

   A 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…”

   proof ↗⚑ flag

   Smooth—none0/10

   A direct probe for OpenAPI/Swagger spec files at all standard paths returned 404, and no docs page references a downloadable machine-readable API spec; only an llms.txt (docs index) is available.

   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.smooth.sh/openapi.json, https://docs.smooth.sh/swagger.json, https://docs.smooth.sh/api…”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.smooth.sh/llms.txt # Smooth ## Docs - [Introduction](https://docs.smooth.sh/index.md): Welcome to…”

   proof ↗⚑ flag

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

   weight 1 · round drawn
   Browser Use—none0/10

   The 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…”

   proof ↗⚑ flag

   Smooth—none0/10

   Smooth's docs describe browser-automation features (live sessions, proxies, persistent auth, structured outputs) but nowhere mention a sandbox/staging mode or any mechanism to isolate test runs from production data or accounts. Community feedback even flags unresolved concerns about data handling and security, but no concrete sandbox capability is described or corroborated.

   ⚑ flag

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

   weight 2 · round drawn
   Browser Use—none0/10

   Evidence 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…”

   proof ↗⚑ flag

   Smooth—none0/10

   No evidence of API versioning scheme or a documented deprecation policy; OpenAPI spec probe returned 404s and docs show no changelog/versioning references. missing for 10: versioned API scheme, deprecation policy documentation, changelog/migration guides.

   • [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 Browser Use
   Browser Use✓fullcommunity7/10

   Docs 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…”

   proof ↗⚑ flag

   Smooth—none0/10

   Smooth's docs describe its own SDK/task API (structured outputs, sessions, custom tools) but there is no mention of a CDP endpoint, Playwright/Puppeteer connect() compatibility, or any way to point existing automation code at Smooth's browsers; one commenter even notes 'agent-browser helped a lot over playwright but doesn't completely close the gap,' underscoring the absence of such interoperability. Missing for 10: any CDP/WebSocket endpoint, official Playwright/Puppeteer connect examples, or documented browser-endpoint compatibility.

   • [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] “Set to `"self"` to create a P2P tunnel through your machine, routing traffic via your IP and enabling access to localhost.”
   • [community] “agent-browser helped a lot over playwright but doesn't completely close the gap.”

   proof ↗⚑ flag

Credentials

1. automation-engineerStore credentials in a vault and have the agent complete logins including TOTP/2FA challenges without exposing secrets to the model

   weight 2 · round to Browser Use
   Browser Use~partialclaimed5/10

   Browser 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]”

   proof ↗⚑ flag

   Smooth—none0/10

   The docs describe persistent sessions (log in once, reuse authentication) but there is no mention of a credential vault, secret injection to avoid model exposure, or TOTP/2FA handling anywhere in the evidence pack. This axis clearly applies to a browser-automation agent product, but no capability matching the story is documented.

   • [claimed-docs] “Log in once, then reuse that authentication for future tasks.”

   proof ↗⚑ flag

Profiles

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

   weight 3 · round to Browser Use
   Browser Use✓fullcommunity8/10

   Docs 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…”

   proof ↗⚑ flag

   Smooth✓fullclaimed7/10

   Smooth's docs explicitly describe a persistent-sessions feature ('Log in once, then reuse that authentication for future tasks') and a session workflow that maintains a persistent browser session across multi-step tasks, directly matching the story. However, there is no independent/hands-on corroboration of this specific feature working reliably, and no detail on profile management (multiple reusable profiles, storage/export). Missing for 10: independent verification of session persistence in practice, documentation on managing multiple reusable profiles.

   • [claimed-docs] “Log in once, then reuse that authentication for future tasks.”
   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”

   proof ↗⚑ flag

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

   weight 2 · round to Browser Use
   Browser Use~partialclaimed3/10

   The 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")”

   proof ↗⚑ flag

   Smooth—none0/10

   Smooth's docs describe single-task execution, session workflows, and structured extraction, but nothing about running/orchestrating bulk operations across many items (e.g., batch task queues, parallel task fan-out) is documented or mentioned by users.

   • [claimed-docs] “Plug-and-play: Run a task in just 4 lines of code, making it easy to integrate into your workflow.”
   • [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] “Extract structured data from the current page by providing a schema.”

   proof ↗⚑ flag

2. ai-native userSchedule recurring jobs or workflows

   weight 2 · round drawn
   Browser Use—none0/10

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

   ⚑ flag

   Smooth—none0/10

   No evidence of scheduling, cron-like triggers, or recurring workflow orchestration; Smooth is documented as a task-execution/browser-automation tool (session workflows, extraction, structured output) with no mention of recurring/scheduled jobs. Missing for 10: any scheduling API, cron/trigger mechanism, or recurring workflow docs.

   • [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] “Plug-and-play: Run a task in just 4 lines of code, making it easy to integrate into your workflow.”

   proof ↗⚑ flag

Local

1. developerRun the agent against a local browser on my own machine for development, without any cloud account

   weight 2 · round to Browser Use
   Browser Use✓fullcommunity8/10

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

   proof ↗⚑ flag

   Smooth—none0/10

   Smooth is documented as a cloud-hosted browser agent service (task execution via live_url, proxies, zero-data-retention as an 'enterprise' add-on), with no docs describing a local-browser/offline mode; a P2P tunnel feature only lets the cloud agent reach your localhost, not run without an account. Community feedback explicitly asks for self-hosting ('Make it self-hostable, the conversation can change'), confirming no local/no-account mode 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] “Set to `"self"` to create a P2P tunnel through your machine, routing traffic via your IP and enabling access to localhost.”
   • [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

Frameworks

1. developerPlug the browser layer into agent frameworks (Claude Agent SDK, Vercel AI SDK, LangChain, CrewAI) through documented adapters

   weight 2 · round drawn
   Browser Use—none0/10

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

   proof ↗⚑ flag

   Smooth—none0/10

   Evidence shows Smooth positions itself as a browser tool usable by agents like Claude Code, but there is no documentation of adapters for Claude Agent SDK, Vercel AI SDK, LangChain, or CrewAI specifically. Missing for 10: any documented integration guide or adapter package for these named frameworks.

   • [github] “The Smooth CLI is a browser for AI agents, enabling tools like Claude Code to navigate the web quickly, cheaply, and reliably.”
   • [claimed-docs] “Custom tools allow you to give Smooth any arbitrary function as a tool.”

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

   GitHub 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…”

   proof ↗⚑ flag

   Smooth—none0/10

   Smooth's docs describe it as using its own internal 'small and efficient AI models' for browser-agent tasks, and none of the documentation, CLI, or API references mention any mechanism for developers to configure or swap in their own LLM provider (e.g., OpenAI, Anthropic, custom model endpoints). This suggests the opposite of model-agnosticism — the models are an implementation detail of the service, not a pluggable choice.

   • [claimed-docs] “Smooth uses small and efficient AI models, making it 7x more affordable than browser-use.”
   • [github] “The Smooth CLI is a browser for AI agents, enabling tools like Claude Code to navigate the web quickly, cheaply, and reliably.”
   • [probe] “PROBE llms.txt: HTTP 200 at https://docs.smooth.sh/llms.txt # Smooth ## Docs - [Introduction](https://docs.smooth.sh/index.md): Welcome to…”

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

   Docs 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…”

   proof ↗⚑ flag

   Smooth~partialprobed5/10

   Docs confirm a hosted task-submission model (4-line integration, live_url for tracking, persistent sessions, structured outputs) consistent with an agent submitting tasks without managing a browser, but no evidence pack item explicitly documents a polling endpoint or webhook delivery mechanism, and probes found no public OpenAPI/REST spec. missing for 10: explicit polling endpoint docs, explicit webhook/callback docs, confirmed REST API schema (openapi probe 404s).

   • [claimed-docs] “Plug-and-play: Run a task in just 4 lines of code, making it easy to integrate into your workflow.”
   • [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…”
   • [probe] “PROBE openapi: all candidate paths 404 (https://docs.smooth.sh/openapi.json, https://docs.smooth.sh/swagger.json, https://docs.smooth.sh/api…”
   • [probe] “official CLI documented at https://docs.smooth.sh/cli/overview”

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

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

   proof ↗⚑ flag

   Smooth✓fullcommunity7/10

   Docs describe exactly this capability: multi-step 'Session Workflow' that navigates URLs, orchestrates sub-tasks, and extracts data, plus a live_url to watch the agent act, and a community commenter confirms 'I just wrote a complex prompt and it did a good job.' This matches the natural-language, end-to-end web task story well. Missing for 10: independently reproducible benchmarks/evals (a commenter explicitly asks for third-party reproducible comparisons and gets no clear answer), and broader hands-on validation beyond a single anecdote.

   • [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] “Extract structured data from the current page by providing a schema.”
   • [claimed-docs] “When running a task, you will receive a `live_url`, which can be used to view the agent actions live.”
   • [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
   Browser Use—none0/10

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

   proof ↗⚑ flag

   Smooth~partialclaimed4/10

   Smooth documents a 'Session Workflow' method for multi-step execution—orchestrating smaller tasks, navigating URLs, and extracting data within a persistent browser session—plus structured outputs and custom tools that let developers build deterministic logic around agent calls. However, there is no explicit documentation of native loop/conditional constructs or parameterized workflow templates; any control flow would rely on the surrounding SDK code rather than a built-in workflow engine. Missing for 10: explicit loop/conditional primitives, parameterization/templating of workflows, and independent evidence of repeatable multi-step automations beyond simple session chaining.

   • [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] “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.”

   proof ↗⚑ flag

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

   weight 2 · round to Browser Use
   Browser Use~partialprobed6/10

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

   proof ↗⚑ flag

   Smooth—none0/10

   The evidence pack shows Smooth as an API/CLI/SDK-first browser-automation tool with docs for tasks, sessions, proxies, custom tools, and a live_url for viewing agent actions, but there is no mention of a separate web dashboard/UI or any comparison of UI-only vs API-only capabilities. Without evidence of what a UI offers (or that all UI features are mirrored in the API), the parity claim can't be substantiated. Missing for 10: any documented web UI/dashboard, and an explicit statement or demonstration that all UI actions are also achievable via API.

   • [claimed-docs] “Plug-and-play: Run a task in just 4 lines of code, making it easy to integrate into your workflow.”
   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”
   • [probe] “official CLI documented at https://docs.smooth.sh/cli/overview”

   proof ↗⚑ flag

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

   weight 3 · round drawn
   Browser Use—none0/10

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

   ⚑ flag

   Smooth—none0/10

   Smooth's docs mention Zero Data Retention (deletion of task data) but there is no evidence of a bulk data export feature or open-format export for users to take their data and leave — the closest related item is deletion, not portability. missing for 10: any documented export mechanism, open format specification, or user data portability tooling.

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

   proof ↗⚑ flag

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

   weight 2 · round to Browser Use
   Browser Use~partialprobed5/10

   The 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…”

   proof ↗⚑ flag

   Smooth—none0/10

   Smooth ships a GitHub repo for its SDK/CLI, but there is no evidence of an open-source license for the core product, and community comments explicitly request self-hosting/open-source alternatives ('Make it self-hostable, the conversation can change', 'I'll wait for a free/open source browser'), implying the core service is closed.

   • [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 Browser Use
   Browser Use✓fullprobed7/10

   Browser 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…”

   proof ↗⚑ flag

   Smooth—none0/10

   Smooth is offered only as a hosted cloud API/SaaS with no documented self-host option, and community feedback explicitly requests self-hosting as a missing capability ('Make it self-hostable, the conversation can change').

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

Pricing

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

   weight 2 · round to Browser Use
   Browser Use~partialclaimed4/10

   Pricing 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.”

   proof ↗⚑ flag

   Smooth—none0/10

   No evidence of documented per-task/per-browser-hour pricing tiers or rate/concurrency limits; only a vague claim of being '7x more affordable' with no actual pricing page or limits documented, and community comments call it 'too expensive' without citing specifics.

   • [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.”
   • [community] “I'm paying a fixed amount on Claude and other agents, so 'more tokens' is 'free' for me. There's a lot of niche tools out there but I think …”

   proof ↗⚑ flag

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

   weight 2 · round drawn
   Browser Use—none0/10

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

   ⚑ flag

   Smooth—none0/10

   No evidence of data residency/region selection options; only Zero Data Retention (deletion) is mentioned, which is a different capability. Missing for 10: any mention of region choice, data center locations, or residency controls.

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

   proof ↗⚑ flag

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

   weight 3 · round to Smooth
   Browser Use—none0/10

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

   ⚑ flag

   Smooth~partialcommunity4/10

   Smooth documents a 'Zero Data Retention' enterprise feature that lets customers delete all data tied to completed tasks, which is adjacent to preventing data reuse, but there is no explicit statement that data is excluded from model training, and this feature is gated to enterprise tier. Community feedback also notes an absence of any detailed security/privacy documentation despite marketing claims of 'enterprise-grade security', raising trust concerns without disputing the ZDR feature itself. missing for 10: explicit AI-training opt-out policy, default (non-enterprise) privacy guarantees, independent verification of data handling.

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

3. ai-native userControl data retention and deletion

   weight 2 · round to Smooth
   Browser Use—none0/10

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

   ⚑ flag

   Smooth~partialcommunity5/10

   Docs confirm a 'Zero Data Retention' feature letting customers delete all data tied to completed tasks, directly addressing retention/deletion control, but it's explicitly gated as an 'enterprise feature' rather than a universal capability, and no detail is given on default retention periods, deletion APIs/CLI commands, or granular controls for non-enterprise users. Community feedback (e.g., concerns about sending data to a third party, no security details found) shows some skepticism but doesn't concretely contradict the ZDR claim itself. missing for 10: default/non-enterprise retention policy, self-serve deletion mechanism (API/CLI), independent verification of ZDR working in practice.

   • [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
   Browser Use—none0/10

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

   ⚑ flag

   Smooth—none0/10

   No evidence describes a telemetry/usage-tracking opt-out control; the only related privacy feature is 'Zero Data Retention' for enterprise customers, which addresses data deletion after tasks rather than disabling telemetry/tracking. Community comments raise general privacy/security concerns but do not confirm or deny an opt-out mechanism.

   • [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 Browser Use
   Browser Use~partialclaimed6/10

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

   proof ↗⚑ flag

   Smooth~partialclaimed4/10

   Docs confirm a live_url to watch agent actions in real time (smooth-docs-2), satisfying the 'watch a session live' half of the story, but there is no evidence of any mechanism for a human to intervene or take control mid-run when the agent gets stuck. missing for 10: documented human-takeover/control API or UI, evidence of pausing/resuming agent execution, hands-on confirmation of mid-run intervention.

   • [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…”

   proof ↗⚑ flag

Replay

1. automation-engineerDebug a failed agent run from recorded replays — video, screenshots, step-by-step action timelines

   weight 2 · round to Browser Use
   Browser Use~partialclaimed4/10

   Docs 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]”

   proof ↗⚑ flag

   Smooth~partialclaimed3/10

   Docs mention a `live_url` for viewing agent actions live during a run, but there is no evidence of persisted video recordings, screenshots, or a step-by-step action timeline that can be replayed after a run has finished and failed. Missing for 10: recorded video/screenshot artifacts, post-hoc replay viewer, structured action timeline, and any independent confirmation of replay-based debugging.

   • [claimed-docs] “When running a task, you will receive a `live_url`, which can be used to view the agent actions live.”

   proof ↗⚑ flag

Fleets

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

   weight 2 · round to Browser Use
   Browser Use~partialclaimed4/10

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

   proof ↗⚑ flag

   Smooth—none0/10

   The evidence pack covers single-session features (persistent sessions, live URL, proxies, structured output) but contains no documentation of concurrency limits, fleet/pool management, or APIs for running many sessions in parallel. Missing for 10: documented concurrency limits, fleet/pool orchestration APIs, rate-limit or scaling guidance, evidence of parallel session usage.

   • [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] “Log in once, then reuse that authentication for future tasks.”
   • [claimed-docs] “When running a task, you will receive a `live_url`, which can be used to view the agent actions live.”

   proof ↗⚑ flag

Lifecycle

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

   weight 1 · round drawn
   Browser Use—none0/10

   Docs 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.”

   proof ↗⚑ flag

   Smooth—none0/10

   No evidence pack item mentions webhooks, callback URLs, or event-driven notifications for task/session completion; the docs describe live_url viewing, structured outputs, and session workflows but nothing about push notifications versus polling.

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

   Browser 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.”

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

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

   ⚑ flag

   Smooth—none0/10

   No evidence anywhere in the pack of a published acceptable-use policy, anti-abuse terms, or guidance on permissible use of the stealth/CAPTCHA-bypass and automation features; docs only describe how to use auto-CAPTCHA and proxy features, not what usage is disallowed. Community commentary even calls out the lack of any such framing (e.g., accusing the marketing of enabling spambots), reinforcing the absence rather than disputing a claim.

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

Stealth

1. automation-engineerEnable stealth fingerprinting and residential or geo-targeted proxies so legitimate automations aren't blocked as bots

   weight 2 · round to Browser Use
   Browser Use✓fullclaimed7/10

   Docs 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.”

   proof ↗⚑ flag

   Smooth~partialcommunity5/10

   Docs confirm auto-CAPTCHA solving and configurable proxy server parameters plus persistent authenticated sessions, which support anti-bot automation goals, but there is no explicit mention of residential/geo-targeted proxy pools or stealth browser fingerprinting techniques. Missing for 10: explicit residential/geo-targeted proxy options, stealth fingerprinting details, and independent verification that bot-detection evasion actually works in practice.

   • [claimed-docs] “To use a proxy with Smooth, you need to specify the proxy server details in your task parameters.”
   • [claimed-docs] “Auto-CAPTCHA solvers: Bypass CAPTCHA challenges automatically, allowing for uninterrupted task execution.”
   • [claimed-docs] “Log in once, then reuse that authentication for future tasks.”
   • [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
   Browser Use~partialclaimed4/10

   Docs 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."”

   proof ↗⚑ flag

   Smooth✓fullclaimed8/10

   Docs explicitly describe structured outputs via `response_model` for deterministic typed data and a dedicated `session-extract` method to extract structured data from a page by providing a schema, directly matching the story. Missing for 10: explicit Zod/Pydantic code examples and independent/hands-on confirmation that extraction validation works as documented.

   • [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] “Extract structured data from the current page by providing a schema.”
   • [claimed-docs] “Session Workflow — Multi-step execution where you can orchestrate smaller tasks, navigate to URLs, and extract data within a persistent brow…”

   proof ↗⚑ flag

Files

1. developerMy agent can download files from and upload files to the sites it operates, with the artifacts retrievable afterwards

   weight 1 · round drawn
   Browser Use—none0/10

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

   • [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."”

   proof ↗⚑ flag

   Smooth—none0/10

   The evidence pack describes Smooth's session workflows, structured extraction, live-view, proxies, and persistent auth, but nothing addresses file download/upload during a browser session or persisting artifacts for later retrieval. Since browser automation tools plausibly support file transfer (e.g., downloading a report from a site or uploading a document to a form), this axis applies but is unaddressed.

   • [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] “Extract structured data from the current page by providing a schema.”
   • [claimed-docs] “When running a task, you will receive a `live_url`, which can be used to view the agent actions live.”

   proof ↗⚑ flag