Cloud Browser Providers Benchmarked: Browserbase vs Hyperbrowser vs Kernel vs Steel

By Nicholas St. Germain — May 5, 2026

Introduction

Cloud browsers - managed Chromium sessions you connect to over CDP - have become the default runtime for serious browser automation. Instead of running headless Chrome on your own VMs, you call an API, get a connection URL, and drive the session with Playwright or Puppeteer. The category exploded alongside AI agents: every framework that lets an LLM "use a computer" needs a reliable browser somewhere, and running it locally doesn't scale.

The four providers most teams compare today are Browserbase, Hyperbrowser, Kernel, and Steel. They all expose roughly the same shape of API, but the operational characteristics - how fast a session boots, how quickly CDP connects, how often the tail latency spikes - differ enough to materially affect agent loop times and web scraping throughput.

Rather than guess, we leaned on the ComputeSDK Benchmarks project, which runs the same Playwright workflow against each provider every day from a GitHub Actions runner and publishes the raw results. This post walks through what they're measuring, what the numbers actually look like, and what each provider's profile means for the workload you're picking it for.

What the Benchmark Measures

The ComputeSDK browser benchmark times four phases of a single end-to-end browser run, then totals them:

1. Create - calling the provider's session API and waiting for it to return a CDP connection URL
2. Connect - chromium.connectOverCDP(connectUrl) with Playwright, fetching the default context and page
3. Navigate - page.goto("https://www.example.com", { waitUntil: "load" })
4. Release - destroying the session via the provider's API

Each provider runs 100 iterations. Each iteration is fully isolated - fresh session, fresh CDP connection, navigate, tear down. Results are trimmed (top and bottom 5%) before computing median, P95, and P99 to keep transient network blips from dominating.

The composite score blends four metrics on a 0–100 scale (10 second ceiling, anything ≥10s scores 0):

Then the timing score is multiplied by success rate (0–1). All four providers in the latest run hit 100/100 success, so for this comparison the score reflects pure timing.

The numbers below are from the 2026-05-05 daily run.

Browserbase

TTI Breakdown

Composite score: 93.63 · Success rate: 100/100

What the Numbers Say

Browserbase is the most consistent provider in the median. Create at 208 ms is fast and tight (the spread between median and P99 is only ~22 ms - most providers vary much more). Release at ~121 ms is also predictable.

The interesting numbers are in the tails. Connect P99 at 631 ms (vs a 114 ms median) and Navigate P99 at 561 ms (vs 142 ms median) suggest occasional CDP handshake or page load hiccups roughly 1% of the time. Total P95 at 1.07 s and P99 at 1.10 s sit close together, which means the bad iterations cluster - when something goes slow, it's mostly the same kind of slow.

Best For

Teams building AI agents that need a polished developer experience and a strong live session viewer. Stagehand integration is first-party. The median is fast and the worst case is still under 1.1 s, which keeps agent loops tight.

Hyperbrowser

TTI Breakdown

Composite score: 95.14 · Success rate: 100/100

What the Numbers Say

Hyperbrowser leads the field on the composite score. The reason isn't that any single phase is dramatically faster - it's that every phase is consistent. The spread from median to P99 is small everywhere: navigate goes from 99 ms to 106 ms, connect from 181 ms to 197 ms. There's no long tail.

That tightness is the main story. P95 at 648 ms and P99 at 838 ms are the lowest tail numbers in the comparison, which matters if your workload involves dozens or hundreds of concurrent sessions where one slow outlier blocks downstream work.

The fastest navigate (99 ms median) is also notable - typically a sign of well-tuned network egress and minimal per-request middleware.

Best For

High-volume workloads where tail latency dominates economics - large agent fleets, parallel scrapers, anywhere "p99 spikes block the whole batch" is a real failure mode. Hyperbrowser is the safest pick if you care about consistency over peak speed.

Kernel

TTI Breakdown

Composite score: 94.93 · Success rate: 100/100

What the Numbers Say

