Cloudflare released Kitesurf — a browser that is not Chromium and generally does not contain an engine in the usual sense. It runs on top of Workers, in isolated V8 sandboxes, and is designed not for humans but for AI agents and scripts. The claim sounds loud, so let’s break down what is inside, what numbers the company shows (and why these numbers are the vendor’s), and most importantly — in which tasks it makes sense to use it instead of the usual Playwright + headless Chromium combo, and in which it is completely useless.
What it is made of
Kitesurf is split into three parts, each a separate component on Workers:
- Engine — accepts connections via the Chrome DevTools Protocol (the same CDP as Puppeteer and Playwright) and HTTP API, keeps the session state.
- PageScript — for each page raises a separate long-lived isolate via Dynamic Workers. HTML is parsed by the Blitz parser, CSS — Stylo, the same stylesheet engine from Firefox, written in Rust.
- PageRenderer — turns the computed tree into pixels: rendering via blitz-paint, font shaping via Parley, outputting a raster buffer.
Key architectural decisions — state-free components (one-shot, horizontally parallel), each page load is considered untrusted and isolated, heavy parts written in Rust and compiled to WebAssembly.
In simple terms: instead of running a full browser with tabs, extensions, compositing and 60 fps to fetch text from a page, Cloudflare built a conveyor belt “HTML → CSS → layout → image” from ready-made Rust bricks and ran it in the same sandbox where Workers live. For an agent that needs text or a single screenshot, the rest of the browser is overhead.
Request lifecycle: Engine → PageScript → PageRenderer. Illustration by Cloudflare
Vendor numbers
Cloudflare provides measurements on a sample of 14 URLs. Note: this is the vendor’s benchmark on its own sample; independent confirmation is not yet available.
| Metric | Kitesurf | Chromium | Difference |
|---|---|---|---|
| CPU, screenshot | 380 ms | 1,173 ms | ×3.1 in favor of Kitesurf |
| CPU, HTML extraction | 229 ms | 877 ms | ×3.8 |
| Memory, screenshot | 57.8 MiB | 271.0 MiB | ×4.7 |
| Memory, HTML extraction | 39.4 MiB | 273.7 MiB | ×7.0 |
| Wall-clock, screenshot | slower | faster | ×1.8 in favor of Chromium |
The last line is the most honest part of the publication, and Cloudflare does not hide it: by “wall time” Chromium is almost twice as fast. The company’s argument is that you are charged for CPU time and memory, not for a stopwatch. This is true for their own Workers billing — and, importantly, less true for you if you run a parser on your own hardware, where seconds also cost money.
Compatibility: claimed to pass around 215,000 Web Platform Tests, with a focus on CSS, DOM, HTML, text selection, SVG and XHR.
Decision matrix
It’s most useful to break this down by task. The limitations of Kitesurf were listed by the company itself, and they are strict: no video playback, no WebGL, no anti-bot challenge handling with real TLS fingerprints, no saving of authorized sessions with state.
| Task | Do with | Why |
|---|---|---|
| Screenshot or static page PDF | Kitesurf | Exactly the scenario it was built for |
| Extract text/HTML for RAG or agent | Kitesurf | Best memory footprint, ×7 by claimed data |
| Mass crawl of tens of thousands of URLs | Kitesurf | CPU and memory gains scale, wall-clock offset by parallelism |
| SPA that renders content only after hydration | Chromium | Full JS runtime and load timeline |
| Site behind anti-bot protection | Chromium (and not guaranteed) | Kitesurf is declared unable to pass TLS fingerprint challenges |
| Logged-in work, carts, multi-step forms | Chromium | Session state is not preserved |
| Video, WebGL, canvas graphics | Chromium | Not supported |
| Anti-detect and multi-accounting | Neither | Requires controlled fingerprint — a separate class of tools |
Separately, for those who came here from parsing: Kitesurf is not a tool for bypassing protections. It does not emulate a real browser fingerprint; on the contrary — it is honest about behaving as a cloud client of Cloudflare. If your scenario today relies on spoofing JA3/JA4, user-agent and WebGL fingerprint, Kitesurf will not suit you in any way.
Irony and practical meaning
An amusing detail: Cloudflare sells site protection from bots (including paid access for AI crawlers) and a browser for AI agents that visits those sites. The contradictions here are smaller than they seem — the company is steadily building a model where “agents traverse the web legally and recognizably, not pretending to be humans.” Kitesurf with its lack of masking fits perfectly with this: it is optimized for sites that agree to visit by an agent.
For our audience the practical takeaway is this. If you are building an agent pipeline — web search for local LLM, filling a RAG database, regular dashboard screenshots — Kitesurf is worth trying: CDP access means your existing Puppeteer or Playwright code can switch by setting the parameter browser=kitesurf, there are REST endpoints for Quick Actions for one-step operations and an MCP interface for agents.
curl -X POST \
'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot?browser=kitesurf' \
-H 'Authorization: Bearer <apiToken>' \
-d '{"url": "https://example.com"}'
During the beta it’s free with account limits. What will happen with price after the beta is not announced, and this is the main unknown parameter in any cost calculations.
Healthy strategy is not to “move entirely to Kitesurf,” but two-tier: first a cheap try via Kitesurf, if it fails (empty DOM, challenge, login required) — fallback to a full Chromium. This way you reduce resource gains for the mass of simple pages and do not lose the complex ones.
Sources
- Cloudflare Blog — Kitesurf: agent-first browser — primary source, architecture, benchmarks and stated limitations
- Discussion on Hacker News — independent developer reactions
- Related forum thread: 99% of traffic — bots: eight barriers to site defense — a perspective from the other side of the barricade
Who has already tried running agents on the web in production — what did you settle on: your own headless Chromium in Docker, cloud rendering, or a self-written HTTP client with a parser? And how many pages do you end up losing to anti-bot protection?