Cloudflare's New Agent Browser Is 7x Cheaper and 80% Slower Than Chrome. They Published Both Numbers.

What Kitesurf actually is

For roughly two years, every company building browser infrastructure for AI agents converged on the same strategy: get closer to Chrome. Full JavaScript, full rendering, pixel-perfect output, because that's what “a real browser” meant. Cloudflare's own post about Kitesurf describes the reasoning it walked away from that strategy with in plain terms: browser engines like Chromium “were built for humans, not agents,” and they carry overhead — tabs, themes, extensions, sync, pixel-perfect 60fps rendering — that an AI model reading a page never uses and never asked for. An agent doesn't care about smooth scrolling. It cares about token count, context window, and whether it can afford to run the next 10,000 sessions.

So Cloudflare built a second browser instead of trying to make Chromium leaner. Kitesurf runs entirely on top of Cloudflare Workers, using V8 isolates rather than spinning up a Chromium process per session. The engine is split into three components: the Engine, which is the only public-facing piece and speaks the Chrome DevTools Protocol (CDP), which is why Puppeteer, Playwright, chrome-remote-interface and the actual Chrome DevTools frontend all work against it unmodified; PageScript, which uses Cloudflare's Dynamic Workers to spin up a stateless, isolated session per page, parsing HTML and CSS with Blitz (a modular Rust rendering engine) and Stylo (Firefox's CSS engine, also in Rust) and running JavaScript inside that same isolate; and PageRenderer, which turns the resulting page object into an actual image, using another Blitz module (blitz-paint) plus Parley for text shaping.

# Point an existing Puppeteer script at Kitesurf instead of Chromium.
# CDP-compatibility means most scripts need zero changes.
const browser = await puppeteer.connect({
  browserWSEndpoint: 'wss://browser-run.<your-account>.workers.dev/v1/cdp',
});
const page = await browser.newPage();
await page.goto('https://example.com');
const html = await page.content();  // Kitesurf: ~229ms CPU
await browser.close();

Everything that touches the network goes through one component, SandboxOutbound, enforced by Dynamic Workers, so a compromised or malicious page can't reach anything it shouldn't. Every session starts stateless and disposable by design: if a render call fails, the engine kills and relaunches the renderer rather than trying to recover state, because there is no state worth recovering. That statelessness is also the entire reason the cost numbers below exist — a component with nothing to reconstruct is cheap to throw away and cheap to run a thousand of at once.

The benchmark, number by number

Cloudflare's own post publishes the medians of five Browser Run quick-action runs across a 14-URL corpus, comparing Kitesurf against a warm-pool Chromium instance on two representative agent tasks: taking a screenshot and extracting a page's HTML. Here is the full table, unedited:

The pattern holds across both tasks: Kitesurf wins CPU and memory by a wide, consistent margin, and Chromium wins wall-clock time by a smaller, also-consistent margin. That consistency is what makes the table credible instead of cherry-picked; if the win only showed up on one task, or one metric, it would be easier to write off as noise. It shows up on every metric that measures resource consumption and loses on every metric that measures latency, cleanly, in both directions.

The reversal, explained honestly

Cloudflare doesn't hide the reason Kitesurf loses the stopwatch, and the explanation is genuinely instructive rather than defensive. Quoting their own post directly:

Unpack the mechanism: a warm-pool Chromium instance has a JIT compiler that has already compiled hot code paths for the kinds of pages in the test corpus, and a GPU-accelerated rasterizer for turning the page into pixels. Kitesurf, being brand new, cold-starts a software renderer every time, and the JPEG/PNG encoding step in particular hasn't been optimized yet by Cloudflare's own account. That is a genuinely fixable engineering gap, not a structural one. The CPU and memory numbers are the structural part: Chromium was built to render a page for a human sitting in front of it, with a process model, extension surface and rendering pipeline sized for that job, and no amount of warming up the JIT changes how much RAM a Chromium tab holds onto to do it.

The math Cloudflare didn't spell out

Cloudflare frames the memory numbers as “the things that actually drive your bill,” but stops short of turning that into a density claim. We did the arithmetic ourselves, and we want to be explicit that this next number is our calculation from their published figures, not something Cloudflare stated: 271.0 MiB ÷ 57.8 MiB = 4.7x, and 273.7 MiB ÷ 39.4 MiB = 6.9x. If memory footprint is the practical ceiling on how many concurrent browser sessions fit on one machine, and it usually is well before CPU becomes the constraint for I/O-bound tasks like page rendering, then the same footprint that holds one Chromium session holds somewhere between roughly 5 and 7 Kitesurf sessions.

