Cloudflare Kitesurf: qué ofrece gratis y cuánto cuesta

¿Cloudflare Kitesurf es gratis? Sí, mientras siga en beta. Sin embargo, la cuota de uso realmente útil de Workers Free tiene un tope de 10 minutos de navegador por cuenta al día, tres Browser Sessions simultáneas y una nueva sesión cada 20 segundos. Alcanza para un piloto bien acotado, pero no demuestra que toda la infraestructura del agente sea gratuita.

¿Cloudflare Kitesurf es gratis?

Cloudflare Kitesurf no tiene costo mientras el navegador continúe en beta. Cloudflare lo afirma de forma explícita en su actualización del 28 de septiembre de 2026, aunque con una salvedad igual de importante: el acceso está sujeto a los límites de Browser Run de cada cuenta.

Kitesurf es el motor de navegador sin estado de Cloudflare para agentes de IA. Funciona sobre Workers y prescinde de funciones propias de un navegador para personas a cambio de un entorno de ejecución más ligero y orientado a agentes. Hoy no hay un cargo independiente por el motor Kitesurf, pero Browser Run sigue siendo el contador que rodea su uso.

Los límites actuales de Browser Run y los precios de Browser Run marcan cuatro fronteras que conviene comparar:

Por eso, «gratis» es una respuesta útil sobre el producto, pero insuficiente para preparar un presupuesto. Aclara cuánto cobra Cloudflare por Kitesurf durante la beta; no dice si el flujo cabe dentro de los topes de la cuenta, si hará falta Workers Paid ni cuánto costará el modelo del agente.

Los precios y límites de esta guía se verificaron en las páginas públicas de Cloudflare el 29 de septiembre de 2026. Para este análisis no hubo una ejecución autenticada de Browser Run, así que aquí no se inventan facturas del panel, tiempos de ejecución ni tasas de éxito de llamadas a herramientas.

Qué cambió realmente el 28 de septiembre de 2026

La actualización de septiembre convirtió a Kitesurf en una opción más sólida para pilotos de mayor alcance, porque conectó el motor con las interfaces que ya utilizan quienes desarrollan agentes. El lanzamiento inicial de agosto presentó el navegador; esta actualización añadió las superficies prácticas que lo rodean.

En primer lugar, Kitesurf ahora admite WebMCP, una API de navegador con la que un sitio web puede exponer herramientas con nombre y entradas estructuradas. Así, un agente puede llamar a una función del tipo searchFlights() en lugar de deducir botones a partir de píxeles. La documentación de WebMCP de Cloudflare indica que Kitesurf puede enumerar y ejecutar esas herramientas mediante Chrome DevTools Protocol, normalmente abreviado como CDP.

En segundo lugar, Kitesurf ya cuenta con cobertura completa de la API de Browser Run. Se puede seleccionar mediante CDP, Playwright, Puppeteer o MCP. Quick Actions, las interfaces de una sola solicitud de Cloudflare para capturas de pantalla, HTML, PDF y otros resultados habituales, también permiten elegir Kitesurf desde un Worker mediante env.BROWSER.quickAction().

En tercer lugar, el renderizador puede ejecutarse en terminales compatibles mediante el protocolo gráfico Kitty y recurrir a un modo de texto ANSI puro cuando Kitty no está disponible. Esto permite ver la página desde la perspectiva del navegador del agente sin abrir otro navegador de escritorio. Es una comodidad para inspeccionar, no un nuevo nivel de facturación para producción.

Cloudflare también señala en la actualización de septiembre que Kitesurf ya aprueba más de 730,000 subpruebas de Web Platform Tests, más de 500,000 adicionales frente al lanzamiento. Es un avance considerable en compatibilidad, pero no garantiza que cualquier portal de clientes se renderice correctamente. Por eso, el piloto debe seguir limitado a una lista concreta de sitios.

Límites de la beta de Kitesurf: ¿caben diez tareas al día?

