Cloudflare shipped an agent browser that is not Chromium

What Cloudflare published on 6 August 2026

The post is titled Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers, it is written by Celso Martinho, and it is dated 6 August 2026. The claim is that a browser aimed at agents does not need most of what a browser aimed at people needs, and that dropping the rest buys a large amount of headroom. Cloudflare names what it gave up in the same breath: tabs, themes, extensions, pixel perfect rendering and smooth scrolling are not there, because no agent asked for them.

What replaces them is an engine running inside a V8 isolate instead of a full browser process. The practical consequence is in the benchmark table Cloudflare publishes. On a screenshot it reports 380 ms of CPU against Chromium's 1,173 ms, described as 3.1 times less, and 57.8 MiB of memory against 271.0 MiB, described as 4.7 times less. On HTML extraction it reports 229 ms against 877 ms, 3.8 times less, and 39.4 MiB against 273.7 MiB, 7.0 times less. The trade is stated just as plainly: wall time goes the other way, 1,148 ms against 637 ms on the screenshot and 820 ms against 472 ms on extraction, which Cloudflare reports as 1.8 and 1.7 times slower.

The Browser Run documentation for Kitesurf covers the mechanics. Selecting it is a parameter rather than a migration: browser=kitesurf appended to a Quick Action endpoint, or to the CDP endpoint URL that a driver or an MCP client connects to. Cloudflare says it is free while the beta lasts. Nothing about this is deployed by a site owner, and that is worth stating early, because the previous Cloudflare release we wrote up, the WebMCP developer preview, was the opposite case: a switch on your own zone. Kitesurf is infrastructure for whoever is building the agent. You do not turn it on, you do not turn it off, and if it arrives at your origin you were not consulted.

That distinction matters for anyone treating generative engine optimization as a list of things to install. This one is not on the list. It is a change in what the population of clients hitting your server is made of, which is a thing to understand rather than a thing to do.

What a browser at 97 percent of DOM subtests means

Cloudflare publishes conformance figures, which is more than most engines do, and the figures are the most useful thing in either page. The documentation, read on 9 August 2026, says Kitesurf passes over 235,000 Web Platform Tests subtests, and breaks the coverage down by area: DOM 97 percent, HTML 96 percent, Selection 99 percent, SVG 97 percent, Encoding 99 percent, CORS 95 percent, XHR 95 percent and URL 83 percent.

Two Cloudflare pages give two figures here, and they do not use the same unit. The announcement says the engine passes 215,000+ WPT tests and growing; the documentation says over 235,000 subtests. A test and a subtest are not the same object in that suite, and the pages may simply be counting different things at different moments. We are recording both rather than reconciling them, in the same way we recorded two different Chrome version numbers across two vendor pages last week, because picking one would mean guessing which page is stale.

The percentages are where the practical reading is. Ninety seven percent of DOM subtests passing means three percent are not, and from outside there is no way to know whether the three percent that fail are the ones your product page depends on. That is a different kind of uncertainty from the one this site usually deals with. When a page fails to reach a fetch only client, the failure is total, legible and reproducible: the text is in the response body or it is not. A partially conformant engine fails narrowly and unpredictably instead, which is much harder to see and much harder to test for, because the page mostly works.

We have written before about text that reaches one consumer and not another. Text inside shadow DOM reaches a browser and not an extractor. The same JSON-LD read two ways can score full marks and zero on one page. Both of those are boundary problems, and a second engine at 95 to 99 percent adds a third boundary that nobody can currently probe from the outside. The honest position on 9 August 2026 is that this is a risk with no published measurement attached, including from us. What is measurable today is unchanged: whether the text is in the HTML before any engine touches it, which is prose parity, and which no conformance percentage can take away from you.

The limitation that names bot challenges

Four limitations are listed, and three of them are ordinary product scope. Kitesurf cannot play video or render WebGL, and it cannot start a long-running authenticated session that requires persistent state. An agent extracting text needs none of those, so they read as deliberate omissions rather than gaps.

The fourth is different. Cloudflare states that Kitesurf is not yet the right option if you need to negotiate a bot-challenge handshake with real TLS fingerprints. Read plainly, that is a company that sells bot management telling you its own agent browser cannot get through a bot challenge of the kind its own network issues. Nothing about that is concealed, it sits in the limitations list on both pages, and it is a fair thing to ship a beta without. It is also the single most consequential sentence in either document for anyone trying to reason about who reaches their origin.

It matters because TLS fingerprinting is not a theoretical defence. Three researchers at the University of Bamberg loaded 10,000 homepages in four browser configurations and found headless Chromium soft blocked on 15.2 percent of them against 7.2 percent for the same browser with a window, which is what happens to a client that looks automated at the transport and header layers. An engine that cannot present a real TLS fingerprint at all is starting from a weaker position than headless Chromium did in that study, not a stronger one.

