Kitesurf: A Browser Built for AI Agents, Not People

A browser is an expensive way to fetch a page.

That sounds unfair because a modern browser does far more than fetch. It decodes video, drives a GPU, manages tabs and extensions, keeps years of local state, synchronizes profiles, paints smooth animations, exposes accessibility APIs, and survives almost every strange page the web can produce. People need that breadth. An AI agent that wants a product price, a documentation section, or a screenshot often does not.

Kitesurf starts from that mismatch. Cloudflare has built a new browser engine for automation, running on V8 isolates inside Workers. It speaks familiar automation protocols, executes page JavaScript, builds a DOM, applies CSS, and can return HTML, screenshots, or PDFs. But it deliberately gives up the promise of being a complete desktop browser.

The result is not “Chromium, made smaller.” It is a different answer to a narrower question: what is the minimum useful browser for a machine?

Why agents need a different browser budget

Chromium is the safe default for browser automation because compatibility matters. If a site works in Chrome, it will probably work in headless Chrome. The cost appears when the workload becomes large and bursty.

Imagine an agent service that receives ten thousand requests to inspect pages. Giving each request a conventional browser process means paying for a general-purpose human interface even when the task only needs a DOM query. Warm browser pools reduce startup time, but they keep memory allocated between tasks and create state-management work of their own.

An agent has different priorities:

• It values structured DOM content, network activity, forms, and screenshots.
• It needs automation protocols more than tabs, themes, or extensions.
• It can tolerate small rendering differences when extracting text or finding controls.
• It benefits from short-lived, isolated sessions because every page is untrusted.
• It needs predictable CPU, memory, and context costs at large concurrency.

Kitesurf optimizes for those priorities. It is an ephemeral engine meant to exist for one task, disappear, and scale out again when the next burst arrives.

That focus is important. A browser made for agents is not necessarily a browser that imitates a person more convincingly. Kitesurf is designed to expose the web as a computable environment, not to hide automation from websites.

A browser split across isolates

Kitesurf divides a page session into a small set of components. Only one of them owns durable session state; the rest are designed to be disposable.

SandboxOutbound: one guarded path to the network

Rendering a page means downloading hostile input: HTML, scripts, stylesheets, fonts, images, and WebAssembly. Kitesurf does not let every component fetch those resources directly. A dedicated SandboxOutbound Worker is the only route to origins.

That boundary enforces CORS, adds browser-shaped headers, filters responses, and keeps cookies in a jar scoped to the page. A disallowed request receives a 403. The design turns network access into an explicit capability instead of ambient power shared by the whole browser.

This is useful beyond browser engineering. Agent systems are safer when the component interpreting untrusted content is not also the component holding unrestricted credentials and network access. Isolation does not solve prompt injection, but it reduces the number of paths through which a bad page can become a broader systems problem.

Engine: protocol gateway and session owner

The Engine is Kitesurf’s public face. It accepts Chrome DevTools Protocol (CDP) connections over WebSocket and HTTP, coordinates a page, and stores session state.

Choosing CDP gives Kitesurf immediate access to an existing ecosystem. Puppeteer, Playwright, chrome-remote-interface, Chrome DevTools, and MCP adapters already know how to talk to that protocol. A developer can point an existing client at a Kitesurf endpoint rather than learning a product-specific action language.

The tradeoff is that Kitesurf implements only a subset of CDP today. The launch discussion also raised the longer-term question of WebDriver BiDi, the standards-based bidirectional automation protocol. CDP is the pragmatic compatibility layer now; broader standardized inspection coverage would be a valuable future direction.

PageScript: one clean JavaScript world per page

Each top-level page or out-of-process iframe gets a long-lived PageScript isolate created through Dynamic Workers. That isolate owns a clean globalThis, a DOM document, and the page’s JavaScript and WebAssembly execution.

Kitesurf assembles rather than reinvents every layer. It uses parts of Blitz, a modular Rust HTML and CSS engine, along with Stylo, the CSS engine also used by Firefox and Servo. Blitz’s unusually loose coupling is a good match: parsing, networking, rendering, windowing, scripting, style, layout, and text shaping can be composed without adopting one monolithic browser process.

