Cloudflare Built a Browser for Agents and Left Out Chromium

What Cloudflare shipped

• A browser with no Chromium in it. Announced 6 August 2026 on Cloudflare's engineering blog, Kitesurf is a stateless browser running entirely on Cloudflare Workers, inside V8 isolates, as part of the Browser Run product. TechCrunch picked it up the following day.
• Rust compiled to WebAssembly, not a rendering-engine fork. Three components: an Engine exposing the CDP WebSocket and HTTP APIs, PageScript running page sessions as Dynamic Workers, and PageRenderer producing pixels through Blitz modules.
• Cheaper on resources, slower on the clock. Median figures across a 14-URL corpus put Kitesurf at 3.1–3.8x less CPU and 4.7–7.0x less memory than Chromium, and 1.7–1.8x slower in wall time.
• It speaks Chrome DevTools Protocol. Puppeteer, Playwright, chrome-remote-interface, the Chrome DevTools frontend and MCP clients connect unchanged.
• Cloudflare publishes its own non-goals. No video, no WebGL, no bot-challenge handshake with real TLS fingerprints, no long authenticated session with persistent state. Free in beta, with per-account limits.

Almost every headless browser in production today is Chromium with the interface removed. That is a strange default given what an agent does with a page: fetch a document, wait for the script to settle, extract text or take a screenshot, dispose of the session. It does not watch video, switch tabs, install extensions or care whether a drop shadow lands on the correct sub-pixel. Yet it pays, in memory and CPU, for an engine built to do all of that for a human.

Kitesurf is Cloudflare's answer: build the browser for the actual caller. Cloudflare says it decided to build it roughly twelve weeks before launch, which is fast for a rendering engine and only makes sense because the Rust web-engine ecosystem had already done the hard parts. Blitz handles HTML and CSS parsing, Stylo does CSS, Parley does text shaping, and the Boa JavaScript engine supports eval(). Cloudflare assembled rather than started from nothing.

The architecture, and why statelessness is the point

The three-part split matters more than the component names. The Engine terminates the CDP WebSocket and HTTP APIs — the surface your automation client talks to. PageScript runs each page session as a Dynamic Worker, which is what makes a session cheap to create and cheap to destroy. PageRenderer turns the resolved document into pixels when you ask for a screenshot.

Running each session as an isolate rather than a process is the load-bearing decision. A Chromium instance is heavyweight and long-lived: a substantial startup cost, then resident memory for as long as it lives. The usual response is to pool instances and reuse them, which buys you state bleed between tasks, a memory curve that only goes up, and a recycling policy nobody is confident in — the operational shape we covered in our guide to running browser agents in production.

A stateless isolate refuses to hold that state at all, and in doing so gives up the pooling optimisation you were relying on. That is precisely why the wall-time numbers look the way they do.

Reading the benchmark table honestly

Cloudflare's own median figures across its 14-URL test corpus. The temptation is to quote the memory column and stop. Do not.

Two things stand out. The first is that memory is the widest gap, and it widens as the task gets simpler: 4.7x on a screenshot, 7.0x on plain HTML extraction. Chromium's footprint barely moves between the two tasks — 271.0 MiB against 273.7 MiB — because you are paying for the engine, not for the work. Kitesurf's drops from 57.8 MiB to 39.4 MiB, because it only builds what the task requires.

The second is the wall-time regression, and it is real: every operation takes roughly 1.7 to 1.8 times longer. Cloudflare is not hiding it, which is more than most vendor benchmarks manage.

So this is a deliberate trade, not a free win. If you are running one session and a person is waiting for the result, half a second of added latency is the only number that matters and you have made your product worse. If you are running hundreds of concurrent, bursty sessions and paying for resident memory, throughput per gigabyte is the number that matters, and a 7x memory reduction lets you run several times more sessions on the same footprint even though each finishes later. Those are different businesses. Kitesurf is optimised for the second, and Cloudflare says as much: it optimises for token count, context windows, scalability, performance and cost rather than for the features only humans need.

The CDP decision is what makes this migratable

A new rendering engine with a new API is a research project. One that speaks the protocol your tooling already speaks is a deployment decision, and the gap between those two is where adoption is won or lost.

Kitesurf implements both the Chrome DevTools Protocol WebSocket interface and its REST interface. Puppeteer connects. Playwright connects. So do chrome-remote-interface, the Chrome DevTools frontend itself, and MCP clients — which matters increasingly as browser control becomes something an agent negotiates over a protocol rather than something a script hard-codes. The direction of travel is visible in WebMCP, the browser-agent protocol Google showed at I/O, and in the wider consolidation of agent protocols under a single neutral governance body.