Diez tareas diarias solo caben si cada tarea completa consume, en promedio, 60 segundos de navegador o menos. La cuota de Workers Free es de 10 minutos, es decir, 600 segundos de navegador. Al dividir ese presupuesto entre 10 tareas, el umbral queda en 60 segundos por tarea.

La fórmula útil es daily task ceiling = floor(600 / measured browser seconds per task). No se debe reemplazar ese dato por el tiempo de reloj que muestra el registro de una aplicación. En Quick Actions, Cloudflare devuelve el tiempo de navegador en el encabezado de respuesta X-Browser-Ms-Used, según su documentación de precios. Conviene registrar ese valor con la misma tarea y los mismos sitios de destino que se usarán en operación.

El tiempo no es el único límite. La página de límites indica que una cuenta Free puede ejecutar tres Browser Sessions a la vez, iniciar una nueva sesión cada 20 segundos y hacer una solicitud de Quick Actions cada 10 segundos. El tiempo de espera predeterminado por inactividad es de 60 segundos. Cloudflare admite una ventana keep_alive más larga en las integraciones de sesión compatibles, pero su página de WebMCP aclara que Kitesurf no acepta keep_alive en la configuración MCP de Chrome DevTools.

La misma página de límites establece otra frontera Free para /crawl: cinco trabajos de rastreo al día y un máximo de 100 páginas por rastreo. Un agente de investigación que convierta una pregunta en varios rastreos puede agotar la cuota de trabajos mucho antes de consumir los 10 minutos de navegador.

La disciplina al cerrar sesiones también modifica la capacidad disponible. Cloudflare advierte que una sesión abierta sigue consumiendo tiempo de navegador hasta que vence. Un cierre explícito registra NormalClosure; un cierre por inactividad registra BrowserIdle. Es mejor colocar browser.close() en un bloque finally y comprobar después el motivo del cierre, en vez de dar por hecho que el código hizo la limpieza.

La regla de decisión es directa: si la mediana medida se mantiene en 60 segundos o menos y los límites de frecuencia no ponen el trabajo en cola, cabe un piloto de 10 tareas. Si no, hay que reducir la lista de páginas o el alcance de la tarea antes de pagar para escalar un bucle ineficiente.

Precio de Kitesurf: tres límites de costo que sí importan

No existe un único precio, porque Kitesurf, la cuenta de Workers, el uso de Browser Run y el modelo de razonamiento son servicios distintos. Agruparlos en una sola partida de «agente gratis» oculta cuál será el primer costo que aumente.

El costo bruto actual del navegador por encima de la cuota es pequeño para una tarea breve. Con la tarifa publicada de Browser Run, una vez consumidas las 10 horas incluidas en Workers Paid, una tarea de 60 segundos cuesta $0.0015 a $0.09 por hora, antes de sumar simultaneidad, cómputo de Workers, uso del modelo o cargos de un SaaS externo. Esas mismas 10 horas incluidas admiten 600 tareas de navegador de un minuto si el trabajo se distribuye de forma uniforme.

Esa cuenta no debe convertirse en una promesa sobre Kitesurf después de la beta. Cloudflare no ha publicado una tarifa específica para esa etapa en la actualización, la documentación de Kitesurf, la página de precios de Browser Run ni la página de precios de Workers. El mínimo de $5 de Workers Paid compra el nivel de cuenta de Workers; no fija el futuro precio de Kitesurf.

Para un comprador, un presupuesto claro separa el tiempo de navegador, la simultaneidad de sesiones, Workers, el modelo y cualquier sistema de pago con el que interactúe el agente. Un motor de navegador gratuito puede seguir formando parte de un flujo de trabajo con costo.

Cloudflare Kitesurf en Browser Run: qué cambia para desarrollo, operaciones y compras

La plataforma está preparada para trabajos acotados y sin estado, no para sustituir a Chromium en todos los casos. Las consecuencias dependen del rol.

Desarrollo: elegir la interfaz más pequeña que complete la tarea

