Kitesurf: el navegador de Cloudflare hecho para agentes

Hacer una captura de pantalla de una web cualquiera le cuesta a Chromium 271 MiB de memoria. A Kitesurf le cuesta 57,8 MiB.

Ahí tienes el post resumido en dos números.

Pero hay una segunda cifra que Cloudflare podría haber escondido y no ha escondido: en tiempo de reloj, Kitesurf es 1,8 veces más lento que Chromium haciendo esa misma captura. Y eso, lejos de hundir el proyecto, es exactamente lo que lo hace interesante.

Porque Kitesurf no compite por el cronómetro. Compite por la factura.

Cloudflare acaba de presentar un navegador entero, construido desde cero en doce semanas, que se ejecuta dentro de isolates de V8 sobre Workers y que está diseñado para que quien navegue sea un agente de IA, no tú. Firman el anuncio Celso Martinho, Ruskin Constant, Rui Figueira y Luís Duarte, y no es un experimento de laboratorio: ya pasa más de 215.000 tests del Web Platform Tests y puedes usarlo hoy, gratis mientras esté en beta, dentro de Browser Run.

Esto es lo que vas a encontrar aquí:

• Por qué un navegador pensado para humanos es mala arquitectura cuando el usuario es un modelo
• Las tres piezas que forman Kitesurf (Engine, PageScript y PageRenderer) y la cuarta que toca la red
• La tabla de benchmarks completa, con la parte incómoda incluida
• Cómo lanzarlo hoy con Puppeteer, Playwright o un cliente MCP cambiando un parámetro
• Lo que todavía no sabe hacer, dicho sin rodeos
• Y la lección de método más aprovechable del anuncio: cómo se construye algo así con agentes sin que se te vaya de las manos

¿Qué es Kitesurf y por qué Cloudflare ha construido un navegador entero? ¶

Kitesurf es un navegador sin estado que se ejecuta por completo sobre Cloudflare Workers y que habla Chrome DevTools Protocol, así que tus clientes actuales (Puppeteer, Playwright, chrome-remote-interface o el propio frontend de Chrome DevTools) funcionan apuntándole sin tocar una línea de código.

La pregunta “¿deberíamos construir nuestro propio navegador?” llevaba años apareciendo en los hilos internos de la empresa y siempre acababa archivada. Lo cuentan ellos mismos en el anuncio: la dificultad técnica nunca compensaba los problemas concretos que resolvería.

Lo que ha cambiado son dos cosas a la vez.

La primera es que la plataforma de Workers ha madurado hasta permitirlo. WebAssembly ya es sólido ahí dentro, y encima han llegado los Dynamic Workers, los Durable Objects con SQLite, el RPC de Worker a Worker, los service bindings, más compatibilidad con Node.js y límites más altos. Sin esas piezas, el proyecto no era viable.

La segunda es la demanda. Browser Run, su producto de automatización headless, ha crecido con la explosión de los agentes por un motivo simple: muchas tareas de agente no se pueden completar sin un navegador. Y ahí aparece el problema de fondo.

Chromium está construido para ti. Para una persona con pestañas, temas, extensiones, sincronización entre dispositivos y una expectativa de scroll a 60 fps. Todo eso cuesta memoria y CPU, y todo eso le da exactamente igual a un modelo de lenguaje. Darle a cada agente su propia instancia de Chromium sale caro, y ese coste actúa como filtro: se lo pueden permitir los modelos grandes y las aplicaciones con presupuesto, y se quedan fuera un montón de casos de uso agénticos que serían perfectamente razonables.

🔑 El argumento de Cloudflare no es “Chromium es malo”. Es que un agente necesita otra cosa: le importan el número de tokens, la ventana de contexto, la escalabilidad y el coste. No le importan las pestañas ni que el CSS quede a pixel perfecto.

Hay un tercer punto en su lista de motivaciones que merece pararse un segundo: el modelo de amenazas cambia. Cuando navegas tú, visitas sitios en los que confías. Cuando navega un agente, va a donde le lleve la tarea, o sea, a código arbitrario de origen arbitrario. Las prioridades pasan a ser la inyección de prompts y la seguridad de las herramientas.