Kernel has the most distinctive shape in the field. Session create at 12 ms is more than an order of magnitude faster than anyone else (208 ms for Browserbase, 170 ms for Hyperbrowser, 243 ms for Steel). That's not a "slightly faster API" - that's a fundamentally different architecture, almost certainly a pre-warmed pool returning immediately rather than provisioning on demand.

Release at 30 ms is also dramatically faster than competitors (which sit around 90–120 ms), suggesting the same warm-pool pattern on teardown.

The cost of that approach shows up in Connect: 422 ms median is roughly 3–4× slower than Browserbase or Hyperbrowser. Whatever Kernel skips at session create has to happen during the CDP handshake instead - likely actually booting or attaching the Chromium process.

Net result: total TTI lands at 665 ms median, slightly behind Hyperbrowser but with extremely tight tails (P99 at 810 ms). The composite score weights create heavily (30%), which is why Kernel beats Browserbase despite a slower total.

Best For

Workloads where session create latency dominates - short, bursty sessions, "open browser, do one thing, close browser" patterns, or any agent loop that frequently spawns and discards browsers. If you average more than a few sessions per agent step, Kernel's create-time advantage compounds quickly.

Steel

TTI Breakdown

Composite score: 84.45 · Success rate: 100/100

What the Numbers Say

Steel is the slowest of the four on the median, and the gap widens at the tails. Total P95 at 3.05 s and P99 at 3.75 s are roughly 4× the equivalent numbers for Hyperbrowser. Reliability is fine - 100/100 success - but the long tail is real.

Most of the latency lives in Connect (633 ms median, 1.95 s P99). Create at 243 ms is in the same ballpark as Browserbase, and Navigate (116 ms) and Release (117 ms) are competitive. The CDP attach phase is where things stall.

It's worth noting Steel is the only provider in this set with an open-source core (the Steel Browser engine is MIT-licensed). The hosted product is newer than Browserbase or Browserless, and the benchmark profile reads like a younger platform that's prioritized correctness and feature surface over raw throughput so far.

Best For

Teams that value the open-source escape hatch - running Steel hosted today with the option to self-host the same engine later for compliance or cost reasons. If your loop is long-running enough that 1.2 s of session setup is rounding error, the platform optionality matters more than the timing gap.

Head-to-Head

Quick read:

• Hyperbrowser wins on composite, total median, and tail tightness
• Kernel wins on session create (by an order of magnitude) and release
• Browserbase wins on CDP connect and is the most consistent on create
• Steel is competitive on the create/navigate/release phases but loses time on connect, especially at the tails

Source: computesdk/benchmarks, 2026-05-05 daily run. All four providers passed 100/100 iterations.

Choosing the Right Cloud Browser

You're Building an AI Agent

Pick Hyperbrowser or Browserbase.

Agent loops measure user-visible latency in seconds, and a tight P95 is more valuable than a slightly faster median. Hyperbrowser's 648 ms P95 is the best in the field; Browserbase's polished DX and live viewer is the best for debugging the agent itself. Either choice keeps you under a second per browser-bound step in the typical case.

You Spawn Many Short Sessions

Pick Kernel.

If your loop creates and discards browsers frequently - e.g., one session per scrape target, or per agent sub-task - Kernel's 12 ms session create dominates. Over 1,000 sessions, that's ~3 minutes of time saved versus the 200 ms-class providers, before counting the equally fast 30 ms release.

You Need Self-Hosted Optionality

Pick Steel.

Steel is the only provider in this comparison with an open-source core. The timing gap is real but the optionality of "managed today, self-hosted tomorrow" matters for compliance-heavy use cases or teams that expect to grow into their own infrastructure.

You're Scraping at High Volume

Pick Hyperbrowser, with external proxies.

The composite score plus the small P95→P99 gap means you can spin up large concurrent batches and not have a few slow sessions hold up everything downstream. Pair with dedicated ISP proxies for clean IP reputation against anti-bot stacks.

The Variable the Benchmark Doesn't Measure: Your IP

