Sin Chromium dentro. Eso es lo primero que hay que decir. Cloudflare lanzó un navegador que escribió desde cero en doce semanas, que se ejecuta por completo en aislados V8 sobre Workers, sobre todo Rust compilado a WebAssembly. Vive dentro de Browser Run, gratis mientras dure la beta. Pasa más de 235.000 subtests de Web Platform. Además, ejecuta Doom.
El intercambio es real y, a su favor, Cloudflare publica las dos mitades. En tareas comunes de agentes, Kitesurf usa de 3,1 a 3,8 veces menos CPU y de 4,7 a 7 veces menos memoria que Chromium. También tarda de 1,7 a 1,8 veces más en el reloj. Y ahora, la parte en la que vale la pena detenerse. La tarifa publicada de Browser Run factura horas de navegador y navegadores concurrentes. No CPU. No memoria. Lo que significa que, a los precios de hoy, el contador que Kitesurf gana es el de Cloudflare, y el contador que pierde es el tuyo. Nadie lo paga todavía porque la beta es gratis, y Cloudflare dice que el ahorro llegará también a los clientes. Simplemente no hay ninguna tarifa de Kitesurf publicada con la que comprobarlo.
Yo construyo las integraciones de eesel, así que un lanzamiento como este me parece una lista de la compra de piezas, no un producto. Más de tres años poniendo agentes de IA en colas de soporte reales me han enseñado una cosa sobre los agentes que manejan navegadores. Casi nunca falla el renderizado. Falla la identidad. eesel ha perdido clientes que se fueron a construir directamente sobre la API de Claude, y todos los que volvieron dijeron la misma frase: que la demo era el 20 % fácil. Así que, si quieres que la IA responda tickets en lugar de hacer capturas de páginas, eesel se conecta a tu helpdesk y a tu documentación, y luego se reproduce sobre tu historial real de tickets antes de hablar con ningún cliente. Gratis para probar. Sin navegador.
El contador que Kitesurf optimiza no es el que pagas
Empecemos por la frase de la propia documentación de Cloudflare: "Kitesurf wins on the memory and CPU that drive your bill (by 3-7x)."
Ahora abre la página de precios de Browser Run, actualizada por última vez en abril de 2026. Hay exactamente dos contadores:
| Contador | Workers Free | Workers Paid |
|---|---|---|
| Horas de navegador | 10 minutos al día | 10 horas/mes, luego 0,09 $ por hora |
| Navegadores concurrentes (solo Browser Sessions) | 3 | 10, en promedio mensual, luego 2,00 $ por navegador |
Ninguno es CPU. Ninguno es memoria. Las horas de navegador son tiempo real de reloj, informado por solicitud en la cabecera de respuesta X-Browser-Ms-Used, y las Quick Actions se cobran solo por horas de navegador. Los navegadores concurrentes son un recuento de unidades, no una medida de recursos. La misma distinción que hace tan difícil comparar entre proveedores los precios de las APIs de LLM.
Así que, con la tarifa publicada, ejecutar el mismo trabajo en Kitesurf en vez de en Chromium hace que el contador facturado avance aproximadamente de 1,7 a 1,8 veces más rápido. El ahorro de CPU y memoria es grande y real, pero aterriza en la flota de Cloudflare, donde una sesión de captura de pantalla baja de 271,0 MiB a 57,8 MiB. Una ventaja real de plataforma, y justo el tipo de cosa que luego permite a un proveedor subir los topes de concurrencia y bajar precios. Todavía no es una línea de tu factura. Cualquiera que haya intentado modelar el coste por resolución sabe lo lejos que pueden estar el coste unitario de un proveedor y tu precio unitario.
Dos salvedades, que prefiero decir claramente en vez de enterrarlas. Primera: el tiempo real del benchmark y los ms de navegador facturados se miden de forma distinta, así que trata ese multiplicador como una dirección y no como un decimal. Segunda: Kitesurf es gratis durante la beta, lo que hace que la respuesta honesta a "¿cuánto cuesta?" sea nada, hoy. La pregunta real es qué pasa en la disponibilidad general. Esa respuesta no está publicada.
Esta es la aritmética con la tarifa actual, para que pongas tu propio volumen:
Con un millón de capturas al mes, la diferencia sale en torno a 12,78 $. Con diez millones, unos 128 $. Cifras absolutas pequeñas, porque Browser Run ya es barato de partida, y eso forma parte de la lectura honesta: hoy nadie elige Kitesurf para ahorrar en horas de navegador. Lo elegirían porque la capacidad propia de Cloudflare se abarata, que es como se llega con el tiempo a techos de concurrencia más altos y una mejor tarifa. Ese techo ya se ha movido dos veces este año, de 30 a 120 en abril y luego a 200 en la página de límites actual.
Qué es realmente Kitesurf
Tres componentes. Por una vez, los nombres son inusualmente literales.
El Engine es la única pieza de cara al público. Habla el Chrome DevTools Protocol sobre WebSocket más una superficie REST por HTTP, y es también el único componente que guarda el estado de la sesión. Esa elección de CDP es toda la historia de compatibilidad, en términos de adopción: apunta Puppeteer, Playwright, chrome-remote-interface o cualquier agente que hable MCP y CDP, y funciona. Lo activas añadiendo browser=kitesurf al endpoint. Esa es toda la migración.
PageScript es donde vive realmente una página. Cada página, y también cada iframe fuera de proceso, recibe su propio aislado de larga duración levantado a través de Dynamic Workers, con un globalThis limpio y un documento DOM. El análisis de HTML y CSS viene de Blitz y Stylo, el analizador de CSS de Firefox. Ambos en Rust.
PageRenderer convierte la página calculada en píxeles. Sin estado, solo con una caché desechable, y el Engine le llama a renderFrame() por Workers RPC. Como no guarda nada, un renderizado atascado simplemente se mata y se reintenta en lugar de depurarse.
Dos detalles ahí valen más que el propio diagrama de arquitectura.
El primero: Workers sigue sin admitir eval de forma nativa, por razones de seguridad. La solución de Cloudflare es ejecutar Boa, un motor ECMAScript escrito en Rust, dentro del aislado. Como dijo un comentarista, eso es un motor de JS escrito en Rust, compilado a Wasm, ejecutándose dentro de V8. Celso Martinho, que escribió la publicación, coincidió en Hacker News y dijo que migrarán fuera de Boa cuando llegue eval nativo. Es raro ver a un proveedor calificar su propia capa de subóptima en la publicación de lanzamiento.
El segundo trata de dónde salió la idea. Cloudflare reconoce a obscura, un motor headless en Rust con licencia Apache-2.0, como la inspiración inicial, y dice que el primer intento fue portarlo a Workers con un agente de IA, lo que "didn't work very well at first." Luego su autor apareció en el hilo:
"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."
A día de hoy ese repositorio tiene 22.186 estrellas.
El benchmark, leído línea por línea
Cloudflare publica medianas de cinco ejecuciones de Quick Actions de Browser Run sobre un corpus de 14 URL, cuyo contenido se puede leer: Hacker News, Wikipedia, MDN, tres periódicos (The Guardian, El Mundo y RTP), más cinco versiones de TodoMVC.
| Métrica | Kitesurf | Chromium (pool en caliente) | Kitesurf, relativo |
|---|---|---|---|
| CPU: captura de pantalla | 380 ms | 1.173 ms | 3,1 veces menos |
| CPU: extracción de HTML | 229 ms | 877 ms | 3,8 veces menos |
| Memoria: captura de pantalla | 57,8 MiB | 271,0 MiB | 4,7 veces menos |
| Memoria: extracción de HTML | 39,4 MiB | 273,7 MiB | 7,0 veces menos |
| Tiempo real: captura de pantalla | 1.148 ms | 637 ms | 1,8 veces más lento |
| Tiempo real: extracción de HTML | 820 ms | 472 ms | 1,7 veces más lento |
Tres cosas que merece la pena notar aquí.
La comparación se hace contra un pool en caliente, que Cloudflare nombra en el propio encabezado de la columna en lugar de esconderlo. Un Chromium en caliente tiene un JIT que ya vio la página; Kitesurf es un renderizador por software en frío, siempre. Lo que lo convierte en una pelea justa para una carga de agentes a ráfagas y en una injusta para una sesión larga. En cualquier caso, el planteamiento es honesto.
La memoria de Chromium apenas varía entre las dos tareas, 271,0 MiB frente a 273,7 MiB, mientras que la de Kitesurf baja de 57,8 a 39,4 MiB. Esa es la forma real del argumento: Chromium paga un navegador entero te pidan o no dibujar algo, y Kitesurf paga más o menos en proporción al trabajo. Es la misma razón por la que los precios de IA medidos por tokens se comportan distinto de los precios por usuario, y por la que los precios de GPT-5.6 premian los prompts cortos.
Y ese corpus son catorce páginas con mucho texto y bien portadas. Un sustituto razonable de "extrae este artículo", uno malo para un flujo de pago.
Lo que todavía no puede hacer
Cloudflare enumera cuatro carencias, y prefiero citarlas a parafrasearlas: reproducir vídeo, renderizar WebGL, negociar un handshake de desafío anti-bots con huellas TLS reales o iniciar una sesión autenticada de larga duración que requiera estado persistente. Para cualquiera de ellas se usa el Chromium predeterminado de Browser Run.
La cuarta es la limitación que sostiene todo. Un agente que hace algo comercialmente interesante en la web pasa la mayor parte de su vida con sesión iniciada, y este es exactamente el caso que Kitesurf aplaza hoy. Cualquier asistente de compras que valga la pena vive tras un inicio de sesión, y también la mayor parte de lo que se le pide a un chatbot de ecommerce. El mejor comentario de todo el hilo de Hacker News vino de alguien que había pasado un día probando la premisa directamente, recorriendo la web abierta solo con HTTP en bruto:
"Rendering was almost never the blocker. Identity was."
Otra persona sacó la conclusión obvia:
"The missing primitive for agents is not a browser. It is a portable identity and a spendable balance."
Algo que, en justicia con Cloudflare, están construyendo por separado. La misma limitación es la razón por la que existe un protocolo de comercio agéntico y por la que la versión de Shopify se apoya en endpoints estructurados en lugar de un navegador. Browser Run ya incluye una función WebMCP cuya propuesta entera es reemplazar los bucles de captura-análisis-clic por llamadas directas a funciones, lo que dice bastante sobre dónde cree Cloudflare que termina todo esto.
Hay también un presupuesto solo para el playground, que conviene saber si pruebas ahí: cada navegación de página recibe 20 segundos de tiempo de CPU y 60 segundos de tiempo real, y luego se detiene la página. Un presupuesto correcto para leer un artículo. Ajustado para cualquier cosa parecida a una ejecución real de un agente autónomo.
Cobertura de estándares y la forma de esa curva
La publicación de lanzamiento afirmaba unos 215.000+ subtests de Web Platform superados. La documentación de Browser Run ya dice más de 235.000 y los desglosa por área: DOM 97 %, HTML 96 %, Selection 99 %, SVG 97 %, Encoding 99 %, CORS 95 %, XHR 95 %, con URL rezagada en 83 %.
Lee la curva, no el titular. No es una rampa suave en absoluto, son tres saltos escalonados y una meseta de cinco semanas en torno a 176.000 hasta finales de junio y entrado julio, y luego un salto justo al final. Así se ve un equipo que despeja áreas enteras de la especificación por lotes, y significa que extrapolar un ritmo semanal a partir de ahí, en cualquier dirección, es una mala lectura.
La conformidad tampoco es lo mismo que funcionar, y Cloudflare lo dice, por lo que combina WPT con pruebas de integración de Puppeteer de varios pasos y ejecuciones de regresión visual contra Chromium en cada paso. Ese instinto, que una suite de pruebas aprobada no es un usuario satisfecho, es el mismo que hay detrás de las pruebas adversariales para agentes de IA. Es también la razón por la que insisto en una simulación sobre tickets históricos reales antes de poner en marcha cualquier clasificación de tickets.
Un detalle menor. El changelog de Browser Run que la publicación te pide vigilar no trae todavía ninguna entrada de Kitesurf, y su línea más reciente es del 28 de julio.
La pregunta de seguridad que el aislado no responde
La historia de seguridad de Cloudflare es el aislamiento, y es una buena historia. Cada carga de página se trata como no confiable, cada sesión empieza limpia y el acceso a la red pasa por un único worker SandboxOutbound que aplica CORS, inyecta cabeceras con forma de navegador, mantiene las cookies de cada página en su propio contenedor y responde 403 a todo lo que no cumple la política. Nada más toca la red, en absoluto. Como postura, es más sólida que la mayoría de lo que leo al auditar proveedores en cuestiones de SOC 2 y GDPR, o en la lista de comprobación de privacidad de datos que envía todo comprador empresarial.
La crítica más afilada del hilo fue que esto protege la dirección equivocada:
"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."
Una respuesta fue más allá:
"Hidden instructions in product descriptions will become the new blackhat SEO: instead of keyword-stuffing for crawlers, stores get prompt-stuffed for agents."
Es razonable, y tampoco es realmente un problema de Kitesurf. En honor a Cloudflare, la publicación de lanzamiento sí menciona la inyección de prompts y la seguridad de las herramientas como prioridades máximas en su sección de modelo de amenazas; simplemente nunca afirma que el aislado las resuelva. Nada en la capa del navegador puede. El aislado acota lo que el agente puede ejecutar, no aquello a lo que pueden convencerlo, así que la solución tiene que vivir en lo que el agente tiene permitido hacer después: herramientas acotadas, umbrales de confianza y una persona en todo lo irreversible. La misma arquitectura que evita que un bot de soporte invente con seguridad una política de reembolsos, que las notas de eesel sobre prevención de alucinaciones y buenas prácticas de traspaso de agentes desarrollan.
¿Pasa la protección anti-bots de la propia Cloudflare?
Esta fue la pregunta principal del hilo, y la especulación alrededor creció lo bastante como para merecer una respuesta directa. Celso Martinho, que escribió la publicación de lanzamiento, respondió él mismo:
"Browser Run requests coming from Chromium or Kitesurf are always identified as bot traffic by Cloudflare."
Las solicitudes llevan un user agent documentado y están firmadas con Web Bot Auth. Kitesurf tampoco puede negociar un handshake de desafío anti-bots con huellas TLS reales, y eso figura como limitación, no como función. Si tu plan dependía de parecer humano, esta no es la herramienta. Para eso el mercado ya tiene scrapers con proxies residenciales, el eje sobre el que gira la comparación de eesel Firecrawl vs Bright Data.
La incomodidad estratégica en el hilo era un punto aparte y no obtuvo respuesta:
"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."
Ambas cosas pueden ser ciertas a la vez. Kitesurf se identifica con honestidad, y Cloudflare ahora vende a los dos lados de una valla que levantó ella misma.
El playground es la forma más rápida de averiguarlo
No hay matriz de compatibilidad. La respuesta de Cloudflare a si un sitio funciona es que lo pruebes. El playground público acepta cualquier URL y te da los botones Inspect, Screenshot, PDF y HTML, con ejemplos precargados que cubren Wikipedia, Hacker News, MDN, unos cuantos periódicos y Doom. El mismo instinto de probarlo uno mismo que hay detrás de las demos de Chrome auto-browse.
https:, una pequeña pista sobre el modelo de amenazas, capturado de kitesurf.cloudflare.app.La mejor función son las Chrome DevTools inyectadas. Cloudflare implementó suficiente CDP como para que el panel Memory informe de la huella de WebAssembly de cada aislado por separado, de modo que ves adónde va realmente el coste de una página.
En esa captura, una sesión de inspección en vivo en la página principal de Wikipedia informa de Main con 25,6 MB, PageRenderer con 24,5 MB y Engine con 19,4 MB, es decir, 69,5 MB de heap de JS en total. Conviene señalar que es más que la cifra de 57,8 MiB del benchmark, y la razón es que una captura de benchmark es un solo disparo, mientras que aquí hay tres aislados abiertos con DevTools conectadas. Una atribución por componente así es una instrumentación inusualmente buena para una beta y, sinceramente, es para lo que lo usaría primero. Si luego esas capturas van a un modelo, el trabajo de Gemini agentic vision es la otra mitad del pipeline.
Qué significa esto si construyes un agente de soporte
Me gano la vida lanzando integraciones, así que mi lectura honesta es esta: Kitesurf es una primitiva muy buena y no un producto. Cloudflare también lo presenta así.
Si construyes agentes que leen la web pública a gran volumen, que hacen capturas de páginas, extraen texto de artículos, generan PDF o prerrenderizan para rastreadores, merece la pena probar un browser=kitesurf en un endpoint esta tarde. Esa es toda la prueba. El patrón es el mismo que hay detrás de cada herramienta de scraping como servicio.
Si estás sopesando opciones ahí, los análisis de alternativas a Firecrawl y de Firecrawl vs Scrapy cubren, respectivamente, el extremo de comprar y el de construirlo uno mismo.
El prerrenderizado es el caso discretamente útil. Browser Run ya incluye un tutorial para devolver HTML listo para rastreadores desde un Worker, y si esa es la razón por la que lees esto, entonces lo que estás construyendo en realidad es un agente de IA para SEO. Conectar la salida a un modelo también es un problema resuelto, ya sea mediante function calling o mediante una integración con Claude.
Ahora bien, si estás construyendo un agente de IA para trabajar una cola de soporte, un navegador es casi la parte menos interesante de toda la pila. Esto es lo que, tras más de tres años con ese problema, decide si funciona:
- Recuperación, no renderizado. El agente tiene que responder a partir de tu centro de ayuda, tus macros y tus tickets pasados. Nada de un navegador hace eso, que es para lo que sirve una base de conocimiento con IA, y por lo que entrenar con tu propio contenido supera siempre a un mejor renderizador. El lado de la recuperación es todo el juego aquí, más o menos el argumento de RAG vs LLM.
- Identidad, exactamente como dijo el hilo. Comprobar el pedido de un cliente requiere una vista autenticada de tus sistemas, y las sesiones autenticadas de larga duración son lo que Kitesurf aplaza explícitamente. Una integración por API lo resuelve desde el primer día, y por eso las herramientas de automatización del soporte se construyen alrededor del helpdesk y no alrededor del navegador.
- Saber cuándo parar. La mayor objeción que eesel oye de los compradores nunca es la precisión en abstracto, es el control. Un responsable de CX de una marca DTC de suplementos lo dijo exactamente así en una llamada: "I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone." Eso es un problema de enrutamiento, y la razón para inclinarse por la desviación de nivel 1 con una vía de escalado limpia en lugar de autonomía en todas partes. Es también la diferencia práctica entre agentes de IA y chatbots.
- Prueba antes de salir en vivo. Cloudflare probó Kitesurf contra 235.000 subtests antes de lanzarlo. El equivalente para un agente de soporte es reproducirlo sobre tus propios tickets históricos, y esa es la diferencia entre una demo y un despliegue.
Esa última también es la versión honesta de construir o comprar. Varios clientes técnicos han dejado eesel para construir directamente sobre la API de Claude, entre ellos una empresa de tecnología de construcción con AR y una marca DTC de belleza. Un responsable de ingeniería de una empresa de hardware de cajeros de bitcoin que fue en la dirección contraria lo dijo mejor: "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 reduce el coste de un ladrillo. El muro sigue siendo tuyo, y los ladrillos que realmente necesitas son un pipeline de RAG, una elección de modelo para soporte y un lugar donde poner la automatización de tickets.
Si lo que quieres es el muro, eesel se conecta a Zendesk, Freshdesk, Gorgias, HubSpot o Front en pocos minutos, lee tu centro de ayuda y tus tickets pasados, y luego te deja ensayar todo sobre historial real antes de que lo vea un solo cliente. También funciona como copiloto, si prefieres mantener a una persona en el envío. Prueba eesel, gratis, y mira qué tiene que hacer bien de verdad un agente de soporte con IA.
Conclusión
Kitesurf es lo más interesante que alguien ha lanzado este año en automatización de navegadores, y las cifras que lo respaldan se publican con tanto detalle que se pueden discutir, algo más raro de lo que debería. Un motor de tres meses con 235.000 subtests, que funciona en Wikipedia, en Hacker News y en Doom, ejecutándose en aislados, es un logro real. También es una apuesta muy distinta de la categoría de consumo de navegadores con IA, donde el producto es la interfaz y no el entorno de ejecución.
Solo sé preciso sobre lo que te da hoy. Te da de 3 a 7 veces menos uso de recursos a cambio de 1,7 a 1,8 veces más tiempo de reloj, en una tarifa que factura el tiempo de reloj. Te da una migración de un solo parámetro y una lista honesta de cuatro cosas que no puede hacer. Lo que no te da es una forma de pasar un desafío anti-bots, y tampoco resuelve la inyección de prompts. Cloudflare dice ambas cosas en voz alta.
El ahorro es real. Solo que está en el lado de Cloudflare del libro mayor hasta que exista un precio de Kitesurf con el que comprobarlo. Para una carga que lee la web pública a escala, pruébalo esta semana. Para un agente que tiene que resolver de verdad el problema de un cliente, el navegador nunca fue la parte difícil. La aritmética que importa ahí es el coste de un agente humano, no las horas de navegador.
Fuentes
- Introducing Kitesurf - blog de Cloudflare, Celso Martinho, 7 de agosto de 2026, el anuncio del navegador pensado para agentes
- Kitesurf - documentación de Cloudflare Browser Run
- Browser Run pricing - documentación de Cloudflare
- Browser Run limits - documentación de Cloudflare
- Browser Run changelog - documentación de Cloudflare
- Automatic request headers - documentación de Cloudflare
- WebMCP - documentación de Cloudflare
- Kitesurf playground and benchmark corpus - Cloudflare
- Kitesurf on Hacker News - debate del lanzamiento, 221 puntos, 63 comentarios
- Blitz y obscura - repositorios de código fuente