CDP was not the elegant option. It is a large, Chrome-shaped protocol with a long tail of methods, and implementing it on a non-Chrome engine means matching behaviour you did not design. Cloudflare took that cost so its users would not have to take theirs — the correct trade for anyone displacing an incumbent, and the reason this is worth an afternoon rather than a bookmark.

// Same suite, different engine. Only the endpoint changes.
const browser = await chromium.connectOverCDP(process.env.CDP_URL);
const page    = await browser.newPage();
await page.goto(target, { waitUntil: 'networkidle' });
const html    = await page.content();
// Diff `html` against the Chromium baseline for the same URL.

What Kitesurf will not do

Cloudflare publishes its non-goals, which is unusual and worth taking at face value. Kitesurf is the wrong tool if you need to play video, render WebGL, negotiate a bot-challenge handshake with real TLS fingerprints, or run a ten-minute authenticated session requiring persistent state. It also drops tabs, themes, extensions and pixel-perfect rendering — the features that exist because a human is looking at the window.

Three of those four exclusions are technical. The bot-challenge one is strategic. Much real-world automation exists precisely because the target site does not want to be automated, and the value of a Chromium stack there is that it presents a genuine browser fingerprint. An engine that is honestly not Chrome cannot fake being Chrome at the TLS layer.

The persistent-session exclusion is the one most teams will hit without expecting to. Stateless is a real constraint, not a marketing word. A long authenticated workflow — log in, navigate five pages, fill a form, wait for an asynchronous confirmation — is exactly the shape Kitesurf is not built for, and plenty of production agent work looks like that.

Then there is coverage. Around 215,000 Web Platform Tests pass today, with hundreds more passing each week. That weekly delta is the honest signal: the number is large and still moving, so the gap is real and closing. Some secondary coverage has quoted a higher figure than Cloudflare's own; take the 215,000 and measure your own sites regardless.

Why the cost model lands harder in Bengaluru and London

Cloudflare's edge footprint covers both of AI Tech Connect's markets, so this is not a US-first launch that reaches Indian and UK teams six months late. What matters more is what the cost shape does to a smaller budget.

Browser automation is one of the few agent costs that is not a token cost, and it is routinely underestimated because it never shows up in the model bill. A team in Bengaluru running a product-catalogue extraction pipeline, or one in Manchester monitoring competitor pricing overnight, pays for compute that sits resident for every session. When a Chromium instance holds roughly 270 MiB whether it is taking a screenshot or reading a paragraph, the fleet you can afford is capped by memory long before anything interesting caps it. A 4.7x to 7.0x reduction changes the size of pipeline a small team can run at all.

That line item only becomes visible if you measure cost per successful task rather than cost per model call — the discipline we set out in LLM unit economics. Teams that track it usually find browser infrastructure is a larger share of the bill than they assumed, and that it scales with concurrency rather than quality.

Two caveats before anyone signs off on it. Moving browser sessions onto a managed edge platform raises data-residency questions that read differently under the UK GDPR than under India's DPDP framework — neither forbids it, both need someone able to say where page content is processed. And an agent browser is another remote surface reaching arbitrary web content on your behalf, the same category of exposure that produced 143,000 findings across 25,000 MCP servers. Treat it as infrastructure, not as a library.

What to test this week

If you run browser agents at any scale, four steps in this order.

1. Classify your sessions first. Stateless extraction, screenshotting, authenticated multi-step journeys, challenge-gated targets. Only the first two are candidates.
2. Run the CDP diff. Point an existing suite at the Kitesurf endpoint, run your real target URLs, and diff extracted text and DOM structure against your Chromium baseline. That measures the engine gap on your sites, which is the only coverage number that matters to you.
3. Benchmark concurrency, not latency. Establish sessions completed per unit of memory at an acceptable error rate. Expect each session to be slower; check whether throughput per rupee or per pound improves. If it does not, the trade is not paying for your workload.
4. Price the lock-in honestly. Kitesurf is free during beta with per-account limits, so today's bill tells you nothing about next year's. Because it speaks CDP your exit cost is genuinely low — but only if you keep the automation code engine-agnostic.

The wider point outlives this one product. For two decades, anything consuming the web did it through a browser built for people, because that was the only browser there was. Agents are now a large enough class of caller to justify their own tooling, and the first serious attempt is 3–7x cheaper on resources and 1.8x slower per operation. Expect more of the stack to be re-cut along that line — and if you are the person doing the re-cutting, it is exactly the kind of work worth showing on a Builder profile.