Every provider in this comparison ships some flavor of bundled proxy product - managed residential pools, geographic targeting, automatic rotation. The ComputeSDK benchmark hits example.com, which has no anti-bot defense, so the bundled proxy never matters. In production it matters a lot.

Bundled proxies in cloud browser products tend to be:

• Shared rotating residential pools with abused IP histories
• Per-GB priced, which makes image-heavy targets expensive
• Opaque - you rarely see ASN, carrier, or specific IP, which slows debugging
• Generic - the same pool everyone else on the platform is using against the same targets

The result is a familiar pattern: a perfectly tuned Hyperbrowser or Browserbase session that still gets challenged constantly because the IP it's coming from has a flagged reputation. You end up paying twice - once for the cloud browser, once for the bundled proxy - and still hitting walls.

Why ISP Proxies Outperform Bundled Pools

ISP proxies are static residential IPs registered to consumer-grade ASNs. To anti-bot systems, traffic from an ISP proxy looks identical to a real residential broadband user.

• Static, dedicated IPs: No rotation surprises mid-session, no inheriting bad reputation from other tenants
• Clean ASN classification: Registered to consumer ISPs, not cloud hosting providers
• Unlimited bandwidth: No per-GB billing, so heavy pages stop being a budget question
• Predictable identity: The same IP across sessions builds trust with target sites over time

Plugging Stat Proxies Into Any of These Providers

Every provider in this comparison supports custom proxies. The shape is the same: pass the proxy URL when you create the session.

Browserbase:

import Browserbase from "@browserbasehq/sdk";

const bb = new Browserbase({ apiKey: process.env.BROWSERBASE_API_KEY });

const session = await bb.sessions.create({
  projectId: process.env.BROWSERBASE_PROJECT_ID,
  proxies: [
    {
      type: "external",
      server: "http://isp.statproxies.com:3128",
      username: process.env.STAT_PROXY_USER,
      password: process.env.STAT_PROXY_PASS,
    },
  ],
});

Hyperbrowser:

import { Hyperbrowser } from "@hyperbrowser/sdk";

const client = new Hyperbrowser({ apiKey: process.env.HYPERBROWSER_API_KEY });

const session = await client.sessions.create({
  proxy: {
    server: "http://isp.statproxies.com:3128",
    username: process.env.STAT_PROXY_USER,
    password: process.env.STAT_PROXY_PASS,
  },
});

Steel:

import Steel from "steel-sdk";

const client = new Steel({ steelAPIKey: process.env.STEEL_API_KEY });

const session = await client.sessions.create({
  proxyUrl:
    `http://${process.env.STAT_PROXY_USER}:${process.env.STAT_PROXY_PASS}` +
    `@isp.statproxies.com:3128`,
});

The pattern is the same regardless of vendor: cloud browser handles rendering, CDP, and orchestration; ISP proxy handles identity. You stop double-paying for low-quality bundled bandwidth and you stop debugging blocks that are really IP-reputation problems.

Conclusion

The 2026-05-05 ComputeSDK benchmarks paint a clear picture of the cloud browser landscape:

• Hyperbrowser is the timing leader - best composite, best tails, best navigate
• Kernel has the most differentiated profile - sub-20 ms create from a warm pool, slower CDP connect to compensate
• Browserbase is the consistency play - predictable medians, polished DX, occasional tail spikes
• Steel is the platform-optionality play - slower today, open-source core for tomorrow

All four are reliable (100/100 success in the latest run). The right choice depends on whether your workload is dominated by session-create overhead, by tail latency under concurrency, by developer experience, or by the optionality of self-hosting later.

Whichever you pick, pair it with a clean ISP proxy on the front. The cloud browser solves the rendering and orchestration problem. Your proxy solves the identity problem. Mixing them in a single bundled SKU is convenient - and consistently the most expensive way to get the worst of both.

Ready to upgrade the proxy half of your stack? Try Stat Proxies' dedicated ISP plans and plug them into the cloud browser you already use.

Benchmark numbers cited from computesdk/benchmarks, 2026-05-05 daily run. All metrics reflect 100 iterations per provider with 5% trim on each end before computing percentiles.