There is a second reading, and it cuts the other way. A client that cannot fake a browser handshake is a client that is easy to identify, and identification is the precondition for every good outcome in this area. Cloudflare's own verified bots programme, which we covered when ignoring crawl-delay became grounds for unverifying a crawler, only works on clients that declare themselves. A separate controlled study found that turning on both of Cloudflare's free AI bot controls stopped one of seven browsing agents, and the one that was stopped was the one listed in the bot directory, which the authors read as self-identification rather than detection. The recurring lesson is the one we set out in a user agent is a claim, not an identity: what a client says about itself and what a network can verify are separate questions, and only the second one is enforceable. Cloudflare has published nothing about what user agent string Kitesurf sends, and neither page we read names one, so what a site owner would see in a log today is not documented.

Why the cost of rendering is the number to watch

Strip away the product and one number is doing the work. Rendering a page is expensive, and that expense is the reason most machine consumption of the web has never involved a browser at all.

Google is the clearest evidence, because it publishes the cost as a queue. Its JavaScript SEO documentation describes processing in three separate phases, crawling, rendering and indexing, and says the page may stay on the rendering queue for a few seconds but that it can take longer than that. The organisation running the largest crawl in existence treats executing your scripts as deferred work rather than a default step, and says so in its own developer documentation. Everyone with a smaller budget makes a harsher version of the same call. The bulk archive a great deal of model training draws on holds no rendered output at all, which is what we found in the Common Crawl July archive. Clients arriving from developer tooling frequently do not present as browsers at all, which is what a Cisco engineer logged when most AI coding agents arrived identifying as an HTTP library.

Against that background, an engine reported at 3.1 to 3.8 times less CPU and 4.7 to 7.0 times less memory is not a footnote about efficiency. It is a change in the price of the decision every one of those operators has already made against you. It does not follow that they will change their minds, and this post is not predicting that they will. Cloudflare's own figures show the trade is real in the other direction too, since wall time is 1.7 to 1.8 times worse, and a retrieval fetcher assembling an answer under a latency budget cares about wall time more than it cares about memory. Whether cheaper and slower is a better deal than expensive and fast depends on which resource an operator is actually short of, and nobody outside those companies knows.

What can be said is that the direction of travel is toward more agents in browsers rather than fewer, and that the value of being operable rather than merely readable rises with it. A controlled experiment we covered found an agent ready storefront passing 89.3 percent of tasks against a baseline of 49.3 percent, and both versions in that study were driven by real browsers, so nothing the agents needed was hidden behind a rendering decision. That is the world Kitesurf is built for. Cloudflare's own framing is that agents care about token count, context windows, scalability and cost rather than about pixels, which is a reasonable description of the client it expects to serve.

What changes on your own site, and what does not

Nothing here is an action. There is no file to add, no header to set and no setting to review, and a post that manufactured one would be padding.

What changes is a piece of reasoning that a lot of site owners rely on without noticing. The reasoning goes: our pages need JavaScript, but modern crawlers render, so we are fine. That was always weaker than it sounded, and it is weaker again now, because rendered has become a family of outcomes rather than one. A page can be complete in Chrome, complete in Chromium under an automation driver, and incomplete in an engine that passes 96 percent of HTML subtests and 83 percent of URL subtests. You cannot test for the third case, because you cannot know which client will use which engine, and no engine publishes a manifest of the pages it gets wrong.

The response to that is not to chase engines. It is to depend on fewer of them. Every piece of text present in your served HTML is text no rendering engine has to get right, and that is the entire argument for measuring the served response first. What GPTBot sees fetches your page the way a client without a browser fetches it and shows you what comes back, and our methodology describes the comparison between that response and the rendered one, because the gap between the two is the quantity underneath nearly every question anyone asks about AI visibility. If your prices, your product copy and your actual answers are in the served bytes, then a partially conformant engine is a question about somebody else's roadmap rather than about your revenue.

The order has not changed either. Two layers decide whether AI can read your site: whether the client is permitted to fetch at all, and whether what it fetches contains the text. Kitesurf sits underneath the second layer as one possible way of resolving it, and it only matters at all for the portion of your content that is not in the HTML already. For a site on a framework where that portion is large, the repair is a rendering strategy rather than a crawler strategy, which is what the per stack guides such as the one for Next.js are for.

One last thing, stated plainly because this site owes it. Lantad has not run Kitesurf, has not rendered a single page in it, has not compared its output with Chromium's, and has no data on whether any AI client uses it. Every figure above is Cloudflare's own, published on the two pages named and read on 9 August 2026. If we later measure a difference between engines on real pages, that post will carry a date, a sample size and a description of what was not measured, in the same form as everything else here.