Con eso encima de la mesa, hace doce semanas volvieron a hacerse la pregunta. Esta vez la respuesta fue que sí.

¿De dónde salió la idea? ¶

De un caso de “nerd sniping” de manual.

Alguien del equipo encontró obscura, un motor headless escrito en Rust para automatización con IA cuya carta de presentación es “sin Chrome, sin Node.js, sin dependencias”. Con ayuda de un agente intentaron portarlo a Workers.

Al principio no funcionó bien.

Lo que cambió el resultado no fue un modelo mejor, fue el encargo: en cuanto le dieron al agente un plan sólido y una definición de éxito lo bastante detallada como para poder iterar en bucle y preguntar cuando se atascara, funcionó. Ese matiz es el mismo que aparece cuando montas sistemas de agentes autónomos que aguantan más de veinte minutos sin supervisión.

De esa prueba de concepto medio funcionando salió la decisión de dejar cocinar al equipo.

Curso gratis · paso a paso

El plan y la definición de éxito no se improvisan

Lo que le faltaba al agente de Cloudflare tiene nombre: Spec Driven Development. En este curso recorres el ciclo entero con OpenSpec sobre un proyecto real (proposal, spec, diseño, tareas y archivar) en modo asistido, para verlo funcionar antes de coger tú el volante.

Entra en el curso gratis →

¿Qué decisiones de diseño tomaron antes de escribir código? ¶

Cuatro, y las cuatro se sostienen fuera de este proyecto.

Tests, tests y más tests. Sabían que iban a apoyarse en IA para ganar velocidad, y la única forma de hacerlo sin perder el control de la calidad es tener criterios de éxito abundantes y automáticos. Ahí entra el Web Platform Tests: una batería enorme de conformidad con los estándares del W3C que funciona como portería para los agentes. Los humanos curaban qué features y en qué orden se atacaban, y revisaban el enfoque arquitectónico.

Pero el WPT mide conformidad con la norma, no si una web real se ve bien. Para cubrir ese hueco montaron pruebas de integración y de regresión visual: tests multipaso con Puppeteer sobre webs reales, ejecutados contra Chromium y contra Kitesurf a la vez, comparando tanto las aserciones como el renderizado en cada paso.

Rust siempre que se pueda. Podían haber tirado de Emscripten y sus capas de dependencias simuladas, pero el binario resultante engorda y se ralentiza. Optaron por Rust nativo compilado a WebAssembly con wasm-bindgen, sin capas de emulación intermedias.

Manejo de excepciones como norma de supervivencia. Un navegador tiene que renderizar una web hostil e inestable sin soltar nunca la página que sostiene. La regla que se impusieron es tajante: cualquier fallo degrada a un frame en blanco o a un elemento que falta, nunca a una sesión muerta. Capturar en cada frontera, devolver algo seguro y vacío por defecto, y registrar lo suficiente para diagnosticar.

Sin estado siempre que se pueda. El estado es lo que hace cara la recuperación. Un componente sin estado es desechable y paralelo por naturaleza: lo matas en cuanto se atasca, lanzas mil a la vez y lo dimensionas según la demanda en lugar de mantenerlo caliente. Encaja con una carga que llega a ráfagas, que es justo la forma de la automatización con IA.

💡 Si te llevas una sola idea de método: la IA acelera de verdad cuando le pones portería. Sin una batería de tests que diga qué es “hecho”, no estás delegando, estás generando trabajo de revisión.

¿Cómo está construido Kitesurf por dentro? ¶

En tres componentes principales más uno que hace de aduana con la red. Vamos por partes.

SandboxOutbound: el único que toca Internet ¶

Renderizar una página no confiable obliga a descargar activos arbitrarios: imágenes, fuentes, CSS, JavaScript, archivos Wasm. Es la operación más peligrosa que hace un navegador.

En Kitesurf eso pasa por un solo componente, SandboxOutbound, y nada más puede tocar la red. La restricción no es una convención de equipo: la imponen los Dynamic Workers.

