What Is Kitesurf? Cloudflare's Browser for AI Agents

What Is Kitesurf? Inside Cloudflare's Browser Built for AI Agents

Short answer: Kitesurf is a browser from Cloudflare built to be driven by AI agents instead of people. It launched on August 6, 2026, runs inside Cloudflare Workers, and is still free during its beta through Browser Run. Since a September 28 update it also supports WebMCP, works with CDP, Playwright, Puppeteer and MCP across the whole Browser Run API, and can even render pages in your terminal.

Kitesurf is a browser Cloudflare shipped on August 6, 2026, built specifically to be driven by an AI agent instead of a human. It's not a trimmed-down Chromium and it's not a wrapper around Puppeteer. It's a purpose-built engine that runs entirely inside V8 isolates on Cloudflare Workers. In Cloudflare's launch benchmark it used between 3.1x and 7.0x less CPU and memory than Chromium on screenshots and HTML extraction, while finishing those tasks more slowly. It's free during beta through Browser Run, Cloudflare's service for running browsers on demand, and tools that already speak CDP or MCP (Puppeteer, Playwright, chrome-remote-interface) connect to it by adding one parameter to the endpoint.

If you're shipping agents that touch the web, research agents, scrapers, form-filling bots, visual QA pipelines, this matters directly, because it resets the cost math everyone quietly assumed: that "browser automation" meant "headless Chromium in some expensive container," full stop.

Why did Cloudflare build a whole new browser instead of just using Chromium?

Cloudflare's own technical post lays out the argument plainly, and it's easier to state than to build: Chromium was designed to be looked at by a human. Full graphics rendering pipeline, video decoding, WebGL, extension support, twenty years of web-compatibility baggage. An AI agent needs almost none of that. It needs to load a page, run JavaScript, read the resulting DOM, and maybe grab a screenshot. Spinning up a complete Chromium process for that, in Cloudflare's own framing, is industrial overkill for a task that doesn't require it.

Their answer was to build a browser that runs entirely on V8 isolates, the same lightweight isolation mechanism Workers already use to run serverless functions for thousands of tenants on shared hardware. The team says the first commit landed in May and the browser was twelve weeks old at launch. That says a lot about how thin a browser can get once you strip out everything an agent doesn't touch.

The important nuance: this isn't "Chromium, but lighter." It's a different engine with its own behavior and its own hard limits, and Cloudflare explicitly positions it as a complement to, not a replacement for, the Chromium-based browsers it already offered inside Browser Run.

How does Kitesurf actually work under the hood?

Three design choices explain most of what you need to know:

1. An engine on V8 isolates, not OS processes. Every Kitesurf session spins up as an isolate, the same mechanism Workers use to run untrusted third-party code side by side without cross-contamination. Booting an isolate is orders of magnitude cheaper and faster than booting a full Chromium process with its own memory space.
2. Stateless by design. Cloudflare's rule for Kitesurf is that wherever a component can be stateless, it should be. That maps onto the intended usage: short, bursty jobs, not long authenticated sessions.
3. Protocol-level compatibility, not a full CDP reimplementation. Kitesurf speaks enough CDP (Chrome DevTools Protocol, the remote control channel Chrome exposes) that existing tools can point at it without rewriting their automation logic. Since September 28, 2026, Cloudflare says Kitesurf has full Browser Run API coverage: you can use it with CDP, Playwright, Puppeteer, or MCP.

WebMCP: letting sites hand agents real buttons

Clicking through a page is slow and fragile for an agent. WebMCP is a draft standard that lets a website publish its actions as tools, so an agent can call something like searchFlights() instead of hunting for the right button. Pages register those tools through document.modelContext, the API in the WebMCP Community Group draft.

Kitesurf sessions support WebMCP since the September 28 update. Cloudflare's demo uses its own Radar site, which exposes tools like navigate-to and set-location. You can see them in the Kitesurf playground at kitesurf.dev, under Application, then WebMCP, in the DevTools panel. Cloudflare's docs list a few limits: Kitesurf doesn't expose tools registered inside iframes or popups, and it doesn't apply WebMCP's permissions policy or origin-based tool filtering.

Here's Cloudflare's current MCP configuration for wiring Kitesurf into an agent. The last flag, --category-experimental-webmcp, adds the list_webmcp_tools and execute_webmcp_tool tools so your agent can use a site's WebMCP tools:

{
 "mcp": {
 "kitesurf": {
 "type": "local",
 "command": [
 "npx",
 "-y",
 "chrome-devtools-mcp@latest",
 "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/YOUR_ACCOUNT_ID/browser-run/devtools/browser?browser=kitesurf",
 "--wsHeaders={\"Authorization\":\"Bearer YOUR_API_TOKEN\"}",
 "--category-experimental-webmcp"
 ],
 "enabled": true
 }
 }
}

And for a one-shot Quick Action, say, a screenshot without spinning up a full automation session:

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

If your code already runs on Workers, you don't need the REST call. Since September 28, Quick Actions also work from inside a Worker through the env.BROWSER.quickAction() binding. This is Cloudflare's own example, with the TypeScript types removed:

