On August 6, 2026, Cloudflare released a beta of Kitesurf, a browser engine for AI agents, on Browser Run. This isn't a product that reworks the Chrome screen for humans. It doesn't ship Chromium at all—instead, it rebuilds browser functionality on top of V8 isolates and WebAssembly within Cloudflare Workers. The goal is to reduce CPU and memory consumption when running large numbers of short-lived page fetches and screen renders.

AI agents that use browsers often don't need tabs, themes, or extensions. Meanwhile, the conventional Browser Run launches headless Chrome, meaning the compute resources required per agent constrain the degree of parallelism. Kitesurf trades away pixel-perfect rendering and broad compatibility in exchange for directing resources toward the work of machines reading pages, operating on them, and returning results. This trade-off shows up clearly in the official benchmarks.

AD

Lower CPU and memory, but higher latency

Cloudflare published median results from running Browser Run's Quick Actions five times against 14 URLs. The comparison point was an already-warmed-up Chromium instance. For screenshots, Kitesurf's CPU time was 380ms versus Chromium's 1,173ms. For HTML extraction, it was 229ms versus 877ms—meaning Kitesurf's CPU time came in at 26–32% of Chromium's.

Task Kitesurf Chromium
Screenshot CPU time 380ms 1,173ms
HTML extraction CPU time 229ms 877ms
Screenshot memory 57.8MiB 271.0MiB
HTML extraction memory 39.4MiB 273.7MiB
Screenshot elapsed time 1,148ms 637ms
HTML extraction elapsed time 820ms 472ms

The table makes the trade-off clear. Kitesurf's memory usage shrinks to 14–21% of Chromium's, but the time to receive results stretches to 1.7–1.8 times longer. Cloudflare explains this is because Kitesurf's cold software renderer is at a disadvantage compared to an already-warmed-up Chromium's JIT. This makes Kitesurf better suited to running many independent tasks under constrained resources, rather than opening a single page as fast as possible.

However, this measurement is based on 14 URLs that Cloudflare itself selected. The gap could shift depending on site complexity, cache state, and operation length. Since Kitesurf is free during the beta period, it also remains unclear how this resource difference will translate into pricing.

Splitting the browser into three parts within Workers

Kitesurf is built around three core components: Engine, which manages sessions; PageScript, which handles the document and scripts within a page; and PageRenderer, which converts the screen into an image. Only Engine, which handles external connections, retains session state; the other components remain as stateless as possible. If a process stalls, its isolate can simply be discarded and restarted, making it easy to scale the number of instances up or down to match workloads dominated by short-lived tasks.

A PageScript isolate is launched per page, separating HTML and JavaScript from other pages. For HTML and CSS parsing, Kitesurf adopts Blitz (written in Rust) and Stylo (derived from Firefox). Since Workers doesn't permit native eval, any JavaScript requiring eval runs through Boa JS, a Rust-based ECMAScript engine. PageRenderer is likewise separated, with Engine requesting rendering via inter-Worker RPC. Even if the rendering side hangs, it won't drag down the Engine that holds the page's state.

Network connections are also consolidated into a SandboxOutbound worker. No other component can connect directly to the internet; SandboxOutbound applies CORS, inspects responses, and maintains a per-page cookie jar. This reflects the need for a design that doesn't trust loaded pages by default, given that agents may visit arbitrary sites.

This separation narrows the resources a malicious page can touch and the blast radius of any failure. However, Cloudflare does not claim that Kitesurf prevents prompt injection. Isolation within the browser and the problem of an AI trusting instructions embedded on a page are separate issues that require independent verification.

AD

Choosing the engine from existing CDP connections

Browser Run, renamed from Browser Rendering in April 2026, is a service that runs headless Chrome on Cloudflare's network, controllable via Puppeteer, Playwright, or the Chrome DevTools Protocol (CDP). Kitesurf doesn't rebuild this control surface. By adding browser=kitesurf to existing CDP endpoints or Quick Actions, you can switch out just the execution engine.

Thanks to this compatibility layer, developers can choose between Chromium and Kitesurf on a per-task basis without rewriting their agent's control code wholesale. Connections are also possible from agents that support MCP and CDP. A practical approach would be to route short HTML extractions and screenshots to Kitesurf, while keeping long-running authenticated sessions that maintain state, or tasks requiring high rendering fidelity, on Chromium.

Kitesurf is offered within Browser Run as a beta, currently free but subject to per-account limits. More significant than the free pricing is the fact that a lightweight engine can now be selected behind the same API. For Cloudflare too, this creates a path for scaling up concurrent agent execution that doesn't depend solely on securing more Chromium instances.

Passing conformance tests doesn't guarantee real-world sites

According to official documentation updated on August 7, Kitesurf passes over 235,000 subtests in the Web Platform Tests (WPT). It covers 97% of DOM, 96% of HTML, and 95% of XHR, while URL coverage stands at just 83%. WPT measures conformance to web standards, but it doesn't guarantee that any given real-world site will render correctly or remain operable through to completion.

At present, Kitesurf doesn't support video or WebGL, nor can it handle bot challenges that rely on real TLS fingerprints. It's also poorly suited to long-running authenticated sessions that maintain state—for such tasks, the default Chromium option in Browser Run is recommended. CDP implementation remains partial as well, and fidelity for screen and PDF rendering is still under development.

Cloudflare has indicated it plans to open-source Kitesurf once it's ready, allowing customers to deploy it within their own accounts. However, no release date, timeline for general availability, or post-beta pricing has been disclosed. The deciding factor for adoption won't be the WPT pass count, but rather whether comparing completion rates and elapsed time against Chromium on your own target sites—factoring in retries on failure—shows that the lighter resource footprint actually pays off.