Ese componente aplica CORS, inyecta cabeceras con forma de navegador, filtra respuestas y mantiene las cookies de cada página en su propio tarro. Lo que no pasa la política se va con un 403. Cada componente recibe exactamente la red que necesita y ni un byte más.

Engine: la cara pública ¶

Es el único componente accesible desde fuera. Gestiona el WebSocket de CDP y las APIs REST, sirve una página de aterrizaje para pruebas internas y, sobre todo, guarda el estado de cada sesión. Todo lo demás es apátrida.

La elección de CDP es la razón de que esto sea usable desde el minuto uno: es el mismo protocolo que hablan las herramientas que ya tienes montadas. Si vienes de manejar el navegador desde un agente de IA o de Playwright CLI, tu setup no cambia.

Curiosamente, y pese al nombre, el Engine es el componente más simple de los tres.

PageScript: una página, un isolate ¶

Aquí es donde se nota que esto no se podía construir hace un año.

Cada página nueva o cada iframe fuera de proceso (OOPIF) usa Dynamic Workers para levantar un isolate de PageScript de vida larga que gestiona esa sesión de página: un globalThis limpio y el objeto document del DOM.

Ese objeto DOM se puebla con el resultado de parsear el HTML y ejecutar todos los scripts. Para el parseo de HTML y CSS usan partes de Blitz, un motor de renderizado modular, y Stylo, el parser de CSS de alto rendimiento de Firefox. Ambos escritos en Rust.

Por cada etiqueta <script> o archivo .wasm que aparece, el código se ejecuta dentro de ese mismo isolate.

¿Y qué pasa con eval? ¶

Esta es mi parte favorita del anuncio, porque es donde admiten una solución fea que funciona.

Workers no soporta eval de forma nativa por seguridad. Y no pueden levantar otro isolate para atenderlo, porque ese isolate no tendría acceso al globalThis de la página.

¿La salida? Boa JS, un motor de ECMAScript escrito en Rust, compilado y ejecutándose dentro de Workers. O sea: un runtime de JavaScript ejecutándose encima de otro runtime de JavaScript.

Ellos mismos lo dicen sin adornos: no parece óptimo, y no lo es, pero funciona lo bastante bien para los eval sueltos que aparecen por ahí. Cuando Workers soporte eval nativo, migrarán.

PageRenderer: de objetos a píxeles ¶

El último componente convierte los objetos de página calculados en píxeles de verdad.

Funciona en bucle con el Engine. Cada vez que este necesita un frame, PageRenderer pide la escena a PageScript, descarga las fuentes e imágenes internas desde Static Assets, rasteriza todo en un buffer de imagen y devuelve el resultado en un formato que el cliente pueda mostrar: JPEG, PNG o PDF.

La parte gorda la resuelve otro módulo de Blitz, blitz-paint, que a su vez usa Parley para convertir caracteres en glifos, elegir fuentes y partir el texto en líneas.

El pegamento: RPC entre Workers ¶

Workers trae un sistema de llamadas a procedimiento remoto integrado que permite llamar métodos de otros Workers, pasar objetos entre ellos e invocar métodos de esos objetos. Sin esquemas de API, sin tipos que mantener, sin autenticación que montar: llamas a remoteFunction(...params) y ya está.

Kitesurf lo usa así: el Engine llama a renderFrame() del PageRenderer con una sola llamada RPC y recibe un PNG.

Y aquí está el detalle elegante. Como el renderizador no guarda estado de página (solo una caché desechable), el Engine puede matarlo y relanzarlo ante cualquier RPC fallida o colgada. Cada petición de renderizado es autocontenida, reintentable, y su isolate es barato y de usar y tirar.

Esa frase describe la arquitectura entera mejor que ningún diagrama.

¿Kitesurf es más rápido que Chromium? ¶

No. Y conviene decirlo antes de la tabla, porque la tabla es honesta y la conclusión es más matizada que un titular.

Estos son los datos que publica Cloudflare: medianas de cinco ejecuciones de quick actions de Browser Run sobre un corpus de 14 URLs, comparando Chromium con pool caliente frente a Kitesurf.

