If your agent loads web pages, you are almost certainly renting a full Chromium somewhere — on Browserbase, Steel, Browserless, or a container you babysit yourself. Chromium is a browser built for a human staring at a 60-fps tab. Your agent isn't staring at anything. It wants the text, maybe a screenshot, and then it throws the page away. On August 6, Cloudflare shipped a browser that admits this out loud.

Kitesurf is an "agent-first" browser engine that runs entirely in V8 isolates on Cloudflare Workers — written from scratch in Rust and WebAssembly, with no Chromium underneath. The headline number: for common agent work like screenshots and HTML extraction, it uses 3–7× less CPU and memory than Chromium. The catch, stated in the same breath: it's about 1.7× slower in wall time per page. That single trade is the whole decision, so let's make it cleanly.

The answer, up front#

Use Kitesurf when your agent fires many short-lived, throwaway page loads and per-load cost is what compounds. Use hosted Chromium (Browserbase, Steel, Browserless) when you need one long, human-shaped, logged-in session or you're fighting bot detection. It is a workload-shape decision, not a brand loyalty one — and because Kitesurf speaks CDP, you can test the swap without rewriting a line of automation.

That's the citable version. Here's why it holds.

Why "no Chromium" is the feature, not a gap#

Chromium carries a process model, a GPU compositor, an extension system, and a rendering pipeline tuned to make pixels look right to an eye. An agent needs none of it. What an agent needs is machine-readable content, low token overhead, horizontal scalability, and isolation against a page that tries to prompt-inject it. Kitesurf is built around exactly that list and drops the rest.

The architecture is the tell. Every page runs as a stateless PageRenderer isolate, so on any crash Cloudflare can kill and relaunch it without losing your session — the same disposability that makes Workers cheap makes browser tabs cheap. All outbound network traffic is funneled through a single SandboxOutbound worker, which is both the scaling choke point and the security one: one controlled egress instead of a full browser's sprawling network surface. This is the isolate-vs-container tradeoff applied to the browser itself — lean, stateless, and horizontally cheap, at the cost of the heavyweight fidelity a real process gives you.

And "no Chromium" usually means "half the web breaks." Here it mostly doesn't: Kitesurf already passes 215,000+ Web Platform Tests, which is the difference between a toy renderer and one that survives real pages. This is the same bet Lightpanda made against Playwright and Browserless — a purpose-built, non-Chromium engine for agents — except Kitesurf is serverless-native on Workers and CDP-compatible out of the box.

What it can't do yet#

The honest list, because it decides half the cases:

None of that matters for the modal agent task — "open this URL, read it, extract the fields, move on." All of it matters for scraping and account automation. Know which one you're building.

You don't rewrite anything#

The reason this is worth ten minutes of your afternoon: Kitesurf exposes the Chrome DevTools Protocol, so Puppeteer, Playwright, and MCP browser clients connect to it unchanged. In a Worker, the Browser Run binding is the same shape you already know:

import puppeteer from "@cloudflare/puppeteer";

export default {
  async fetch(request, env) {
    // Browser Run hands you a browser over CDP — Kitesurf sits behind
    // the same binding, so this Puppeteer script is engine-agnostic.
    const browser = await puppeteer.launch(env.MYBROWSER);
    const page = await browser.newPage();
    await page.goto("https://example.com", { waitUntil: "networkidle0" });

    const text = await page.evaluate(() => document.body.innerText);
    const shot = await page.screenshot();      // the cheap-3-7x path

    await browser.close();
    return new Response(text);
  },
};

Point an existing script at Browser Run, run your own workload, and read the CPU-seconds off the bill. That's the only benchmark that matters, because the 3–7× is their number on their tasks — yours may land anywhere in that range, and the 1.7× wall-time tax may or may not fit your latency budget.

The money#

Kitesurf rides Browser Run's pricing: the free tier gives roughly 10 minutes of browser usage a day with 3 concurrent browsers, the Workers Paid plan includes about 10 browser-hours a month and 10 concurrent browsers, and past that it's $0.09 per browser-hour. Now put the 3–7× next to it: the discount isn't the per-hour rate — it's that each page consumes a fraction of the CPU-seconds, so you fit far more page loads inside the same hour. For a fleet doing thousands of short loads, that's the line item that moves. Cloudflare also says it plans to open-source the engine, which lowers the lock-in objection to trying it.

Where it sits in the browser-for-agents stack#

Kitesurf doesn't replace the whole category; it splits it. The remote-Chromium comparison — Browserbase vs Steel vs Browserless — is still the right map when you need real browser fidelity, anti-bot muscle, or held-open sessions. The computer-use vs browser-automation question is a different axis entirely. What changed on August 6 is that the cheap, scalable, non-Chromium corner of the map — previously a one-name club — now has a serverless-native option you can drive with the Puppeteer script already in your repo. It also slots neatly into the rest of what Cloudflare shipped this week; if you're already adopting its Agents Week stack, the browser now lives in the same place as the gateway and the sandboxes.

The instinct to reach for a "real browser" is the same expensive instinct as reaching for the guaranteed GPU: it feels safe, and most of what your agent actually does never needed it. If your workload is a firehose of short page loads, the browser built for a human watching one tab was never the right tool. Now there's one built for the machine that isn't watching.