Cloudflare publicó el 13 de noviembre de 2026 el código de Kitesurf bajo licencia Apache 2.0, el navegador que su plataforma usa para que los agentes de IA lean y capturen páginas web. El anuncio de Cloudflare describe un motor sin estado que corre entero dentro de Workers: interpreta el HTML, aplica el CSS, ejecuta el JavaScript de cada página y genera capturas sin un contenedor de navegador detrás. No hay un Chrome escondido en ninguna parte del invento.
La cuenta que publica la documentación de Browser Run, el servicio donde conviven los dos motores, ayuda a poner tamaño al cambio. En una captura de pantalla, Kitesurf gasta 380 ms de CPU y 57,8 MiB de memoria, frente a los 1.173 ms y los 271 MiB de Chromium. El mismo informe reconoce que devuelve la imagen más tarde: 1.148 ms contra 637 ms, porque aquí no hay procesos calientes esperando.
Menos máquina y más espera, ese es el trueque. El interés del anuncio no está en la cifra de CPU, sino en la forma: el navegador del agente deja de ser un proceso privilegiado, con su sistema de ficheros y su sesión, y pasa a ser una función que se invoca, se aísla y se apaga al terminar.
Un motor de navegador que vive dentro de una función
Dentro del repositorio de Kitesurf la pieza pesada no es JavaScript, sino una colección de paquetes Rust compilados a WebAssembly. Blitz resuelve el análisis de HTML, el DOM, el diseño y el pintado. Stylo se ocupa de la cascada de CSS y de los estilos calculados. Boa ejecuta el JavaScript de la página y queda como último recurso cuando el motor no puede usar Dynamic Workers. Las librerías de Linebender aportan composición de texto y gráficos 2D, y Krilla fabrica el PDF. Cada proyecto conserva su licencia y el archivo NOTICE recoge los avisos de terceros.
La arquitectura se reparte en tres piezas. Engine gestiona las sesiones y las conexiones de los clientes, PageScript ejecuta la página y su JavaScript, y PageRenderer dibuja el resultado en píxeles. Como el motor habla el Chrome DevTools Protocol, un cliente de Puppeteer, Playwright o MCP se conecta por WebSocket y lanza las mismas órdenes que contra Chrome.
Ese protocolo no equivale a un Chrome completo, y el repositorio lo admite sin adornos: algunas funciones de DevTools todavía no responden. Lo que sí hay es superficie suficiente para abrir una página, leer el DOM, pulsar un botón y guardar la captura del resultado.
Respetando estándares
La conformidad con los estándares también está publicada, y ahí se nota el perfil del motor. Las pruebas del DOM pasan al 97%, las de HTML al 96% y las de selección de texto al 99%, mientras las de URL se quedan en el 83%. Son cifras de un motor que prioriza lo que un modelo necesita leer, no la experiencia de una persona recorriendo una web con el ratón.
La otra pieza que llegó el 28 de septiembre de 2026 fue WebMCP, el mecanismo que permite a una web publicar funciones que el agente llama en vez de simular clics. Con eso el motor deja de adivinar qué botón pulsar y recibe herramientas con nombre, lo que rebaja el coste en tokens de cada tarea. Desde entonces Kitesurf cubre también la API completa de Browser Run.
Lo de sin estado merece una explicación, porque ordena casi todo lo demás. Cada página vive en un Worker aislado que existe mientras dura la tarea, y nada sobrevive entre visitas: ni cookies, ni carrito, ni memoria del formulario anterior. Ganar aislamiento así es barato; reconstruir una sesión con login y mitad de un pedido dentro, en cambio, no lo es tanto.
Para un agente que resume noticias o extrae fichas de producto, el intercambio sale a cuenta. Para uno que administra una cuenta ajena protegida con doble factor, el motor se queda corto por diseño y lo dice.
Lo que se gana y lo que se pierde con un motor sin estado
La comparación de la documentación mide dos tareas de agente, captura de pantalla y extracción de HTML, con medianas de cinco ejecuciones sobre un corpus de 14 URL. Leída entera, la tabla explica por qué el ahorro no sale gratis y por qué Chromium sigue siendo el motor por defecto del servicio.
| Métrica |
Kitesurf |
Chromium en Browser Run |
Diferencia |
| CPU en captura de pantalla |
380 ms |
1.173 ms |
3,1 veces menos |
| Memoria en captura de pantalla |
57,8 MiB |
271,0 MiB |
4,7 veces menos |
| Memoria al extraer HTML |
39,4 MiB |
273,7 MiB |
7,0 veces menos |
| Tiempo de pared en captura |
1.148 ms |
637 ms |
1,8 veces más lento |
| Tiempo de pared al extraer HTML |
820 ms |
472 ms |
1,7 veces más lento |
El patrón tiene una explicación técnica sencilla. Chromium calienta un compilador just-in-time y reutiliza procesos entre peticiones, de modo que responde antes en la primera visita. Kitesurf paga el arranque de un renderizador en software y lo compensa gastando mucha menos máquina por página, que es la partida que escala mal cuando hay mil agentes en paralelo.
Hay webs que este motor no atiende, y la lista es explícita: vídeo, WebGL, desafíos antibot que exigen una huella TLS real y sesiones autenticadas que duran horas con estado persistente. Para todo eso, la propia documentación manda usar Chromium.
Ahí está el límite práctico. Un agente que compra, reserva o rellena un formulario de tres pasos choca con ese muro antes o después, y cuando maneja dinero el motor pasa a formar parte del camino del pago. Ese terreno lo están cerrando los protocolos de micropagos entre agentes, donde MCP y A2A discuten quién pide, quién firma y quién cobra cada operación.
Un motor que no trae autenticación
Autoalojar Kitesurf es un comando, y también el riesgo que el repositorio documenta con un aviso en mayúsculas. El motor no tiene autenticación propia: quien tenga la URL puede navegar por la web a través de tu cuenta, conectar su cliente de CDP, lanzar peticiones salientes con tu identidad y consumir los Dynamic Workers que pagas. La recomendación oficial es poner Cloudflare Access delante antes del primer despliegue.
El despliegue exige el plan de pago de Workers porque cada página necesita su propio Worker aislado, y ese detalle separa el producto de la demostración de feria. La versión gestionada sigue en beta y gratis con límites por cuenta, así que probarla no cuesta nada y operarla sí.
El modelo de amenaza se mueve con el inquilino. Antes el navegador corría en la máquina de alguien; ahora ejecuta código de una web desconocida dentro de la infraestructura de quien lo opera, con su red, sus credenciales y su factura.
Los incidentes de esa clase ya existen. Un ataque con IA que expuso datos de clientes de Chainstack entró por un servidor de pruebas con claves de fábrica y acabó atribuido a agentes que exploraban el entorno sin supervisión. Un navegador de agente sin puerta delante es la misma categoría de fallo, con una vuelta de tuerca: aquí el agente además sale a internet.
¿Quién audita al navegador que paga por ti?
Cloudflare publicó los benchmarks y el panel de conformidad en abierto, y esa decisión pesa más de lo que parece cuando cualquiera puede desplegar el motor en su propia cuenta. Un navegador que lee datos privados y firma pagos en nombre de otro necesita números que un tercero pueda repetir en su máquina, no una demostración que sale bien en la presentación. El código Apache 2.0 permite además mirar cómo se aísla cada página, que es donde se juega la seguridad real del invento.
La pelea por el comercio entre agentes mide la ambición del movimiento. Mientras Google y OpenAI se disputan el protocolo con el que un agente elige, negocia y paga, quien controla el motor que dibuja la tienda controla lo que el agente llega a ver. Kitesurf no gana esa guerra esta semana, pero deja el motor en manos de quien quiera auditarlo.
