FuturPulse analysis · 15 October 2026
Scout Browser Agent’s published 92.5% cloud result came from three runs on 7 October 2026, so it is a pilot candidate, not an unattended holder of production credentials, on 15 October 2026.
At a glance
- Outcrawl says Scout reached 92.5% of pages in a three-run test of an 80-site benchmark, but that is not an independently reproduced task-success score.
- Browser Use reports 63.3% task success for its bu-2-0 model on its 100-task BU Bench V1, using its open-source agent loop.
- Scout requires Node 22 or later, while Browser Use’s documented local Claude integration requires Python 3.11 or later on Linux or macOS.
- Browser Use Cloud lists browser time at $0.02 per hour plus traffic; Scout publishes 1,000 free monthly credits but no public credit-to-dollar conversion in its repository.
Is Scout Browser Agent ready for production?
Scout is ready for a bounded pilot where a person reviews the replay and output. It is not yet a sensible choice for a payroll, banking, purchasing, customer-support, or administrator account that can act without a human.
The reason is evidence, not Scout’s ability to click buttons. Scout documents step, duration and budget caps, plus completed, partial, capped and failed results. Those are useful controls because they stop a run and preserve what it found.
But production readiness also needs clear controls around authority. Scout’s public quickstart shows sign-in tasks and cloud replays, yet it does not publish a credential vault design, role model, approval gate, audit-retention term, or incident-response commitment in the repository. A cap limits work; it does not decide whether an irreversible action should happen.
Which browser agent should you choose?
The practical choice is between Scout’s TypeScript-first, model-neutral loop and Browser Use’s larger Python ecosystem with documented model and tool integrations. Neither published record proves safe autonomous purchasing or account administration.
| Concrete option | Published figure | Integration and control signal | Production-readiness call | Evidence tier |
|---|---|---|---|---|
| Scout on a local Chromium browser | Node 22 or later | Runs against a launched local browser or an existing Chrome DevTools Protocol connection. | Pilot for non-sensitive tasks. Local operation avoids a cloud browser dependency, but the public material does not establish credential governance. | Tier A: verified vendor repository |
| Scout on Outcrawl Cloud | 92.5% page reach across 3 runs | Residential connections, CAPTCHA solving and replay links are vendor-described cloud features. | Useful where access failure is the main problem. Treat the score as a vendor self-test, not a cross-vendor winner. | Tier B: vendor self-reported benchmark |
| Browser Use open source with bu-2-0 | 63.3% success on 100 tasks | Browser Use exposes custom tools and its model card recommends allowlists, step limits and human approval for high-impact actions. | Better documented for application integration. Still require your own approval path before purchases or external submissions. | Tier A: verified vendor model card |
| Browser Use Cloud browser | $0.02 per browser-hour, plus traffic | Hosted browser infrastructure can be paired with the open-source library or hosted agents. | Choose when managed browser operations matter more than owning the runtime. Model inference remains an additional cost. | Tier A: verified vendor pricing page |
Evidence tiers distinguish public product documentation from a company’s own benchmark claim. No untraceable rumour is used in this scorecard. “Production-readiness call” is FuturPulse’s assessment of the published controls, not a vendor certification.
Are Scout’s and Browser Use’s benchmarks comparable?
No. Scout’s 92.5% figure measures pages reached on Browser Use’s 80-site benchmark, with Outcrawl’s own code and three full runs. Browser Use’s 63.3% figure measures binary task success across 100 mixed browser-agent tasks, not page reach.
Browser Use describes BU Bench V1 as a 100-task mix of custom page interaction, WebBench, Mind2Web 2, GAIA and BrowseComp. Its judge rates whether the user’s intended result was completed, so a page that loads but does not produce the answer is still a failure.
Scout’s result is still useful. It says Outcrawl’s hosted browser passed through more target pages than the test’s next-best entry, which reached 81.4%. It does not show that Scout planned better, extracted better, or completed more end-to-end work than Browser Use.
Browser Use separately reports 90.5% successful visits on 100 bot-protected sites for its cloud browser, versus 82% for Anchor, 80.5% for Kernel and 78.5% for Browserbase. That is an infrastructure reach test, not a comparison with Scout’s agent loop.
The buyer’s rule is simple: do not compare percentages until the task list, browser configuration, model, number of repetitions, success judge and failure treatment match. Ask both suppliers to run your real workflow with redacted data and publish the replay, trace and result.
How does Scout connect to models and browsers?
Scout is unusually flexible about the model, because it has no built-in default model. Its repository says any standard chat-completions-compatible service can supply the required “hands” model, including a model hosted on the buyer’s own machine.
“Hands” is the model Scout calls at every step to read the page and choose clicks, typing, scrolling or extraction. Optional “brain,” “eyes” and “extract” jobs split planning, screenshot reading and structured extraction across different models.
That split can reduce cost or improve output quality, but it adds operational choices. Each job can use a separate endpoint and API key. A buyer must therefore log which model saw which page, restrict which endpoint can receive sensitive content, and test structured-output failures before deployment.
Scout can drive Outcrawl Cloud, a Chromium browser it launches locally, or an existing browser through Chrome DevTools Protocol. The last option is useful for an isolated test profile, but it is also exactly why a normal employee browser should not be connected casually: its authenticated session may carry more authority than the task needs.
What integration edge does Browser Use have?
Browser Use has the stronger published integration story. Its open-source library can use its bu-2-0 decision model or a selected external model, and the project reports 118,000 GitHub stars, compared with Scout’s 795 at the time checked.
Stars are not a security test or a reliability benchmark. They do, however, indicate a much larger public contributor and user base around Browser Use’s Python library. Browser Use’s repository lists 10,345 commits, while Scout’s public mirror lists 19 commits and says changes first land in Outcrawl’s production repository.
The more concrete advantage is its Claude integration. Browser Use documents 31 browser actions plus an optional Bash tool. It can operate local Chromium, Browser Use Cloud, or an existing remote CDP browser.
That flexibility brings risk. Browser Use’s quickstart can enable JavaScript execution, file upload, console reading and network reading, while Bash can run beside the Python process. Keep those tools off unless the workflow needs them. Separate browser workers from internal systems, and never give an agent shell access merely because it can produce a report.
How much can Scout’s model use cost?
Scout’s source code is open, but its model calls are not free. By our calculation from OpenRouter’s listed Llama 4 Scout rates, a 30,000-input-token and 2,000-output-token agent step costs $0.00658, or $6.58 for 1,000 such steps.
This is a planning estimate, not a Scout bill. Tokens are the chunks of text a model reads and bills by. The calculation assumes Meta Llama 4 Scout at $0.18 per million input tokens and $0.59 per million output tokens, with no caching, provider markup, retries or browser charge.
The important implication is that browser work can create more model traffic than chat. Scout says its hands model runs on every step. A long task can repeatedly send page state, prior actions and tool results to the model, so make the agent stop after a sensible number of steps rather than asking it to “keep trying.”
Scout offers 1,000 free Outcrawl credits each month with no card required, but its public repository does not state what a credit buys or quote a cash price for a cloud session. Browser Use is clearer on browser infrastructure: its published rate is $0.02 an hour plus internet traffic, while model inference remains separate.
What setup should a team test first?
Start with a local, throwaway browser profile and a low-risk target. Scout needs Node 22 or later, then its local path installs Playwright Core and Chromium. Browser Use’s local Claude toolset requires Python 3.11 or newer, Linux or macOS with Bash, or Windows through WSL.
For Browser Use, Astral’s uv documentation lists standalone installers, package-manager routes and pip installation. That makes reproducible Python environments easier, but it does not replace isolation. Pin package versions, record the browser version, and keep the automation account separate from your own account.
- Give the agent a test account with no payment method, no administrator role and no reusable corporate password.
- Set a small step, duration and spending cap before the first run.
- Require structured output, then compare it against the browser trace or replay.
- Block file upload, JavaScript execution, shell access and downloads unless the use case requires each one.
- Put a human approval step before submission, purchase, deletion, publishing or sending messages.
Use real tasks, not headline demos. A browser agent that finds three stories on Hacker News has not proved it can handle your single sign-on flow, customer data, stale page state, conflicting instructions or an unexpected payment screen.
What should you actually deploy?
Deploy Scout first when you need a TypeScript agent that can bring its own model, run locally, return structured JSON and provide cloud replays for supervised research. Its standout published claim is browser reach, not independently established end-to-end task completion.
Choose Browser Use first when your application is Python, you need documented custom tools, or you want its Claude toolset. Browser Use explicitly recommends domain allowlists, tool allowlists, step limits and custom human approval tools for high-impact work. That is the right baseline, not an optional enterprise upgrade.
Do not select either project because a blog calls browser agents autonomous. Firecrawl’s 2026 survey of browser-agent products usefully separates open-source frameworks, managed infrastructure and consumer browsers, but category labels do not settle operational risk. Your agent’s authority is set by its tools, account and approval rules.
For an external website, also design for the harm an agent can create through volume. One site operator described repeated AI-related requests that caused high load. Rate limits, caching, backoff and a clear user agent are not polite extras. They are part of a deployment that does not make another team’s service worse.
What we could not verify?
Outcrawl has not publicly published a cash price per Scout cloud session, a credit conversion, an independent reproduction of its 92.5% result, or detailed terms for replay retention and access. Outcrawl could settle those questions with a pricing page, a benchmark repository and a security-control specification.
There is also no published like-for-like Scout versus Browser Use test that holds browser provider, target sites, model, retries, budget, task judge and repetitions constant. An independent benchmark operator, or either vendor publishing a jointly reproducible test harness, could settle the performance claim that buyers actually need.
