Kitesurf, Browser Run, and Manifest: Three Different Layers, Not Three Competitors

Cloudflare shipped two things this quarter that are relevant if you're building browser-using AI agents: Browser Run, their headless browser automation product, and Kitesurf, a new agent-first browser engine that runs inside it. Both are getting lumped into "agent browser infra" conversations next to tools like Manifest. They're not the same category. Here's where each one actually sits.

Browser Run: the access layer

Browser Run is Cloudflare's serverless browser automation product. You get a controllable browser instance on Cloudflare's network, driven over the Chrome DevTools Protocol — so Puppeteer, Playwright, chrome-remote-interface, or any MCP-speaking agent works against it out of the box.

Two engine choices:

• Chromium (default) — full-featured, handles WebGL, video, and bot-challenge TLS fingerprinting.

• Kitesurf (opt-in via browser=kitesurf) — lighter, but with real gaps (see below).

There's also a Quick Actions mode: one-shot REST endpoints for screenshot or HTML extraction without managing a full CDP session.

Billing runs on two meters — browser-hours and concurrent sessions — not CPU or memory. That matters for the next section.

Kitesurf: a new engine, not a new product

Kitesurf is Cloudflare's own browser implementation, built specifically for agents rather than humans, running entirely inside V8 isolates on Workers. No Chromium anywhere in the stack.

Three stateless components do the work:

• Engine — the only public-facing piece; handles the CDP session and state.

• PageScript — parses HTML/CSS (via Blitz + Stylo, Firefox's CSS parser) and runs page JS inside a Dynamic Workers isolate. eval is handled by Boa, a Rust-based JS engine, since Workers doesn't support native eval.

• PageRenderer — rasterizes the parsed page into pixels via Workers RPC.

The pitch is efficiency: 3-7x less CPU and memory than Chromium on typical agent tasks (screenshot, HTML extraction). The catch: it's 1.7-1.8x slower in wall-clock time, because a cold Wasm renderer can't compete with Chromium's JIT once it's warmed up. It also can't yet do WebGL, video, or real TLS-fingerprinted bot-challenge handshakes — so for now it's a Chromium substitute for a subset of pages, not a full replacement.

One thing worth flagging if you're citing Cloudflare's own numbers: the "3-7x cheaper" framing is about CPU and memory, but Browser Run doesn't bill on either of those — it bills on browser-hours and concurrent sessions. The efficiency gain is real on Cloudflare's infrastructure; it doesn't automatically show up as savings on your invoice yet.

Where Manifest fits

Both of the above solve the same problem: get me a rendered page, cheaply, at scale. Neither answers the next question an agent actually has to answer: what can I do on this page, and in what order?

That's the gap Manifest fills. Point it at a page and it returns a structured JSON action manifest — every clickable, fillable, and submittable element, with resolved locators (CSS/role/name), plus a requires dependency graph encoding which fields depend on which others before an action is valid.

Stacked together, a typical flow looks like:

1. Browser Run or Kitesurf fetches and renders the page.

2. Manifest turns that render into a structured, agent-consumable action schema.

3. The agent's model reasons over the manifest instead of raw HTML or a screenshot, and acts.

Manifest sits between browser-access tools (Browserbase, and now Browser Run / Kitesurf) and content-extraction tools (Firecrawl) — it's the actions layer, not the access layer. Cloudflare making browser access cheaper and more scalable doesn't compete with that; if anything it makes the case for Manifest stronger, since it's now viable to render more pages more often, which means more pages that need turning into something an agent can actually act on.