export default {
  async fetch(request, env) {
    return await env.BROWSER.quickAction("screenshot", {
      url: "https://example.com",
      browser: "kitesurf"
    });
  },
};

Notice what Cloudflare didn't do: they didn't ship a separate product with a separate API. It's the same Browser Run endpoint that already existed for Chromium, with browser=kitesurf added to the query string. That's a smart product call. It drops the switching cost to almost zero for anyone already on Browser Run.

What else changed since launch

Cloudflare's September 28 post, "The road to the agentic browser," lists a few more updates worth knowing:

• More of the web works. Kitesurf added CSS Layout, the CSS Object Model, CSS Typed OM and custom elements, plus JSON modules and import maps for sites that load JavaScript in chunks. Iframes load at the right time and display text correctly in more languages.
• Standards tests keep climbing. Web Platform Tests is a shared test suite that checks whether browsers follow web standards. Kitesurf now passes more than 730,000 of its subtests, which Cloudflare says is 500,000 more than at launch.
• Same cost profile. Cloudflare says wall-clock time and CPU use stay roughly in line with its launch benchmarks, and in some cases improved. It hasn't published a new table, so treat that as Cloudflare's own claim.
• A terminal version. Run brew install cloudflare/cloudflare/kitesurf, then kitesurf https://example.com, and the page renders inside terminals that support the Kitty graphics protocol, such as Kitty, Ghostty and WezTerm, with a plain text mode for the rest. It's a quick way to see a page the way an agent using Kitesurf sees it.

How does Kitesurf compare to Chromium, Browserbase, and Browserless?

This is the table that actually drives the decision of which engine sits behind your agent:

The honest reading of Cloudflare's own 14-URL launch benchmark is that Kitesurf clearly wins on cost per session and loses on wall-clock speed: roughly 3.1x less CPU and 4.7x less memory for screenshots, and 3.8x less CPU with 7.0x less memory for HTML extraction. But the same table shows Kitesurf finishing 1.8x slower on screenshots and 1.7x slower on HTML extraction than a warm Chromium. Cloudflare doesn't hide this. It's right there in the launch post. It's a deliberate trade of time for resources, not a "faster and cheaper across the board" marketing claim.

What is Kitesurf actually good for, and where does it fall short?

Where it makes real sense today:

• High-volume content extraction. An agent crawling thousands of URLs for clean text, pricing, or metadata doesn't need video rendering or WebGL, it needs a fast-booting session and a clean DOM.
• On-demand screenshots and PDF generation. The one-shot "Quick Action" pattern, where spinning up a full Chromium process per request is wasted compute.
• Bursty workloads. Agents that sit idle most of the time and then need to fire off hundreds of short parallel sessions, the exact shape of a research-agent pipeline or an automated QA sweep.
• Prototyping agent-first automation without managing browser infra yourself. If your stack already lives on Workers, adding Kitesurf is architecturally coherent, everything runs on the same runtime.

Where Cloudflare itself flags it as the wrong tool:

• Authenticated sessions that need persistent state, even ones as short as ten minutes, in Cloudflare's own example.
• Beating anti-bot challenges that check real TLS fingerprints, Kitesurf isn't a real browser fingerprint.
• Anything involving video or WebGL.
• Heavy visual debugging or advanced stealth, where Browserbase has had more time to build specifically for that.

Verdict: should you switch your automation stack to Kitesurf?

It depends on what you're actually building, and this deserves an opinion, not a neutral feature checklist.

If your agent does bulk scraping, structured data extraction, or one-off screenshots, Kitesurf is worth testing right now, especially while it's free during beta. Cloudflare's own benchmark shows large CPU and memory savings, and the barrier to entry is basically one URL parameter. If you're already on Cloudflare Workers, the env.BROWSER.quickAction() binding makes the integration close to trivial. And if the sites you target publish WebMCP tools, your agent can call those instead of clicking.

If your product depends on long authenticated sessions, needs to evade anti-bot detection with a real browser fingerprint, or works with rich media (video, canvas, WebGL), Kitesurf isn't your tool yet. Stick with managed Chromium, Browserbase if you want debugging and stealth out of the box, Browserless if you'd rather have a more traditional API with self-hosting options.

The real risk here isn't performance, it's maturity. Kitesurf is still in beta two months after launch, it isn't open source yet (Cloudflare says that's "coming soon" and hasn't given a date), and Cloudflare is the only operator of the infrastructure. If your agent handles sensitive data or you need to audit exactly what the rendering engine does, waiting for the open-source release is a reasonable call. For everything else, the cost of trying it during the free beta is essentially zero.

Go deeper

• What is Stagehand, Browserbase's SDK for agents that drive a full Chromium browser
• What an MCP server is, the protocol behind the MCP setup above
• Web search APIs for AI agents, for when your agent needs search results, not a browser at all

If you already call AI APIs and want a guided path to building agents that use tools like these, see how AI Flex works. It's self paced, with an AI tutor and mentors.

For more tested tools like this one, see our AI tools hub.