Every AI agent stack that touches the web ends up running headless Chromium somewhere — for scraping, for screenshots, for filling out forms a user asked an agent to handle. Chromium is the default because it’s the only browser engine that’s been battle-tested at that scale. Cloudflare just shipped something that questions that default: Kitesurf, a browser built from scratch, specifically for agent workloads, that doesn’t use Chromium at all.

I’ve spent the last few years running headless browser fleets for scraping and test automation, so the pitch — “same CDP API, a fraction of the resource cost” — is the kind of claim I want to verify with numbers before I trust it. Cloudflare published real benchmarks. Here’s what they actually say, and where I’d deploy this versus stick with Chromium.

What Kitesurf Actually Is

Kitesurf isn’t a Chromium fork or a wrapper around an existing engine. It’s assembled from three separately-sourced, mature components, each doing one job:

• Blitz — Servo’s layout engine, handling the box model, flexbox, grid, and rendering geometry
• Stylo — Firefox’s CSS engine, handling selector matching and style computation
• Boa — a JavaScript engine written in Rust, executing page scripts

That’s a deliberate choice: instead of writing a new layout engine or CSS engine from scratch (a multi-year undertaking that Chromium, Firefox, and Safari all paid for the hard way), Cloudflare composed existing, independently-maintained engines that already pass real conformance suites.

The architecture splits into three isolated pieces:

flowchart LR
    A[Agent Request] --> B[Engine Worker]
    B --> C[PageScript - Boa JS]
    B --> D[PageRenderer - Blitz+Stylo]
    C --> E[CDP Response]
    D --> E

• Engine Worker — orchestrates the page lifecycle and owns the CDP (Chrome DevTools Protocol) interface
• PageScript — runs Boa, executing the page’s JavaScript in isolation
• PageRenderer — runs Blitz + Stylo, producing layout and paint output

Critically, the whole thing runs inside a Cloudflare Workers V8 isolate, not a container or a VM. That’s the part that actually changes the economics: no Chromium process tree, no GPU process, no per-instance OS overhead — just an isolate that spins up in milliseconds.

The Numbers That Matter

Cloudflare’s own benchmarks, run against headless Chromium on equivalent screenshot and content-extraction workloads:

That last row matters more than it looks — 215k+ WPT passes means this isn’t a toy renderer that breaks on real-world pages; it’s tracking actual web standards conformance, the same suite browser vendors use internally.

The CPU/memory numbers are the headline, but the honest read is: Chromium is still faster in raw wall-clock terms, because Boa doesn’t have Chromium’s JIT compiler. For JS-heavy interactive pages — SPAs doing a lot of client-side computation — Chromium will finish faster per request. Kitesurf wins on cost-per-request at scale, not latency-per-request.

Hands-On: Same Code, Different Backend

The part that actually matters for adoption: Kitesurf speaks CDP, the same protocol Puppeteer and Playwright already use to drive Chromium. That means most existing automation code doesn’t need to change — you point it at a different endpoint.

// Existing Puppeteer code, pointed at Chromium
const browser = await puppeteer.connect({
  browserWSEndpoint: 'wss://chrome.example.com/session',
});

// Same code, pointed at a Kitesurf endpoint on Workers
const browser = await puppeteer.connect({
  browserWSEndpoint: 'wss://kitesurf.example.workers.dev/session',
});

const page = await browser.newPage();
await page.goto('https://example.com/product-listing');
const data = await page.evaluate(() => {
  return Array.from(document.querySelectorAll('.price')).map(el => el.textContent);
});
await browser.close();

No rewrite. That’s the actual engineering achievement here — not the new engine, but making the new engine a drop-in replacement for the CDP surface everyone already codes against.

Where I’d Actually Deploy This

Kitesurf makes sense when:

• You’re running a fleet of agent-driven scraping or extraction workers at real volume, where CPU/memory cost scales linearly with fleet size — cutting resource usage 3-7x is a direct infrastructure bill reduction.
• The workload is mostly extraction (read DOM, take screenshot, fill a form) rather than executing heavy client-side JS logic.
• You want the isolate-level sandboxing Workers gives you for free when running agent-directed, potentially untrusted browsing sessions — no shared container, no process escape surface between tenants.
• Cold-start latency matters. A V8 isolate spins up in single-digit milliseconds; a fresh Chromium process does not.

Stick with headless Chromium when:

• Your target pages are JS-heavy SPAs where JIT-compiled execution speed genuinely matters — Boa’s interpreter-level performance will show up as real latency on compute-heavy client code.
• You need maximum site compatibility today. Chromium has years of edge-case handling for broken, non-standard pages that a newer engine, however conformant, hasn’t accumulated yet.
• Your team already has deep Chromium/Puppeteer operational knowledge and the current cost isn’t actually a problem worth solving.

The Trend This Confirms

The interesting signal isn’t “Cloudflare built a browser” — it’s that agent workloads are diverging enough from human-browsing workloads that a browser optimized specifically for agents (headless-only, no rendering-for-a-human requirement, high concurrency, cost-per-request as the primary metric) is now worth building instead of just running the human-facing browser headless. That’s the same pattern I’ve seen play out in inference serving, where general-purpose runtimes eventually get replaced by workload-specific ones once the volume justifies it.

I wouldn’t rip out a production Puppeteer/Chromium pipeline today — the maturity gap on obscure site compatibility is real, and it’s early. But if you’re standing up a new agent-browsing fleet from scratch and your workload is extraction-heavy rather than interaction-heavy, benchmark Kitesurf against your actual pages before defaulting to Chromium. The CDP compatibility means that test costs you an afternoon, not a rewrite.

Thuận Lương is a Technical Lead with 15+ years in .NET, cloud architecture, and AI systems. He writes about real-world lessons from building production systems.