Chromium gana el cronómetro y hay un motivo técnico claro: un JIT que ya ha visto esa página siempre le gana a un renderizador software en frío. La mayor parte de esa diferencia viene de la rasterización y de la codificación a JPEG y PNG, que es justo lo que dicen que van a seguir optimizando.

Pero fíjate en qué columnas ganan cada uno.

El cronómetro no es lo que te cobran. Lo que te cobran es CPU y memoria, y ahí Kitesurf va entre 3 y 7 veces por debajo. Menos memoria significa más sesiones simultáneas en el mismo hardware, mejor escalado y menos coste, tanto para ellos como para ti.

⚠️ Traducido a decisiones: si tu carga es una tarea de agente que se ejecuta mil veces al día, medio segundo extra por tarea no te va a doler tanto como multiplicar por cinco la memoria de cada sesión. Si tu carga es una sola captura con un usuario esperando delante de la pantalla, la cuenta te sale al revés.

Ah, y el test que de verdad importa: Kitesurf ejecuta Doom. Concretamente silentspacemarine.com, aquel experimento suyo de hace unos años. Un proyecto no está terminado hasta que corre el Doom, ya lo sabes.

¿Qué cobertura real tiene hoy? ¶

Más de 215.000 tests del WPT en verde, con cientos nuevos cada semana.

El número por sí solo dice poco, así que el dato útil es la distribución: las áreas que le importan a un agente (CSS, DOM, HTML, selección, SVG y XHR) ya tienen buena cobertura. Incluso partes que a priori pintan menos en contexto agéntico, como los streams, están decentemente soportadas.

A día de hoy renderiza bien TodoMVC en sus variantes de vanilla, React, Vue, Angular y Preact, además de Wikipedia, Hacker News, el blog de Cloudflare y buena parte de su propio dashboard.

Esa lista es a la vez una demostración y una advertencia. Son webs de complejidad media, bien construidas, sin gimnasia de navegador. Es exactamente el terreno donde Kitesurf tiene sentido hoy.

Construye agentes con criterio

Elegir qué navegador usa tu agente es una decisión de arquitectura

Las herramientas que le das a un agente, los guardarraíles y la orquestación se deciden igual que Cloudflare decidió su motor. Vas a recorrer los seis niveles de arquitectura, con código, hasta un sistema multiagéntico revisado por otro modelo.

Ver la arquitectura entera →

6 niveles de arquitectura, en directo · Web Reactiva Premium

¿Cómo lo pruebo en mi proyecto? ¶

Cambiando un parámetro en la URL. Literalmente.

El endpoint CDP de Browser Run acepta ahora browser=kitesurf, así que cualquier cliente que ya hable ese protocolo, incluido cualquier agente que hable MCP y CDP, funciona sin cambios de código.

Para una captura rápida con quick actions:

# Captura de pantalla usando el motor Kitesurf en lugar de Chromium
curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/screenshot?browser=kitesurf' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{
    "url": "https://example.com"
  }' \
  --output "screenshot.png"

Y para engancharlo a un cliente MCP (el ejemplo que ellos dan es con Opencode), la configuración apunta el chrome-devtools-mcp al WebSocket de Browser Run:

{
  "mcp": {
    "kitesurf": {
      "type": "local",
      "command": [
        "npx",
        "-y",
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=wss://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/devtools/browser?browser=kitesurf",
        "--wsHeaders={\"Authorization\":\"Bearer <API_TOKEN>\"}"
      ],
      "enabled": true
    }
  }
}

Si prefieres no tocar nada todavía, hay un playground público donde metes una URL y ves cómo la renderiza, con interacción incluida.

Y ahí han hecho algo que agradecerás si te gusta destripar cosas: inyectan Chrome DevTools en la interfaz. Puedes inspeccionar elementos del DOM expandidos, leer la consola y mirar la actividad de red mientras Kitesurf pinta. Han implementado además las instrucciones CDP necesarias para que el panel de Memoria reporte la huella de WebAssembly de cada isolate, frames incluidos.

