Per-action throughput inside a running session — 10 sequential actions across 100 sessions per provider.
Powered byMedian latency per action type. Each action type is timed individually.
Provider | Score | Actions/sec | Task (med) | Task (p95) | Screenshot | Navigate | Click |
|---|---|---|---|---|---|---|---|
| Kernel | 81.3 | 6.07 | 1.65s | 2.16s | 231ms | 492ms | 229ms |
| Tilion | 73.4 | 4.44 | 2.25s | 3.60s | 205ms | 342ms | 373ms |
| Browserbase | 72.9 | 4.25 | 2.35s | 3.04s | 264ms | 798ms | 298ms |
| Browser Use | 70.1 | 3.66 | 2.73s | 3.16s | 248ms | 689ms | 573ms |
| Hyperbrowser | 67.7 | 3.28 | 3.05s | 3.97s | 427ms | 702ms | 454ms |
| Steel | 57.7 | 3.05 | 3.28s | 8.91s | 343ms | 371ms | 596ms |
| Notte | 51.4 | 1.26 | 7.93s | 9.77s | 1039ms | 801ms | 2352ms |
Want to see a provider added?
Each session executes 10 sequential actions inside a single running browser: navigate → waitForSelector → screenshot → textContent → click → waitForSelector → screenshot → textContent → goBack → waitForSelector, on Wikipedia.
Every action is timed individually. A failed action does not abort the session — the sequence continues and the failure is recorded. This lets us observe degradation patterns rather than discarding unlucky sessions.
Each provider runs 100 sessions per benchmark run. All sessions use stealth mode and a 1920×1080 viewport to match realistic agent conditions. Benchmarks run weekly via GitHub Actions and results are committed to the public benchmarks repo.
The Composite Score (0–100, higher is better) weights four axes that matter for agent workloads, then multiplies by success rate so flaky providers can't hide behind fast averages.
The final score is multiplied by success rate — the fraction of sessions that completed all 10 actions. A provider that fails 1 in 10 actions is penalized proportionally.