There is an awkward exception. Workers does not natively permit eval, while real websites sometimes depend on it. Kitesurf currently runs those cases through Boa, a JavaScript engine written in Rust and compiled for Workers. Running one JavaScript runtime inside another is not elegant or cheap, but it fills a compatibility hole until native support changes.

This is a recurring browser-engine lesson: the long tail matters. A clean architecture still needs deliberate fallbacks for web behavior that cannot simply be wished away.

PageRenderer: turn a scene into pixels

PageRenderer receives the computed page scene, loads required fonts and images, rasterizes the result, and returns a PNG, JPEG, or PDF buffer. Blitz Paint handles much of the painting work, while Parley handles text shaping, font selection, glyphs, and line breaking.

The Engine calls the renderer through Workers RPC. PageRenderer keeps no important page state, only a disposable cache. If rendering stalls or fails, the Engine can kill that isolate, start another, and retry the frame without reconstructing the entire session.

That separation is the architectural center of Kitesurf. Stateful work is kept narrow; expensive stateless work can be replaced. Failures degrade into a missing element, blank frame, or retried render instead of taking the whole session down.

Tests are the map for a new engine

Building a browser in twelve weeks would be reckless without a machine-readable definition of progress. Kitesurf uses the Web Platform Tests, the shared cross-browser suite for standards behavior, as that definition.

Cloudflare reported more than 215,000 passing WPT tests at launch, with strong coverage in areas useful to agents: HTML, DOM, CSS, selection, SVG, XHR, and streams. The team used AI coding agents to accelerate implementation, but humans chose the feature order, reviewed approaches, and supplied tests as concrete acceptance criteria.

WPT is necessary, not sufficient. A standards test can prove that an API behaves correctly without proving that a complicated production site works. Kitesurf therefore also uses multi-step Puppeteer integration tests against real websites and visual regression comparisons with Chromium. That catches the gap between isolated conformance and an actual page assembled from thousands of interacting assumptions.

This combination is a practical template for AI-assisted infrastructure work:

1. Define behavior with a large conformance suite.
2. Let agents work inside bounded, testable slices.
3. Review architecture and sequencing with humans.
4. Compare the result against real workloads, not only unit tests.
5. Track the missing surface explicitly instead of declaring parity too early.

The novelty is not that AI “built a browser.” The useful lesson is that mature tests turned an enormous problem into many measurable loops.

For the traditional browser-engine milestone, Cloudflare also ran a WebAssembly port of Doom inside Kitesurf. It is a playful demo, but it exercises enough scripting, layout, input, and rendering behavior to expose problems that isolated conformance cases can miss.

The benchmark result is a trade, not a victory lap

Cloudflare compared median results from five Browser Run quick-action executions over a 14-URL corpus. Its launch numbers were:

Task	Kitesurf	Warm Chromium	Difference
Screenshot CPU	380 ms	1,173 ms	3.1× less CPU
HTML extraction CPU	229 ms	877 ms	3.8× less CPU
Screenshot memory	57.8 MiB	271.0 MiB	4.7× less memory
HTML extraction memory	39.4 MiB	273.7 MiB	7.0× less memory
Screenshot wall time	1,148 ms	637 ms	1.8× slower
HTML extraction wall time	820 ms	472 ms	1.7× slower

These are vendor measurements from a small corpus, not a universal browser benchmark. They still show the intended exchange clearly. Kitesurf reduces CPU and memory by several times, while a warm Chromium pool finishes the measured tasks faster.

For an interactive request, latency may matter most and Chromium can remain the better choice. For a burst of independent extraction jobs, memory density and CPU cost can dominate. A system that can run more concurrent sessions on the same budget may complete the whole queue sooner even if each individual session takes longer.

The right comparison is therefore workload-level:

• How many pages are processed per dollar?
• What percentage of target sites render correctly?
• How often does a task fall back to Chromium?
• Does the output need pixel fidelity or only structured content?
• Is the session short and disposable, or logged in and long-lived?

“Lightweight” is not a sufficient buying criterion. Compatibility failures and retries can erase infrastructure savings.

Existing tools can opt in