O sea, puedes ver cuánta memoria te está costando cada página. Que es el número que este navegador ha venido a cambiar.

¿Qué no puede hacer Kitesurf todavía? ¶

Esta lista está en el anuncio original y merece copiarse entera, porque te ahorra media tarde de pruebas.

Si necesitas alguna de estas cuatro cosas, usa el Chromium por defecto de Browser Run:

1. Reproducir vídeo.
2. Renderizar WebGL.
3. Negociar un desafío antibot con huellas TLS reales.
4. Mantener una sesión autenticada larga (del orden de diez minutos) que dependa de estado persistente.

La cuarta es la que más gente va a encontrarse de frente, porque choca de lleno con la decisión de diseño de ser apátrida. Kitesurf está pensado como un motor efímero, aislado y sin estado, vivo solo mientras dura la tarea. Los flujos largos con login no son su terreno.

Su recomendación para saber si un sitio concreto te sirve es la más sensata posible: probarlo. Con la API o con el playground, mirando la consola y las métricas de memoria.

¿Qué significa esto para el resto de nosotros? ¶

Que el navegador acaba de dejar de ser un producto exclusivamente para humanos.

Durante treinta años la web ha optimizado para un solo tipo de usuario: uno con ojos, con paciencia y con un ratón. Todas las capas que hemos ido apilando (el compositor, la aceleración de GPU, el scroll suave, el sistema de extensiones) están ahí por esa persona.

Ahora aparece un segundo tipo de usuario que quiere del navegador algo mucho más corto: dame el DOM, dame un PNG, dame un PDF, y hazlo barato. Ese cliente no necesita el 80% del edificio.

Kitesurf es la primera respuesta seria a esa asimetría desde la infraestructura, y no desde el harness. Es una diferencia importante respecto a lo que ya has visto por aquí: herramientas como el harness Webwright de Microsoft o Playwright CLI mejoran cómo un agente conduce un navegador que sigue siendo el de siempre. Kitesurf cambia el navegador.

Hay dos cosas más en el roadmap que conviene tener en el radar.

La primera es una promesa: van a liberar el código. El objetivo declarado es que cualquier cliente pueda desplegar su propia versión de Kitesurf en su propia cuenta. Si eso ocurre, el cálculo cambia otra vez, porque deja de ser un producto de un proveedor y pasa a ser una pieza que puedes montar donde quieras.

La segunda es más sutil y dice mucho de hacia dónde va esto. Entre sus prioridades está mejorar la fidelidad de renderizado de capturas y PDFs, y el motivo que dan es que los LLM a menudo trabajan mejor a partir de una imagen que del texto subyacente. Un navegador cuyo objetivo de calidad visual se define por lo bien que un modelo lee el resultado. Ahí lo tienes.

¿Kitesurf o Chromium? Tabla de decisión ¶

TL;DR ¶

• 🚀 Kitesurf es el navegador agent-first de Cloudflare: sin estado, sobre Workers y en isolates de V8, gratis mientras dure la beta dentro de Browser Run
• 💸 Gasta entre 3 y 7 veces menos CPU y memoria que Chromium en capturas y extracción de HTML, aunque es 1,7-1,8 veces más lento en tiempo de reloj
• 🧩 Habla Chrome DevTools Protocol, así que Puppeteer, Playwright, chrome-remote-interface o un cliente MCP funcionan añadiendo browser=kitesurf
• 🦀 Por dentro es Rust compilado a Wasm: Blitz y Stylo para parsear, Parley para el texto y Boa JS para los eval que Workers no soporta
• ⚠️ No sirve todavía para vídeo, WebGL, desafíos antibot ni sesiones autenticadas largas: para eso sigue el Chromium por defecto

Preguntas frecuentes sobre Kitesurf ¶

¿Qué es Kitesurf de Cloudflare?
Es un navegador web sin estado, diseñado para agentes de IA, que se ejecuta por completo sobre Cloudflare Workers dentro de isolates de V8. Se anunció el 6 de agosto de 2026 y está disponible gratis en beta dentro de Browser Run, con límites por cuenta.