That is not a 1-for-1 trade of speed for savings. It is trading a small, fixed amount of per-request latency, well under a second either way, for several times the concurrent capacity on the same hardware. For a single request served to a single waiting human, that trade reads as a regression. For a fleet of agents running continuously against thousands of pages a day, the trade reads as the entire point.

What it costs, concretely

Cloudflare hasn't published separate pricing for Kitesurf; it's free while in beta, folded into the existing Browser Run product. But Browser Run's own published pricing shows exactly which resource gets metered once a workload leaves the free tier, and it lines up with the numbers above:

Concurrent browsers, not requests and not wall-clock minutes, is the line item Cloudflare charges for once you're past the included tier. That is precisely the resource memory footprint governs. A back-of-envelope example: a Workers Paid account running 50 browser hours a month at 15 average concurrent browsers pays roughly $13.60 today, per Cloudflare's own published example, $3.60 for the hours plus $10.00 for the 5 browsers over the included 10. If a workload that needed 15 concurrent Chromium sessions could instead run inside the memory footprint of 3 Kitesurf-equivalent slots, at 4.7-7x density, the concurrent-browser line item is the one that would move.

Is it real, or a proof of concept with a good benchmark table?

A brand-new browser engine inviting skepticism is fair, so it's worth checking what Cloudflare is measuring itself against. Kitesurf currently passes over 215,000 Web Platform Tests (WPT), the same standards-conformance suite real browser engines are graded against, and Cloudflare says it's adding hundreds of newly-passing tests every week. Some secondary coverage of the launch reported this figure as 235,000; we went to the primary blog post directly and the text there reads “around 215,000+ WPT tests,” which is the number we're using here. Coverage is deliberately prioritized toward what agents actually touch: CSS, DOM, HTML, selection, SVG and XHR are called out as already well-covered, while video playback, WebGL, persistent authentication sessions and bot-challenge handling are explicitly not supported yet, because none of those matter much to a model reading a page for structured content.

Cloudflare also ran integration and visual-regression testing beyond WPT conformance, multistep Puppeteer tests against real websites, comparing both assertions and rendered output between Chromium and Kitesurf at every step, to catch behavioral drift that a pure standards suite wouldn't. And in the tradition of every serious rendering engine announcement, they shipped the obligatory proof: Kitesurf renders and runs a browser-based Doom port, which is a genuinely reasonable stress test for a from-scratch WebAssembly and Rust rendering pipeline, even if no agent will ever ask it to.

Why this is bigger than one product launch

Browser benchmarks have meant one thing for twenty years: how fast does a page load for the one human waiting on it. Every browser war, from the early 2000s onward, was fought and won on that axis. Kitesurf is the clearest evidence yet that the infrastructure being built for AI agents is being graded on a different axis entirely, not how fast one request finishes, but how many thousand requests you can run at once before the bill breaks you. An agent that's supposed to run continuously, not on-demand for a single human click, doesn't experience one slightly-slow page load as pain the way a person staring at a spinner does. It experiences one bloated, over-provisioned session, repeated across ten thousand concurrent runs, as the reason the month's infrastructure bill didn't make sense.

Cloudflare made that trade-off explicit and public, in a single published table, rather than burying the slower number in a footnote or omitting it entirely. That's the part worth taking seriously past the specific product: the company that ships infrastructure for agents that actually run around the clock is going to look, by the old benchmark, like it lost. Kitesurf is a preview of what winning by the new one looks like instead.

If you're building agents that need to run this way

The Kitesurf trade-off is really a specific case of a much more general problem: the moment an agent stops being a single request-response chatbot and starts being something that runs continuously, cost per concurrent unit becomes the metric that actually determines whether the thing is viable, not raw speed on a single task. That's true for the browser layer Cloudflare just shipped for, and it's just as true for the model-inference layer underneath every agent doing the reasoning.

If you're running agents with mhermes, MegaBrain's always-on agent runtime, every agent gets its own isolated VM with a headless browser, persistent storage and scheduling built in, so it can run continuously instead of spinning up fresh infrastructure per task. And because MegaBrain routes every model call through one API at zero markup, with full cost visibility per task, you can see exactly what keeping an agent running around the clock actually costs, the same discipline Cloudflare just applied to the browser layer, applied to the model calls that layer feeds.

Sign up at getmegabrain.com to run agents that are built for always-on from the start, instead of discovering what continuous operation costs after the infrastructure bill arrives.