Conviene empezar con una Quick Action cuando el resultado buscado sea una captura de pantalla, el contenido de una página, un PDF o una extracción estructurada. Se añade browser=kitesurf al endpoint, se mide el tiempo de navegador devuelto y solo se pasa a una sesión completa cuando la tarea exige navegación o conservar estado entre varias acciones.

WebMCP resulta atractivo cuando un sitio compatible expone exactamente la acción que necesita el agente. Sustituye un bucle visual frágil por una herramienta con nombre, aunque no elimina la necesidad de validar la implementación del sitio, sus límites de permisos y el resultado.

Cuando una sesión para clientes avanza hacia producción, la elección del motor debe acompañarse con controles de Browser Run. La guía sobre hosts aprobados y revisión de cliente en modo de solo lectura aborda el límite de destinos que la elección de navegador, por sí sola, no resuelve.

Operaciones: medir por separado el trabajo normal y los fallos

Para cada clase de tarea, operaciones debería registrar los milisegundos de navegador, el motivo de cierre, el resultado de la solicitud y el uso del modelo. Una extracción exitosa y una página que agota el tiempo de espera no representan la misma carga. Promediarlas oculta si hay que corregir el navegador, el sitio o el bucle del agente.

Ante una tarea fallida, conviene preservar las pruebas antes de iniciar otra ejecución. El flujo de inspección de Browser Run de Cloudflare puede mostrar la consola, la red y el estado final de la página después de una sesión grabada. La guía para depurar una tarea fallida antes de repetirla explica cuándo esas pruebas valen más que un nuevo intento inmediato.

Compras: adquirir capacidad solo después de comprobar la compatibilidad

No conviene subir de plan solo porque el contador Free llegó al límite. Primero hay que confirmar que Kitesurf renderiza los sitios de destino y completa correctamente la tarea. Después se determina si el cuello de botella está en el tiempo diario de navegador, la frecuencia de solicitudes, la simultaneidad o el modelo.

La documentación actual de Cloudflare establece cómo repartir las cargas entre motores. Kitesurf encaja en renderizado puntual compatible, extracción y trabajo de agentes sin estado en ráfagas. Chromium sigue siendo la opción cuando el flujo requiere video, WebGL, un desafío antibots con huellas TLS reales o una sesión autenticada de larga duración con estado persistente.

La decisión puede tomarse antes de un despliegue amplio: una tarea representativa, un conjunto de sitios de destino, una distribución medida del tiempo de navegador y una alternativa explícita. Si esa alternativa se activa con frecuencia, el motor más pequeño no está reduciendo el costo operativo.

Quién debería actuar ahora, quién debería esperar y quién apenas notará el cambio

Actuar ahora tiene sentido para quien gestiona un flujo de soporte, investigación o QA basado en páginas públicas o de bajo riesgo. Entre los buenos pilotos están capturar una pantalla de un centro de ayuda, extraer una nota de versión, comprobar un componente renderizado o llamar a una herramienta de búsqueda WebMCP en un sitio compatible. Son tareas breves, auditables y fáciles de comparar con un resultado conocido.

Esperar es lo prudente si el flujo depende de un inicio de sesión persistente, video, WebGL, compatibilidad con desafíos antibots o confirmación sin supervisión de acciones sensibles de WebMCP. Las sesiones de Kitesurf no aparecen en wrangler browser list y no tienen vista en vivo. Por eso, según Cloudflare, una sesión de agente en Kitesurf no puede completar una herramienta que se detenga para pedir confirmación humana; esa interacción requiere el playground manual.

También conviene esperar antes de asumir un compromiso presupuestario que se extienda más allá de la beta. El navegador actual es gratuito, pero no existe un precio publicado de Kitesurf para después de esa etapa que pueda incluirse en un contrato largo o en una cotización de margen fijo para clientes.

El impacto será mínimo si un flujo estable de Chromium en Browser Run ya cumple sus objetivos de costo y confiabilidad. La versión de septiembre ofrece otro backend para evaluar, pero no obliga a migrar un navegador de producción que ya funciona.

Qué se exagera sobre la beta gratis