¿En qué se diferencia Kitesurf de Chromium?
Chromium está diseñado para personas e incluye pestañas, extensiones, sincronización y renderizado pixel perfect. Kitesurf elimina todo lo que un modelo de lenguaje no usa y prioriza consumo de CPU, memoria, escalabilidad y coste. A cambio acepta que el CSS o el renderizado no sean exactos.

¿Cuánta CPU y memoria ahorra Kitesurf?
Según los benchmarks de Cloudflare (medianas de cinco ejecuciones sobre 14 URLs), usa 3,1× menos CPU en capturas y 3,8× menos en extracción de HTML, y entre 4,7× y 7× menos memoria que Chromium en pool caliente.

¿Kitesurf es más rápido que Chromium?
No en tiempo de reloj: es 1,8× más lento en capturas y 1,7× en extracción de HTML. La causa es que un JIT que ya conoce la página gana a un renderizador software en frío, sobre todo en la rasterización y la codificación a JPEG y PNG.

¿Funciona con Puppeteer y Playwright?
Sí. Kitesurf implementa un subconjunto de Chrome DevTools Protocol, y Puppeteer, Playwright, chrome-remote-interface y el propio frontend de Chrome DevTools funcionan apuntándole. Solo hay que añadir el parámetro browser=kitesurf al endpoint de Browser Run.

¿Cómo activo Kitesurf en Browser Run?
Añadiendo browser=kitesurf a la URL del endpoint, tanto en el WebSocket de CDP como en las quick actions REST. No hace falta cambiar el código del cliente ni instalar nada nuevo.

¿Qué webs renderiza bien Kitesurf hoy?
TodoMVC en sus versiones de vanilla, React, Vue, Angular y Preact, además de Wikipedia, Hacker News, el blog de Cloudflare y buena parte del dashboard de Cloudflare. Para cualquier otro sitio, la vía rápida es probarlo en el playground público.

¿Qué limitaciones tiene Kitesurf?
No reproduce vídeo, no renderiza WebGL, no negocia desafíos antibot con huellas TLS reales y no mantiene sesiones autenticadas largas con estado persistente. Para esos casos, Cloudflare recomienda el Chromium por defecto de Browser Run.

¿Kitesurf es open source?
Todavía no, pero Cloudflare ha declarado la intención de liberarlo “cuando esté listo”, con el objetivo de que cualquier cliente pueda desplegar su propia versión en su propia cuenta.

¿Cómo maneja Kitesurf el eval de JavaScript?
Workers no soporta eval nativo por seguridad, así que Kitesurf ejecuta Boa JS, un motor de ECMAScript escrito en Rust, dentro del propio isolate. Es un runtime sobre otro runtime, y el equipo reconoce que no es óptimo, pero cubre los casos sueltos hasta que llegue el soporte nativo.

La pregunta que deja abierta ¶

Doce semanas. Primer commit en mayo. Un navegador que pasa 215.000 tests del WPT y ejecuta Doom.

Lo llamativo no es la velocidad de ejecución, es lo que revela sobre el momento: cuando aparece un usuario nuevo con necesidades distintas, la infraestructura se reescribe para él. Y el usuario nuevo no eres tú.

Así que la pregunta útil no es si Kitesurf está listo para producción, porque no lo está del todo y ellos lo dicen. Es esta otra: ¿cuánto de tu stack está construido para un humano que ya no es quien lo usa?

Ábrete el playground y mira el panel de memoria un rato. Se entiende mejor viéndolo.

Fuentes ¶

• Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers — anuncio original de Celso Martinho, Ruskin Constant, Rui Figueira y Luís Duarte
• Changelog de Cloudflare: Kitesurf en Browser Run
• Playground público de Kitesurf
• Web Platform Tests
• Blitz, motor de renderizado modular en Rust
• Boa, motor de ECMAScript en Rust

🧨 Última oprtunidad para recibir la dinamita que mereces sobre programación con IA el próximo domingo: Suscríbete gratis a Web Reactiva en https://webreactiva.com/newsletter