Kitesurf is available in Cloudflare Browser Run during its beta. Browser Run supports quick, stateless actions such as screenshots and extraction, plus full sessions through Playwright, Puppeteer, and CDP.

For compatible CDP clients, the switch is deliberately small: add browser=kitesurf to the endpoint. The same idea works through chrome-devtools-mcp, allowing an MCP-capable coding agent to connect without a Kitesurf-specific tool vocabulary.

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

Quick Actions use the same selector. That makes gradual adoption possible: send known-compatible screenshot or extraction tasks to Kitesurf and preserve Chromium as the fallback for everything else.

Where Kitesurf fits today

At launch, Cloudflare says Kitesurf can render sites including Hacker News, Wikipedia, the Cloudflare Blog, TodoMVC implementations across several frameworks, and much of its own dashboard. That is enough for meaningful experiments, but not blanket production compatibility.

Kitesurf is a plausible fit for:

• One-shot HTML or text extraction from compatible sites
• Large batches of screenshots where small visual differences are acceptable
• PDF generation for pages covered by tests
• Short agent tasks using DOM and network inspection
• Sandboxed browsing of unknown pages without shared session state
• Workloads where CPU and memory density matter more than single-request latency

It is not the right engine today for:

• Video playback
• WebGL applications
• Pixel-perfect screenshot testing across the entire web
• Bot challenges that depend on authentic browser TLS fingerprints
• Long authenticated sessions that must preserve state
• Sites that depend on missing web APIs or unsupported CDP commands

Those are not minor footnotes. Authentication, anti-bot checks, and complex application state are central to many real browser agents. Cloudflare explicitly recommends Browser Run’s Chromium default for such cases.

Browser Run traffic also does not receive a secret passage through Cloudflare protection. In the HN discussion, a Cloudflare engineer said both Chromium and Kitesurf traffic is identified as bot traffic. The Browser Run changelog documents signed Web Bot Auth headers, which let origins identify the service rather than disguise it as a person.

A practical routing strategy

The strongest production design is likely hybrid, at least while Kitesurf matures.

Start with an allowlist of tasks and sites known to work. Send extraction, simple navigation, and one-shot rendering to Kitesurf. Record compatibility failures, missing protocol calls, rendering differences, and total retries. Route a task to Chromium when it requires video, WebGL, a durable login, an unsupported API, or strict visual fidelity.

Treat the fallback rate as a first-class metric. If 70 percent of jobs use one-seventh the memory but the other 30 percent retry twice before falling back, the real savings are smaller than the headline benchmark suggests. Measure the complete path.

Also keep credentials outside page execution. Use scoped bindings or a controlled proxy to inject authorization only for approved destinations. Destroy the session after the task. A fresh isolate is valuable, but it does not replace domain policy, output validation, rate limits, or human confirmation before consequential actions.

Finally, test your own corpus. Cloudflare provides a public playground with DevTools and memory inspection, but a handful of representative pages is more useful than a generic demo. Build fixtures for the sites, controls, and outputs your agents actually touch.

The bigger idea: purpose-built web runtimes

Kitesurf matters even if it never replaces Chromium for most automation.

For years, browser automation has inherited the architecture of a human browser because that was the only compatible implementation available. Agent workloads are now large enough to justify another layer: purpose-built runtimes that implement the parts of the web their tasks need, expose standard interfaces, and fall back when the long tail wins.

The modular pieces are as important as the product. Blitz supplies decomposed HTML, CSS, layout, and painting machinery. Rust and WebAssembly bring those pieces into Workers. Dynamic Workers create isolated page worlds. RPC connects disposable renderers. CDP lets existing tools arrive without a new integration.

Cloudflare plans to improve CDP coverage, rendering fidelity, WPT results, and efficiency, and says it intends to open-source Kitesurf when ready. Until that happens, the product should be evaluated as an early hosted beta with vendor-reported performance, not as an independently auditable browser engine.

Still, the direction is compelling. The web does not have to be presented to every consumer through the same heavyweight machine. People need a browser that feels like an operating system. Many agents need something closer to a safe, temporary compiler from URLs to structured state and pixels.

Kitesurf is the first serious attempt to make that distinction operational at edge scale.