Spider Browser passes all 80 tasks on Browser Use's Browser Fidelity Bench

Updated September 18, 2026. Spider now passes 80 of 80. The March 22, 2026 numbers are kept below, and every rival score on this page is still that March run. The live board is on the research page.

Browser Use open-sourced a benchmark that tests cloud browser providers against 80 websites that check hard whether a real browser is asking for the page. It is a hard, honest test, so we ran Spider Browser through it.

We forked their repo, added Spider Browser as a provider, and ran the same 80 tasks on the same harness. In March, Spider Browser scored 85% against Browser Use Cloud’s 81%. On the September 18 rerun it passed every task, a 100% score.

We did not modify the test suite or cherry-pick results. The benchmark and our full results are open source at github.com/spider-rs/benchmark.

How the benchmark works

Browser Use built Browser Fidelity Bench V1 from 300,000 security check events in their production traffic. The test set covers 80 websites, grouped by the protection service each one runs: Cloudflare, PerimeterX, Datadome, Akamai, reCaptcha, hCaptcha, GeeTest, Kasada, Shape, and custom setups.

Each task is simple by design. Open a site, perform a basic interaction, read content. Three steps, no authentication. If the page does not load, the task fails.

The harness checks one thing per task: whether the page loaded for the browser, not whether the agent finished the job. A page that never loads counts as a failure.

Browser Use validated the difficulty with two baselines: headless Chromium scored 2%, headful Chromium scored 50%. The tasks are hard.

Results

In March that was 4 points ahead of Browser Use Cloud, and the gap held across repeated runs. September clears the board. The rival rows are the March readings, kept as published. We did not re-run their providers, and the chart above is that same March snapshot.

Results by site category

The benchmark groups its sites by the protection service they run. Here is how the top providers did in March, when Spider still had ground to make up:

Two numbers stood out. 96% on the Cloudflare set, the service you meet most often on the open web, and 100% on the reCaptcha set. Spider Browser scored highest overall and led four of the six categories.

The other two were PerimeterX and Datadome, at 83% and 77%, and they were hard for everyone on the board. That is where the six months since went.

What changed between the two runs

Nothing in the test moved. Same 80 tasks, same harness, same configuration in the block below. The work went into the challenge path, which is what those two categories lean on, and the last of it landed in September.

Protection services ship on their own schedule, so 80 of 80 is one day’s reading.

How we ran it

We forked Browser Use’s benchmark repo, added spider-cloud as a browser provider using the spider-browser SDK, and ran the evaluation script unchanged.

opts = SpiderBrowserOptions(
    api_key=os.environ["SPIDER_API_KEY"],
    server_url="wss://browser.spider.cloud",
    captcha="solve",
    smart_retry=True,
    stealth=0,
    max_stealth_levels=3,
    hedge=True,
    mode="scraping",
)

That is the full configuration, with no manual retry logic, per-site tuning, or special browser flags. When a site serves a challenge, the SDK detects it and steps up through the stealth levels on its own.

All 80 tasks completed in under 10 minutes total.

What makes Spider Browser different

Spider Browser is a browser runtime written in Rust that drives Chromium, Gecko, and WebKit from one process. Chrome, Firefox, Safari, Brave, and Edge are profiles it presents, not separate stacks to maintain.

That layout is where the score comes from. Site checks stopped being about any one signal a long time ago. What fails now is inconsistency, a browser claiming to be one thing while the details underneath say something else. Patch a profile onto stock headless Chrome and you create those contradictions faster than you can paper over them, because the story and the engine telling it were never the same thing.

We went the other way. We build each profile from the engine that renders the page, so there is no story to keep straight. It is just what that browser does.

One API call gets all of it. The runtime picks an engine and profile per request, watches how the site responds, and switches when something pushes back. That is why the config above has no per-site branches in it, and why no single trick accounts for the score.

The agentic browser

All of that is groundwork for what we set out to build. An agent does not want a page. It wants to finish something, and finishing something means working through a flow, reading what came back, deciding what to do next, and going again, often for a long time, on sites that were not built to be friendly about it.

A browser that fails deep into that run has wasted the whole run. So has a browser that leaves the recovery to you. Spider Browser keeps sessions open, keeps them consistent across every step inside them, and deals with challenges as they come, so the agent can spend its attention on the task instead of on the browser. Use our SDK, connect Puppeteer or Playwright over CDP, or hand it to an agent through Spider’s MCP server.

Loading the page is half of it

A page that loads is worth little if you still have to write the extraction yourself.

In our previous benchmark, we tested 999 URLs across 254 domains and achieved a 100% pass rate with a 2.5s median end-to-end latency. That test covered everything from simple static sites to the most demanding protected sites, with full content extraction and screenshots.

Page loading, extraction, screenshots, structured data, and agent-driven interaction all run through the same SDK.

import { SpiderBrowser } from "spider-browser";

const spider = new SpiderBrowser({
  apiKey: process.env.SPIDER_API_KEY,
  stealth: 0,
});

await spider.init();
await spider.page.goto("https://protected-site.com");

// Structured extraction from any page
const data = await spider.page.extractFields({
  title: "h1",
  price: ".price",
  description: ".product-desc",
});

Reproduce the benchmark

Everything is open source. Clone the repo, set your API key, run the benchmark.

git clone https://github.com/spider-rs/benchmark.git
cd benchmark
pip install uv && uv sync

# Decrypt the task set
python -c "
import base64, hashlib, json
from cryptography.fernet import Fernet
key = base64.urlsafe_b64encode(hashlib.sha256(b'Stealth_Bench_V1').digest())
tasks = json.loads(Fernet(key).decrypt(base64.b64decode(open('Stealth_Bench_V1.enc').read())))
json.dump(tasks, open('Stealth_Bench_V1.json', 'w'), indent=2)
"

# Run with Spider Browser
SPIDER_API_KEY=your-key uv run python run_stealth_eval.py

Results land in stealth_bench/official_results/. Compare against every other provider’s results already committed to the repo.

What this means

Credit to Browser Use for building this benchmark and giving it away. Most comparisons in web scraping are vendor slide decks. This one you can run yourself.

Site checks move. These numbers will move with them, and some future run will go worse than this one. We will publish those too. Try Spider Browser, set your API key, and point it at any URL.

• spider-rs/benchmark: Browser Fidelity Bench fork with Spider results
• spider-rs/spider-browser: TypeScript, Python, and Rust SDKs
• spider-rs/web-scraping-examples: 1,004 ready-to-use scraper scripts