La palabra «gratis» abarca demasiado cuando se usa para describir al agente completo. Se refiere a la disponibilidad de Kitesurf durante la beta, no al modelo, al tiempo del operador, al SaaS de destino ni a un futuro precio comercial.

WebMCP tampoco elimina los fallos del navegador. Cloudflare documenta cuatro carencias relevantes de la implementación actual de Kitesurf: no hay una política de permisos para herramientas WebMCP ni filtrado por origen, las herramientas de iframes o ventanas emergentes no se exponen mediante CDP, las sesiones de Kitesurf no tienen vista en vivo y el agente no puede confirmar por sí solo las herramientas que requieren intervención humana. Una función con nombre es más confiable que hacer clic por píxeles solo si la página expone y protege la función correcta.

El renderizador de terminal mejora la visibilidad, pero no es una estrategia de despliegue. Sirve para que quien desarrolla vea lo que ve Kitesurf; no modifica los minutos de navegador, la simultaneidad, el costo del modelo ni la compatibilidad de los sitios.

El relato sobre rendimiento exige la misma cautela. En el benchmark de mediana de Cloudflare, realizado con cinco ejecuciones de Quick Actions sobre un conjunto de 14 URL, Kitesurf consumió 380 ms de CPU para una captura de pantalla, frente a 1,173 ms de Chromium en un pool precalentado, y 57.8 MiB de memoria, frente a 271.0 MiB. También fue más lento en tiempo total: 1,148 ms frente a 637 ms. Consumir menos recursos es valioso al escalar, pero no significa que cada solicitud individual termine antes.

Por último, aprobar más de 730,000 subpruebas demuestra un avance rápido, no una paridad total con la web. Una matriz de compatibilidad construida con los sitios de destino sigue siendo más valiosa que un recuento global de pruebas.

La tarea del lunes: ejecutar un piloto acotado

El siguiente paso adecuado es una prueba controlada de cuenta, no una migración de arquitectura. Esta página no ejecutó una solicitud autenticada de Browser Run, por lo que la secuencia siguiente es un piloto reproducible, no un benchmark que se presente como experiencia directa.

1. 1

   Inspeccionar la superficie pública

   Abre el playground de Kitesurf en Cloudflare Radar. En DevTools, entra en Application > WebMCP y anota las herramientas que Cloudflare afirma que Radar expone, incluidas navigate-to y set-location. Su presencia no demuestra que el sitio de destino ofrezca herramientas equivalentes.

2. 2

   Ejecutar una tarea representativa

   Usa una cuenta de prueba existente para una solicitud de contenido o de captura de pantalla. La estructura documentada por Cloudflare para una captura es:

   curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/browser-run/screenshot?browser=kitesurf' \
     -H 'Authorization: Bearer <API_TOKEN>' \
     -H 'Content-Type: application/json' \
     -d '{"url":"https://example.com"}' \
     --output screenshot.png

   Empieza con un destino no sensible. Comprueba que el resultado sea correcto antes de optimizar la velocidad.

3. 3

   Registrar cada frontera de costo

   Registra el plan de Workers, X-Browser-Ms-Used para una Quick Action, el uso de Browser Run, el motivo de cierre de la sesión y el uso del modelo. En una Browser Session, ciérrala de forma explícita y confirma NormalClosure en lugar de BrowserIdle.

4. 4

   Calcular la capacidad de la cuota

   Divide 600 entre los segundos de navegador medidos por cada tarea exitosa y redondea hacia abajo. Un día de 10 tareas exige un promedio medido de 60 segundos o menos. Mantén la factura del modelo en una columna aparte y decide después si el piloto cabe en Free, necesita una tarea más acotada o justifica Workers Paid.

Esa sola ejecución aporta las pruebas que faltan: compatibilidad, tiempo de navegador, comportamiento al cerrar y costo del modelo para una tarea que el negocio realmente repetiría.

Si quieres que el próximo cambio de precio o límite en la infraestructura para agentes se convierta en una decisión operativa concreta, suscríbete al newsletter.