Pas de Chromium dedans. C'est la première chose à dire. Cloudflare a lancé un navigateur écrit de zéro en douze semaines, qui s'exécute entièrement dans des isolats V8 sur Workers, principalement du Rust compilé en WebAssembly. Il vit dans Browser Run, gratuit tant que dure la bêta. Plus de 235 000 sous-tests Web Platform réussis. Il fait aussi tourner Doom.
Le compromis est réel et, à leur crédit, Cloudflare publie les deux moitiés. Sur les tâches courantes d'agents, Kitesurf utilise 3,1 à 3,8 fois moins de CPU et 4,7 à 7 fois moins de mémoire que Chromium. Il met aussi 1,7 à 1,8 fois plus de temps à l'horloge. Et voici le point qui mérite une pause. La grille tarifaire publiée de Browser Run facture des heures de navigateur et des navigateurs simultanés. Pas du CPU. Pas de la mémoire. Ce qui signifie que, aux prix d'aujourd'hui, le compteur que Kitesurf gagne est celui de Cloudflare, et le compteur qu'il perd est le vôtre. Personne ne paie encore cela puisque la bêta est gratuite, et Cloudflare dit que les économies finiront aussi par arriver chez les clients. Il n'existe simplement aucun tarif Kitesurf publié pour le vérifier.
Je construis les intégrations d'eesel, donc un lancement comme celui-ci se lit pour moi comme une liste de courses de briques, pas comme un produit. Plus de trois ans à mettre des agents IA sur de vraies files de support m'ont appris une chose sur les agents qui pilotent des navigateurs. Le rendu casse presque jamais. L'identité, si. eesel a perdu des clients partis construire directement sur l'API Claude, et tous ceux qui sont revenus ont dit la même phrase : la démo, c'était les 20 % faciles. Donc : si vous voulez que l'IA réponde aux tickets au lieu de faire des captures de pages, eesel se connecte à votre helpdesk et à votre documentation, puis se rejoue sur votre historique réel de tickets avant de parler à un seul client. Gratuit à essayer. Pas de navigateur requis.
Le compteur que Kitesurf optimise n'est pas celui que vous payez
Commençons par la phrase de la propre documentation de Cloudflare : « Kitesurf wins on the memory and CPU that drive your bill (by 3-7x). »
Ouvrez maintenant la page de tarification de Browser Run, mise à jour pour la dernière fois en avril 2026. Il y a exactement deux compteurs :
| Compteur | Workers Free | Workers Paid |
|---|---|---|
| Heures de navigateur | 10 minutes par jour | 10 heures/mois, puis 0,09 $ par heure |
| Navigateurs simultanés (Browser Sessions uniquement) | 3 | 10, en moyenne mensuelle, puis 2,00 $ par navigateur |
Aucun n'est du CPU. Aucun n'est de la mémoire. Les heures de navigateur sont du temps d'horloge, signalé par requête dans l'en-tête de réponse X-Browser-Ms-Used, et les Quick Actions ne sont facturées qu'en heures de navigateur. Les navigateurs simultanés sont un nombre d'unités, pas une mesure de ressources. La même distinction qui rend si difficile la comparaison des tarifs d'API de LLM d'un fournisseur à l'autre.
Donc, selon la grille publiée, exécuter le même travail sur Kitesurf plutôt que sur Chromium fait avancer le compteur facturé environ 1,7 à 1,8 fois plus vite. Les économies de CPU et de mémoire sont importantes et réelles, mais elles atterrissent dans le parc de Cloudflare, où une session de capture d'écran passe de 271,0 MiB à 57,8 MiB. Un vrai gain de plateforme, et exactement le genre de chose qui permet ensuite à un fournisseur de relever les plafonds de concurrence et de baisser les prix. Ce n'est pas encore une ligne de votre facture. Quiconque a essayé de modéliser le coût par résolution sait à quel point le coût unitaire d'un fournisseur et votre prix unitaire peuvent s'éloigner.
Deux réserves, que je préfère énoncer clairement plutôt qu'enterrer. Première : le temps réel du benchmark et les ms de navigateur facturés sont mesurés différemment, donc considérez ce multiplicateur comme une direction et non comme une décimale. Seconde : Kitesurf est gratuit pendant la bêta, ce qui fait que la réponse honnête à « combien ça coûte ? » est rien, aujourd'hui. La vraie question est ce qui se passera à la disponibilité générale. Cette réponse n'est pas publiée.
Voici le calcul sur la grille actuelle, pour que vous puissiez y mettre votre propre volume :
À un million de captures d'écran par mois, l'écart ressort à environ 12,78 $. À dix millions, environ 128 $. De petits montants absolus, parce que Browser Run est déjà bon marché au départ, et cela fait partie de la lecture honnête : personne ne choisit Kitesurf aujourd'hui pour économiser sur les heures de navigateur. On le choisirait parce que la capacité propre de Cloudflare devient moins chère, ce qui est ainsi que l'on finit par arriver à des plafonds de concurrence plus élevés et à une meilleure grille tarifaire. Ce plafond a déjà bougé deux fois cette année, de 30 à 120 en avril, puis à 200 sur la page des limites actuelle.
Ce qu'est réellement Kitesurf
Trois composants. Les noms sont, pour une fois, étonnamment littéraux.
L'Engine est la seule pièce exposée au public. Il parle le Chrome DevTools Protocol sur WebSocket plus une surface REST HTTP, et c'est aussi le seul composant qui conserve l'état de session. Ce choix de CDP, c'est toute l'histoire de la compatibilité, côté adoption : pointez Puppeteer, Playwright, chrome-remote-interface ou n'importe quel agent qui parle MCP et CDP dessus, et ça marche. Vous l'activez en ajoutant browser=kitesurf au point d'accès. C'est toute la migration.
PageScript est l'endroit où une page vit réellement. Chaque page, et chaque iframe hors processus, reçoit son propre isolat de longue durée lancé via Dynamic Workers, avec un globalThis propre et un document DOM. L'analyse du HTML et du CSS vient de Blitz et de Stylo, l'analyseur CSS de Firefox. Tous deux en Rust.
PageRenderer transforme la page calculée en pixels. Sans état, avec seulement un cache jetable, et l'Engine appelle renderFrame() dessus via Workers RPC. Comme il ne conserve rien, un rendu bloqué est simplement tué et relancé plutôt que débogué.
Deux détails valent plus que le schéma d'architecture lui-même.
Le premier : Workers ne prend toujours pas en charge eval nativement, pour des raisons de sécurité. Le contournement de Cloudflare consiste à exécuter Boa, un moteur ECMAScript écrit en Rust, dans l'isolat. Comme l'a formulé un commentateur, c'est un moteur JS écrit en Rust, compilé en Wasm, exécuté dans V8. Celso Martinho, qui a écrit l'article, a confirmé sur Hacker News qu'ils abandonneront Boa dès que l'eval natif arrivera. Il est rare de voir un fournisseur qualifier sa propre couche de sous-optimale dans l'article de lancement.
Le second concerne l'origine de l'idée. Cloudflare cite obscura, un moteur headless en Rust sous licence Apache-2.0, comme l'inspiration initiale, et dit que la première tentative a été de le porter sur Workers avec un agent IA, ce qui « didn't work very well at first. » Puis son auteur est apparu dans le fil :
"I had no idea Cloudflare had tried porting Obscura until I read this post. Seeing something I built mentioned as the starting point for Kitesurf is an honor... For context, I'm 16."
À ce jour, ce dépôt compte 22 186 étoiles.
Le benchmark, lu ligne par ligne
Cloudflare publie des médianes de cinq exécutions de Quick Actions de Browser Run sur un corpus de 14 URL, dont le contenu est lisible : Hacker News, Wikipedia, MDN, trois journaux (The Guardian, El Mundo et RTP), plus cinq builds TodoMVC.
| Mesure | Kitesurf | Chromium (pool chaud) | Kitesurf, relatif |
|---|---|---|---|
| CPU : capture d'écran | 380 ms | 1 173 ms | 3,1 fois moins |
| CPU : extraction HTML | 229 ms | 877 ms | 3,8 fois moins |
| Mémoire : capture d'écran | 57,8 MiB | 271,0 MiB | 4,7 fois moins |
| Mémoire : extraction HTML | 39,4 MiB | 273,7 MiB | 7,0 fois moins |
| Temps réel : capture d'écran | 1 148 ms | 637 ms | 1,8 fois plus lent |
| Temps réel : extraction HTML | 820 ms | 472 ms | 1,7 fois plus lent |
Trois choses à noter ici.
La comparaison se fait contre un pool chaud, que Cloudflare nomme directement dans l'en-tête de colonne au lieu de le cacher. Un Chromium chaud a un JIT qui a déjà vu la page ; Kitesurf est un moteur de rendu logiciel à froid, à chaque fois. Ce qui en fait un combat équitable pour une charge d'agents par rafales et inéquitable pour une longue session. Dans les deux cas, la présentation est honnête.
La mémoire de Chromium bouge à peine entre les deux tâches, 271,0 MiB contre 273,7 MiB, alors que celle de Kitesurf passe de 57,8 à 39,4 MiB. C'est la vraie forme de l'argument : Chromium paie pour un navigateur entier, que vous lui demandiez ou non de dessiner quoi que ce soit, et Kitesurf paie à peu près en proportion du travail. C'est la même raison pour laquelle la tarification IA au jeton se comporte différemment de la tarification par siège, et pour laquelle la tarification de GPT-5.6 récompense les prompts courts.
Et ce corpus, ce sont quatorze pages riches en texte et bien élevées. Un substitut raisonnable pour « extrais cet article », un mauvais pour un parcours de paiement.
Ce qu'il ne sait pas encore faire
Cloudflare énumère quatre lacunes, et je préfère citer plutôt que paraphraser : lire des vidéos, rendre du WebGL, négocier une poignée de main de défi anti-bot avec de vraies empreintes TLS, ou démarrer une session authentifiée de longue durée nécessitant un état persistant. Pour tout cela, vous utilisez le Chromium par défaut de Browser Run.
La quatrième est la limite porteuse. Un agent qui fait quelque chose de commercialement intéressant sur le web passe l'essentiel de sa vie connecté, et c'est exactement le cas que Kitesurf renvoie à plus tard aujourd'hui. Tout assistant d'achat digne de ce nom vit derrière une connexion, tout comme la plupart de ce qu'on demande à un chatbot e-commerce. Le meilleur commentaire de tout le fil Hacker News est venu de quelqu'un qui avait passé une journée à tester directement la prémisse, en parcourant le web ouvert uniquement en HTTP brut :
"Rendering was almost never the blocker. Identity was."
Quelqu'un d'autre en a tiré la conclusion évidente :
"The missing primitive for agents is not a browser. It is a portable identity and a spendable balance."
Ce que, en toute justice envers Cloudflare, elle construit par ailleurs. La même limite est la raison pour laquelle un protocole de commerce agentique existe et pour laquelle la version de Shopify s'appuie sur des points d'accès structurés plutôt que sur un navigateur. Browser Run propose lui-même désormais une fonction WebMCP dont l'argumentaire entier est de remplacer les boucles capture-analyse-clic par des appels de fonction directs, ce qui en dit long sur l'endroit où Cloudflare pense que tout cela finit.
Il y a aussi un budget réservé au playground, bon à savoir si vous testez là : chaque navigation de page reçoit 20 secondes de temps CPU et 60 secondes de temps réel, puis la page est arrêtée. Un budget correct pour lire un article. Serré pour tout ce qui ressemble à une vraie exécution d'un agent autonome.
Couverture des standards et forme de cette courbe
L'article de lancement annonçait environ 215 000+ sous-tests Web Platform réussis. La documentation de Browser Run indique déjà plus de 235 000 et les détaille par domaine : DOM 97 %, HTML 96 %, Selection 99 %, SVG 97 %, Encoding 99 %, CORS 95 %, XHR 95 %, avec URL à la traîne à 83 %.
Lisez la courbe, pas le titre. Ce n'est pas du tout une rampe régulière, ce sont trois sauts en palier et un plateau de cinq semaines autour de 176 000 jusqu'à fin juin et en juillet, puis un saut tout à la fin. C'est ce à quoi ressemble une équipe qui règle des domaines entiers de la spécification par lots, et cela veut dire que extrapoler un rythme hebdomadaire à partir de là, dans un sens comme dans l'autre, est une mauvaise lecture.
La conformité n'est pas non plus la même chose que le bon fonctionnement, et Cloudflare le dit elle-même, c'est pourquoi elle associe WPT à des tests d'intégration Puppeteer multi-étapes et à des exécutions de régression visuelle face à Chromium à chaque étape. Cet instinct, selon lequel une suite de tests réussie n'est pas un utilisateur satisfait, est le même que celui qui sous-tend les tests adversariaux pour les agents IA. C'est aussi pourquoi j'insiste sur une simulation sur de vrais tickets historiques avant qu'une classification de tickets n'entre en production.
Un petit détail. Le changelog de Browser Run que l'article vous demande de surveiller ne contient pas encore d'entrée Kitesurf, sa ligne la plus récente datant du 28 juillet.
La question de sécurité à laquelle l'isolat ne répond pas
L'histoire de sécurité de Cloudflare, c'est l'isolation, et c'est une bonne histoire. Chaque chargement de page est traité comme non fiable, chaque session démarre à neuf, et l'accès réseau passe par un seul worker SandboxOutbound qui applique CORS, injecte des en-têtes de forme navigateur, garde les cookies de chaque page dans son propre bocal et renvoie 403 à tout ce qui échoue à la politique. Rien d'autre ne touche le réseau, du tout. Comme posture, c'est plus solide que la plupart de ce que je lis en auditant des fournisseurs sur les questions SOC 2 et RGPD, ou dans la liste de contrôle de confidentialité des données que tout acheteur d'entreprise envoie.
La critique la plus acérée du fil était que cela protège dans la mauvaise direction :
"The V8 isolate guards the wrong half of this imo. It stops the agent's code from escaping the sandbox, but the risky part of a browser agent isn't code escaping, it's that it reads untrusted pages and then acts on them."
Une réponse est allée plus loin :
"Hidden instructions in product descriptions will become the new blackhat SEO: instead of keyword-stuffing for crawlers, stores get prompt-stuffed for agents."
C'est juste, et ce n'est pas vraiment un problème propre à Kitesurf non plus. À l'honneur de Cloudflare, l'article de lancement nomme l'injection de prompt et la sécurité des outils parmi les priorités dans sa section sur le modèle de menace, il ne prétend simplement jamais que l'isolat les résout. Rien au niveau du navigateur ne le peut. L'isolat borne ce que l'agent peut exécuter, pas ce qu'on peut le convaincre de faire, donc la solution doit se trouver dans ce que l'agent a ensuite le droit de faire : des outils restreints, des seuils de confiance et un humain sur tout ce qui est irréversible. La même architecture qui empêche un bot de support d'inventer avec aplomb une politique de remboursement, ce que les notes d'eesel sur la prévention des hallucinations et les bonnes pratiques de transfert d'agent détaillent.
Passe-t-il la protection anti-bot de Cloudflare elle-même ?
C'était la question principale du fil, et la spéculation autour est devenue assez bruyante pour mériter une réponse directe. Celso Martinho, qui a écrit l'article de lancement, a répondu lui-même :
"Browser Run requests coming from Chromium or Kitesurf are always identified as bot traffic by Cloudflare."
Les requêtes portent un user agent documenté et sont signées avec Web Bot Auth. Kitesurf ne peut pas non plus négocier de poignée de main de défi anti-bot avec de vraies empreintes TLS, et cela figure comme une limite, pas comme une fonctionnalité. Si votre plan dépendait de paraître humain, ce n'est pas l'outil. Pour cela, le marché dispose déjà de scrapers à proxys résidentiels, l'axe sur lequel tourne la comparaison Firecrawl vs Bright Data d'eesel.
Le malaise stratégique dans le fil était un point distinct et n'a pas reçu de réponse :
"It's pretty bizarre to see them going from being the bot protection platform to differentiating on the kinds of bots they'll block, because now they're facilitating the exact kind of bot automation they made their name protecting against."
Les deux peuvent être vrais en même temps. Kitesurf s'identifie honnêtement, et Cloudflare vend désormais des deux côtés d'une clôture qu'elle a elle-même bâtie.
Le playground est le moyen le plus rapide de le savoir
Il n'y a pas de matrice de compatibilité. La réponse de Cloudflare à la question de savoir si un site fonctionne est d'aller essayer. Le playground public accepte n'importe quelle URL et vous donne les boutons Inspect, Screenshot, PDF et HTML, avec des exemples préchargés couvrant Wikipedia, Hacker News, MDN, quelques journaux et Doom. Le même instinct d'essayer soi-même que derrière les démos de Chrome auto-browse.
https:, un petit indice sur le modèle de menace, capturé depuis kitesurf.cloudflare.app.La meilleure fonctionnalité, ce sont les Chrome DevTools injectés. Cloudflare a implémenté suffisamment de CDP pour que le panneau Memory indique l'empreinte WebAssembly de chaque isolat individuellement, de sorte que l'on voit où va réellement le coût d'une page.
Dans cette capture, une session d'inspection en direct sur la page d'accueil de Wikipedia indique Main à 25,6 Mo, PageRenderer à 24,5 Mo, Engine à 19,4 Mo, soit 69,5 Mo de heap JS au total. À signaler : c'est plus élevé que le chiffre de 57,8 MiB du benchmark, et la raison est qu'une capture de benchmark est un coup unique alors qu'ici trois isolats sont maintenus ouverts avec DevTools attachés. Une attribution par composant comme celle-ci est une instrumentation étonnamment bonne pour une bêta, et honnêtement c'est pour cela que je l'utiliserais en premier. Si ces captures partent ensuite vers un modèle, le travail sur Gemini agentic vision est l'autre moitié du pipeline.
Ce que cela signifie si vous construisez un agent de support
Je livre des intégrations pour vivre, donc ma lecture honnête est celle-ci : Kitesurf est une très bonne brique et non un produit. Cloudflare le présente aussi ainsi.
Si vous construisez des agents qui lisent le web public à grand volume, en faisant des captures de pages, en extrayant du texte d'articles, en générant des PDF, en pré-rendant pour des robots d'indexation, alors cela vaut le coup d'ajouter browser=kitesurf sur un point d'accès cet après-midi. C'est tout le test. Le schéma est le même que derrière tout outil de scraping en tant que service.
Si vous pesez les options de ce côté, les analyses sur les alternatives à Firecrawl et sur Firecrawl vs Scrapy couvrent respectivement le côté achat et le côté construction maison.
Le pré-rendu est le cas discrètement utile. Browser Run propose déjà un tutoriel pour renvoyer du HTML prêt pour les robots d'indexation depuis un Worker, et si c'est la raison pour laquelle vous lisez ceci, alors ce que vous construisez en réalité est un agent IA pour le SEO. Brancher la sortie sur un modèle est également un problème résolu, soit via l'appel de fonctions, soit via une intégration Claude.
Maintenant, si vous construisez un agent IA pour traiter une file de support, un navigateur est presque la partie la moins intéressante de toute la pile. Voici ce que plus de trois ans sur ce problème disent de ce qui décide si cela fonctionne :
- La recherche d'information, pas le rendu. L'agent doit répondre à partir de votre centre d'aide, de vos macros, de vos tickets passés. Rien dans un navigateur ne fait cela, ce qui est à quoi sert une base de connaissances IA, et pourquoi l'entraînement sur votre propre contenu bat un meilleur moteur de rendu à chaque fois. Le côté recherche est tout le jeu ici, ce qui est à peu près l'argument de RAG vs LLM.
- L'identité, exactement comme l'a dit le fil. Vérifier la commande d'un client demande une vue authentifiée dans vos systèmes, et les sessions authentifiées de longue durée sont précisément ce que Kitesurf renvoie explicitement à plus tard. Une intégration par API règle cela dès le premier jour, ce qui explique pourquoi les outils d'automatisation du support sont construits autour du helpdesk et non autour du navigateur.
- Savoir quand s'arrêter. La plus grande objection qu'eesel entend des acheteurs n'est jamais la précision dans l'abstrait, c'est le contrôle. Un responsable CX d'une marque DTC de compléments l'a dit exactement ainsi lors d'un appel : "I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone." C'est un problème de routage, et la raison de privilégier la déviation de niveau 1 avec un chemin d'escalade propre plutôt que l'autonomie partout. C'est aussi la différence pratique entre agents IA et chatbots.
- La preuve avant la mise en production. Cloudflare a testé Kitesurf sur 235 000 sous-tests avant de l'expédier. L'équivalent pour un agent de support est de le rejouer sur vos propres tickets historiques, et c'est la différence entre une démo et un déploiement.
Ce dernier point est aussi la version honnête du construire ou acheter. Plusieurs clients techniques ont quitté eesel pour construire directement sur l'API Claude, dont une entreprise de technologie de la construction en AR et une marque DTC de beauté. Un responsable d'ingénierie d'une entreprise de matériel de distributeurs de bitcoin qui est allé dans l'autre sens l'a le mieux dit : "We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain." Kitesurf abaisse le coût d'une brique. Le mur reste le vôtre, et les briques dont vous avez réellement besoin sont un pipeline RAG, un choix de modèle pour le support, ainsi qu'un endroit où mettre l'automatisation des tickets.
Si c'est le mur que vous voulez, eesel se branche sur Zendesk, Freshdesk, Gorgias, HubSpot ou Front en quelques minutes, lit votre centre d'aide existant et vos tickets passés, puis vous laisse faire un essai à blanc sur l'historique réel avant qu'un seul client ne le voie. Il fonctionne aussi comme copilote, si vous préférez garder un humain à l'envoi. Essayez eesel, gratuitement, et voyez ce qu'un agent de support IA doit vraiment réussir.
En résumé
Kitesurf est la chose la plus intéressante que quiconque ait livrée cette année en automatisation de navigateur, et les chiffres qui le sous-tendent sont publiés avec assez de détail pour qu'on puisse en discuter, ce qui est plus rare qu'il ne devrait l'être. Un moteur de trois mois à 235 000 sous-tests, qui réussit sur Wikipedia, sur Hacker News et sur Doom, en s'exécutant dans des isolats, est une vraie réussite. C'est aussi un pari très différent de la catégorie grand public des navigateurs IA, où le produit est l'interface et non l'environnement d'exécution.
Soyez simplement précis sur ce qu'il vous apporte aujourd'hui. Il apporte 3 à 7 fois moins d'utilisation de ressources en échange de 1,7 à 1,8 fois plus de temps d'horloge, sur une grille tarifaire qui facture le temps d'horloge. Il apporte une migration à un seul paramètre et une liste honnête de quatre choses qu'il ne sait pas faire. Ce qu'il n'apporte pas, c'est un moyen de passer un défi anti-bot, et il ne résout pas non plus l'injection de prompt. Cloudflare dit les deux à voix haute.
Les économies sont réelles. Elles se trouvent simplement du côté de Cloudflare du bilan jusqu'à ce qu'un prix Kitesurf existe pour les vérifier. Pour une charge qui lit le web public à grande échelle, essayez-le cette semaine. Pour un agent qui doit réellement résoudre le problème d'un client, le navigateur n'a jamais été la partie difficile. Le calcul qui compte là-bas est le coût d'un agent humain, pas les heures de navigateur.
Sources
- Introducing Kitesurf - blog de Cloudflare, Celso Martinho, 7 août 2026, l'annonce du navigateur pensé pour les agents
- Kitesurf - documentation Cloudflare Browser Run
- Browser Run pricing - documentation Cloudflare
- Browser Run limits - documentation Cloudflare
- Browser Run changelog - documentation Cloudflare
- Automatic request headers - documentation Cloudflare
- WebMCP - documentation Cloudflare
- Kitesurf playground and benchmark corpus - Cloudflare
- Kitesurf on Hacker News - discussion du lancement, 221 points, 63 commentaires
- Blitz et obscura - dépôts de code source