Cloudflare Kitesurf: Agent-First Browser Guide

Cloudflare Kitesurf is an experimental browser engine for AI agents. It speaks enough of the Chrome DevTools Protocol (CDP) to work with familiar automation clients, but it replaces a long-lived Chromium process with isolated Workers components designed to exist for one task.

That trade changes the buying question. Kitesurf is not trying to win a pixel-perfect browser benchmark. It is trying to reduce the CPU and memory cost of high-volume extraction, screenshot, and PDF jobs where agents can tolerate incomplete browser compatibility.

Fast decision:

• Use Kitesurf for bursty, one-shot browsing on compatible sites.
• Keep Chromium for video, WebGL, bot challenges, and long authenticated sessions.
• Measure successful task cost, not browser startup alone.
• Route failures to Chromium instead of forcing one engine everywhere.

What Kitesurf is

Kitesurf is a Rust-heavy browser implementation compiled to WebAssembly and distributed across Cloudflare Workers. Cloudflare built it after observing that agent browsing often needs DOM access, network inspection, HTML extraction, screenshots, and PDFs—but not tabs, extensions, smooth scrolling, or perfect visual fidelity.

It retains a CDP surface so existing tools do not need an entirely new control protocol. Cloudflare explicitly names Puppeteer, Playwright, chrome-remote-interface, Chrome DevTools, and CDP-speaking agent tools as intended clients. Compatibility at the protocol layer does not mean behavioral parity with Chrome: Kitesurf currently implements the subset needed for its target tasks.

The launch post says the project began about 12 weeks before release and uses curated Web Platform Tests, real-site integration tests, and visual regression tests against Chromium. Cloudflare reported more than 215,000 passing WPT tests at launch, while also describing the engine as early-stage.

How Kitesurf works

Kitesurf separates a session into four trust and execution roles.

The Engine is the stable control surface. Other components communicate through Workers RPC. If a stateless renderer stalls or fails, the Engine can discard it and retry without rebuilding a long-lived browser process.

PageScript combines Rust browser components with a Worker isolate. Cloudflare says it uses parts of Blitz for HTML and CSS processing and Firefox's Stylo CSS parser. Page JavaScript and WebAssembly run in the page isolate. Because Workers did not natively support eval at launch, Kitesurf uses the Rust-based Boa JavaScript engine for occasional eval paths—an acknowledged compatibility and performance compromise.

SandboxOutbound centralizes network authority. It applies CORS rules, browser-shaped headers, response filtering, and per-page cookie jars. Dynamic Worker boundaries prevent the Engine, renderer, and page components from making unrestricted outbound requests directly.

This architecture is built around two principles:

1. Every page load is untrusted input and begins with a fresh boundary.
2. Components should be stateless where possible so burst capacity and retries are cheap.

That is a useful design for one-shot tasks, but it works against use cases that depend on durable browser identity or a long interactive session.

Read the benchmark correctly

Cloudflare compared the medians of five Browser Run quick-action runs over a 14-URL corpus. Chromium used a warm pool; Kitesurf used its task-oriented path.

These are Cloudflare's measurements, not independent results. The table supports a narrower conclusion than “Kitesurf is faster”: it used materially fewer compute resources for the tested tasks but completed them more slowly than warm Chromium.

For an agent fleet, benchmark these four numbers together:

• successful tasks per CPU-hour;
• peak memory per concurrent session;
• median and tail task latency;
• fallback rate to Chromium.

A low-resource engine that fails 20% of target pages can cost more than Chromium after retries. A slower engine that cuts memory enough to raise safe concurrency may still win on throughput and price.

Kitesurf vs Chromium

Cloudflare lists TodoMVC implementations, Wikipedia, Hacker News, its blog, and much of its dashboard among working examples. That is evidence of useful coverage, not a general compatibility guarantee.

Try Kitesurf

Browser Run selects Kitesurf with the browser=kitesurf query parameter. A screenshot request has this shape:

curl -X POST \
  'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \
  -H 'Authorization: Bearer <API_TOKEN>' \
  -H 'Content-Type: application/json' \
  -d '{"url":"https://example.com"}' \
  --output screenshot.png

Expected output: screenshot.png is written when the target is compatible and the account token can access Browser Run.

For an MCP client, Cloudflare documents putting chrome-devtools-mcp in front of the Browser Run WebSocket endpoint:

{
  "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
    }
  }
}

Expected output: the MCP client exposes CDP-backed browser tools and connects sessions to Kitesurf rather than the default Chromium engine.

Do not place the token in a committed config. Inject it through a secret manager or generated local configuration, and scope it to the minimum account permissions required.

Build a fallback strategy

A production rollout should treat browser choice as routing, not ideology.

1. Create a representative corpus. Include login flows, dashboards, SPAs, static pages, PDFs, consent screens, and known anti-bot paths.
2. Define task assertions. Check the extracted fields, screenshot dimensions, expected DOM nodes, console errors, and action outcomes.
3. Run both engines. Record CPU, memory, wall time, and semantic success—not just HTTP status.
4. Classify durable failures. Route unsupported APIs, WebGL, media, fingerprint challenges, and persistent-session jobs directly to Chromium.
5. Add a bounded fallback. Retry once in Chromium after a compatibility failure; avoid loops between engines.
6. Track drift. Websites and Kitesurf both change. Re-run canaries before expanding the allowlist.

A simple policy might start Kitesurf only for known domains and task types. Broaden the allowlist when data shows success; do not make Kitesurf the default solely from the launch resource table.

Security checklist

Kitesurf's component isolation reduces some blast radius, but it does not make web content trustworthy.

• Treat page text as untrusted data that may contain prompt injection.
• Keep credentials out of page prompts and screenshots.
• Restrict which domains an agent may visit and what data it may send.
• Require human approval for purchases, publishing, account changes, and destructive actions.
• Redact logs and captured pages that contain personal or confidential data.
• Validate downloaded files separately; browser isolation is not file-content validation.
• Expire sessions and tokens aggressively.
• Monitor Chromium fallback rates for security-sensitive sites rather than weakening controls to improve compatibility.

Verdict

Kitesurf is a credible new execution class, not a universal browser replacement. Its strongest case is a large volume of short, tested agent tasks where memory and CPU determine concurrency and where slightly slower or imperfect rendering is acceptable.

Keep Chromium beside it. The safe architecture is a measured Kitesurf allowlist with explicit assertions and a bounded Chromium fallback. Revisit that split as CDP coverage, rendering fidelity, open-source availability, and production readiness improve.

FAQ

Sources and links

• Cloudflare: Introducing Kitesurf
• Cloudflare Browser Run changelog
• Cloudflare Agents browser documentation
• Cloudflare Developers launch post