Kitesurf: Cloudflare's browser for AI agents
Kitesurf is interesting because it asks what a browser should look like when the primary user is an agent, not a human.
Chromium uses 271 MB of memory to take a screenshot. An agent that browses the web thousands of times a day doesn’t need tabs, themes, or pixel-perfect rendering — it needs that number to be 58 MB.
Source
Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers
By: Cloudflare
Published: Aug 06 2026
Type: Product announcement
This matters because it asks a question most browser automation tools skip: what should a browser look like when the primary user is an agent, not a human? Kitesurf rebuilds the browser from scratch around that constraint.
What changes when the browser user is an agent
Cloudflare had shelved the “should we build our own browser” question multiple times over the years. What changed was a collision: Workers’ technical capabilities matured (WebAssembly support, dynamic workers, SQLite-based Durable Objects, Worker-to-worker RPC) at the same time as agent demand for browsers hit critical mass through Browser Run.
The core observation is that Chromium was built for humans and carries overhead agents don’t need. Agents don’t care about tabs, themes, browser extensions, or synchronised bookmarks. They care about token count, context windows, scalability, performance, and cost. Structured, machine-readable content matters; pixel-perfect 60fps scrolling doesn’t. And the threat model is different — prompt injection and tool safety replace phishing and drive-by downloads as the primary concerns.
Kitesurf is the result: a browser written primarily in Rust, compiled to WebAssembly, running entirely inside V8 isolates on Workers. Built in 12 weeks, available free in beta through Browser Run.
The architecture has three main components. The Engine is the only public-facing worker. It handles the Chrome DevTools Protocol (CDP) WebSocket and REST APIs, and stores session state. CDP compatibility means Puppeteer, Playwright, and the actual Chrome DevTools frontend all work — point them at Kitesurf and they connect without changes.
PageScript handles HTML parsing and JavaScript execution. Each page or out-of-process iframe spins up a Dynamic Worker isolate with a clean globalThis and DOM. HTML and CSS parsing use parts of Blitz (a modular rendering engine) and Stylo (Firefox’s CSS parser), both in Rust. JavaScript runs inside the same isolate; for eval() calls — which Workers doesn’t support natively — they run Boa JS, an ECMAScript engine in Rust, essentially a runtime on top of a runtime. Not optimal, but functional until native eval support lands.
PageRenderer turns the computed page into pixels. It receives the page object from PageScript, fetches fonts and images from static assets, rasterises everything into an image buffer, and returns it as JPEG/PNG or PDF. It holds no page state — only a disposable cache — so the Engine can kill and relaunch it on any stuck call, making each render request self-contained and retryable.
Network access is locked down through a single SandboxOutbound worker. Nothing else touches the network directly, enforced by Dynamic Workers. It handles CORS, browser-shaped headers, response filtering, and per-page cookie jars. Anything failing policy gets a 403.
The design decisions tell you as much as the architecture. Stateless whenever possible — if there’s nothing to reconstruct, recovery is just starting a new isolate. Every page load treated as untrusted input. And tests as the primary quality mechanism: they used the Web Platform Tests (215,000+ passing and growing), combined with integration and visual regression testing against real websites, comparing Kitesurf to Chromium at every step. This made it possible to use AI agents for acceleration while keeping quality under control — the WPT suite gave agents clear goalposts.
The benchmarks are revealing. Across a 14-URL corpus, Kitesurf uses 3.1× less CPU for screenshots and 3.8× less for HTML extraction than Chromium. Memory is the bigger win: 57.8 MB vs 271 MB for screenshots (4.7× less), 39.4 MB vs 273.7 MB for HTML extraction (7× less). Chromium wins on wall-clock time by about 1.7× because its JIT always beats a cold software renderer — but memory and CPU are what drive the bill when you’re running thousands of concurrent sessions.
My take
The subtlety here is that Kitesurf doesn’t have to be a better browser than Chromium — it has to be a better browser for agents. The 7× memory advantage isn’t about being faster at rendering; it’s about running 7× more concurrent sessions at the same cost. That changes the economics of any system where agents browse the web at scale. The risk is standards conformance: 215,000+ WPT tests pass, but the real web is messier than the WPT suite, and agents hitting pages with edge-case CSS or JavaScript will eventually find gaps. The hybrid approach — Kitesurf for cheap bulk work, Chromium through Browser Run for cases that need full fidelity — is probably the practical answer for a while.
Where this is useful
- When you need agents browsing the web at scale and Chromium’s memory footprint is the limiting factor — Kitesurf’s 4-7× memory reduction directly increases concurrent capacity.
- When building agent pipelines that mostly need HTML extraction and screenshots rather than full interactive browsing — the CPU savings compound fast.
- When your threat model includes agents visiting arbitrary untrusted pages — the isolation-by-default design with no cross-session state is a meaningful security baseline.
Apply this: If your agents use headless Chromium, benchmark your per-session memory. If it’s the capacity bottleneck, Kitesurf’s lighter approach is worth testing for your bulk scraping and screenshot workloads.
What I want to remember
Remember: When the user changes, the product should change. A browser for agents optimises for tokens, memory, cost, and isolation — not tabs, themes, and pixel-perfect rendering. The right trade-off is less fidelity for 7× more concurrent sessions.