kitesurf: give your coding agent a cloud browser
Stacks · 8 min read · posted Aug 11, 2026, 5:35 am
Kitesurf is a browser Cloudflare built for AI agents instead of people. Written in Rust, it runs entirely on Cloudflare Workers inside V8 isolates. No window, no tabs, no Chromium anywhere in the stack. It launches on demand per request, stateless, and it speaks Chrome DevTools Protocol, which means the browser tooling you already use can drive it today.
Announcement: blog.cloudflare.com/kitesurf Playground: kitesurf.cloudflare.app
the problem nobody talks about
Every browser your agents use today was built for humans. Chromium renders pixels, runs a JIT tuned for interactive pages, and eats memory doing work no agent asked for. Cloudflare's own benchmark on a 14-URL corpus: Chromium needs 273.7 MiB to extract HTML from a page. Kitesurf does the same job in 39.4 MiB. That is 7x less memory, and CPU comes in at 3.8x less.
If you run browser automations locally, you already know this pain. Half my automations drive a real Chrome window on my Mac, and it is the single heaviest thing in my stack. A browser that exists only to serve agents, hosted on someone else's edge, is the first release actually aimed at that problem.
why this matters
It speaks CDP, so nothing changes in your tooling. Puppeteer, Playwright, and chrome-devtools-mcp all connect the way they always have. You point them at a Cloudflare wss endpoint with browser=kitesurf instead of a local Chrome.
The engineering is genuinely weird, in a good way. JS evals run through Boa, a JavaScript engine written in Rust, compiled to WebAssembly, executing inside V8. Cloudflare calls it "a runtime on top of a runtime." CSS parsing comes from Stylo (Firefox's parser), rendering from Blitz. It still passes 215,000+ Web Platform Tests.
It's free while in beta. Access is through Browser Run on any Cloudflare account. No card, no local install.
Slower per page, and that's fine. Cloudflare names the tradeoff themselves: 1.7-1.8x slower wall time per page than Chromium, whose JIT is more mature. Agents don't sit and watch a page load. The win is launching hundreds of stateless instances on demand instead of babysitting one fat browser.
step 1: get a token
Create a Cloudflare account if you don't have one, then generate an API token with Browser Run permissions from the dashboard. Note your account ID while you're there. Both go into every connection below.
step 2: sanity-check it with curl
The quick actions live under browser-run in the regular Cloudflare API. A screenshot round trip proves your token works before you touch any agent config:
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://news.ycombinator.com"}' \
--output screenshot.png
Same pattern fetches a page as markdown, which is the extraction agents actually want. One caveat from testing: the free beta rate-limits quick actions to roughly one per minute, so space your calls.
step 3: wire it into claude code
This is the one config block. Add it to your MCP servers and your coding agent has a cloud browser with nothing installed:
{
"kitesurf": {
"type": "stdio",
"command": "npx",
"args": [
"-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\"}"
]
}
}
Swap in your account ID and token. On the first tool call, Kitesurf spawns a page target on demand and the agent browses like it would through local Chrome. Puppeteer and Playwright connect to the same wss endpoint through their standard connect methods.
step 4: poke it in the playground
kitesurf.cloudflare.app loads any URL with embedded devtools and a live Wasm memory panel. Load a heavy page and watch what it costs. This is the fastest way to build intuition for what the browser does and doesn't render before you commit automations to it.
honest limitations
No video and no WebGL yet. It won't pass bot challenges that fingerprint TLS, so anything behind serious bot protection stays a Chromium job. Sessions are stateless by design, which means no persistent logins. And the per-page slowdown is real: if your workload is one latency-sensitive page, local Chrome still wins. Open-sourcing is planned but hasn't shipped.
Everything else, it browses.