Kitesurf is a browser engine Cloudflare built from scratch for AI agents. Rust compiled to WebAssembly, running inside Workers V8 isolates, no Chromium anywhere. Announced on 6 August 2026 by Celso Martinho, free while in beta through Browser Run.
The argument behind it is simple. Every agent framework today drives a headless Chromium, and Chromium was built for a person looking at a screen. Agents do not need tabs, themes, extensions, device sync or 60-fps scrolling. They need machine-readable content, low token counts and isolation against a hostile page. Everything Chromium spends resources on beyond that is billed to you and thrown away.
For business people
If you run agents that browse the web, this changes your bill, not your code.
The problem it solves. Browser automation is the most expensive part of most agent stacks. Every Chromium instance is a heavy process holding a lot of memory. When a hundred agents each need a page rendered, you are paying for a hundred full browsers to do work a fraction of which the agent actually consumes.
The value. Kitesurf uses 3 to 7 times less CPU and memory than Chromium for the two things agents do most: take a screenshot, and extract the HTML. Less memory per session means more sessions per machine, which means lower cost per task at scale.
The trade. It is roughly 1.7 to 1.8 times slower on wall-clock time. A warm Chromium with a JIT that has already seen the page beats a cold software renderer. If your workload is one agent doing one thing, you will feel that. If it is thousands of one-shot tasks, the resource win dominates.
Cost. Free during beta, behind per-account limits, through Browser Run. No separate product to buy.
When to choose it. Content extraction, PDF and screenshot generation, one-shot page reads. Stay on Chromium for video, WebGL, sites that fingerprint TLS to block bots, and anything needing a long authenticated session.
The strategic bit. Cloudflare says it will open source Kitesurf and let customers self-host. That is worth watching if you would rather not build your agent infrastructure on a single vendor's endpoint.
For technical people
Four Workers, each stateless where it can be, each with the minimum access it needs.
| Component | Job |
|---|---|
| Engine | The only public-facing Worker. Speaks CDP over WebSocket, holds session state, orchestrates the rest |
| PageScript | Fresh isolate per page via Worker Loader. Parses HTML and CSS, builds the DOM, runs page JS |
| PageRenderer | Turns the computed page into pixels. Returns PNG or JPEG. No network access at all |
| SandboxOutbound | The single network gateway. Enforces CORS, headers, cookies and response filtering |
Parsing and rendering lean on existing Rust crates rather than a bespoke engine. Blitz handles HTML and layout, Stylo (Firefox's CSS engine) handles styles, and blitz-paint rasterises with Parley for text shaping and Vello for the raster. Everything compiles to Wasm with wasm-bindgen rather than Emscripten, to skip the emulation layers.
The eval problem is the fun one. Workers do not allow dynamic code evaluation, and you cannot hand eval() to a second isolate because it would lose access to globalThis. Cloudflare's fix: run Boa JS, an ECMAScript engine written in Rust, inside the isolate. A JavaScript runtime running inside a JavaScript runtime. Their own words: "which doesn't seem optimal, and it isn't, but it works well enough".
Workers RPC does the cross-isolate plumbing. The Engine calls renderFrame() on PageRenderer and gets a PNG back in one call. Because the renderer holds no page state, the Engine can kill and relaunch it on any stuck call. Every render is self-contained, retryable and disposable.
Network isolation
Every page load is treated as untrusted input and every session starts fresh. The renderer is denied the network outright.
This matters more than it first looks. The threat model for an agent browser is not the same as for a human one. A person visits sites they chose; an agent is pointed at whatever the task demands. Prompt injection and tool safety move to the top of the list, and the answer here is architectural rather than a filter.
Using it
Add browser=kitesurf to any Browser Run CDP or Quick Action endpoint. Existing Puppeteer, Playwright and chrome-remote-interface clients work unchanged.
curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot?browser=kitesurf' \
-H 'Authorization: Bearer <apiToken>' \
-H 'Content-Type: application/json' \
-d '{"url": "https://example.com"}' \
--output "screenshot.png"
For an MCP client, point chrome-devtools-mcp at the CDP WebSocket:
{
"mcp": {
"kitesurf": {
"type": "local",
"command": [
"npx", "-y", "chrome-devtools-mcp@latest",
"--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
"--wsHeaders={\"Authorization\":\"Bearer <API_TOKEN>\"}"
],
"enabled": true
}
}
}
Benchmarks
Medians of five Browser Run quick-action runs across a 14-URL corpus, Kitesurf against a warm Chromium pool.
| Metric | Kitesurf | Chromium | Delta |
|---|---|---|---|
| CPU, screenshot | 380 ms | 1,173 ms | 3.1x less |
| CPU, HTML extraction | 229 ms | 877 ms | 3.8x less |
| Memory, screenshot | 57.8 MiB | 271.0 MiB | 4.7x less |
| Memory, HTML extraction | 39.4 MiB | 273.7 MiB | 7.0x less |
| Wall time, screenshot | 1,148 ms | 637 ms | 1.8x slower |
| Wall time, HTML extraction | 820 ms | 472 ms | 1.7x slower |
It passes 215,000+ Web Platform Tests, with the areas agents care about already well covered: DOM 97%, HTML 96%, Selection 99%, SVG 97%, Encoding 99%, CORS 95%, XHR 95%, URL 83%. It also runs Doom, which the team treats as the real acceptance test.
How it was built
This part is the actual story. Twelve weeks from idea to launch, and Cloudflare is open that AI agents wrote much of it.
The seed was obscura, a Rust headless engine for AI automation with "no Chrome, no Node.js, no dependencies". Someone tried porting it to Workers with an agent. The first attempt failed. Once they gave the agent a real plan and a clear definition of success, it worked.
That definition of success is the interesting bit: the Web Platform Tests became the objective function. A standards suite with tens of thousands of pass-or-fail criteria is exactly the goalpost an agent loop needs. Humans curated which features to assign and in what order, then reviewed architecture while agents ground through conformance. They backed it with visual regression tests running the same Puppeteer scripts against Chromium and Kitesurf and diffing the rendered output at every step.
Worth stealing as a pattern. Agents are good at grinding toward a machine-checkable target and bad at deciding what the target should be. WPT is a rare case where somebody else already wrote 215,000 tests for you.
What it cannot do
- Play video or render WebGL.
- Negotiate a bot-challenge handshake with a real TLS fingerprint.
- Hold a long-running authenticated session that needs persistent state.
- Match Chromium on pixel fidelity or wall-clock speed.
My take
The efficiency numbers are good, but the reusable lesson is the build method. Pick a domain that already has an exhaustive machine-checkable test suite, point agents at it, keep humans on architecture and review. That is a template, not a one-off.
The rest is Cloudflare doing what Cloudflare does: notice that everyone is paying for a general-purpose thing to do a narrow job, then ship the narrow version on infrastructure they already own. If the open-source and self-host promise lands, this becomes the default way agents read the web.