Cloudflare Web Search API: proveedores, precios y la brecha de 28 veces

Qué es realmente la Cloudflare Web Search API

La presentación en la publicación del lanzamiento, de Michelle Chen, Sam Else y Gabriel Massadas, empieza con una admisión divertida. Cuando un agente necesita una página en vivo, suele adivinar la URL y hacerle un curl, por eso se ven tantos 404 en los registros de agentes. La búsqueda web le da al agente un punto de partida real: envía una consulta, recibe una lista de resultados y pásalos al modelo.

Por dentro es una capa de enrutamiento, no un motor de búsqueda. La página About de Cloudflare enumera cuatro pasos para cada solicitud:

1. Enrutar la solicitud a través del AI Gateway que indiques.
2. Reenviar la consulta al proveedor que elegiste, o a Ceramic.ai si no elegiste ninguno.
3. Normalizar la respuesta a un único formato: URL, título y, opcionalmente, descripción, imagen, favicon y fecha de última modificación.
4. Registrar la solicitud y facturarla a tu cuenta.

Hoy ese es todo el producto, y lo digo como un cumplido. Si ya haces tus llamadas a modelos a través de AI Gateway, la búsqueda aparece ahora en los mismos registros, con el mismo presupuesto y bajo las mismas reglas de acceso. Cloudflare también dice que vienen las herramientas de servidor, de modo que la búsqueda web acabará integrada en el plano de control en lugar de ser una herramienta que conectas tú.

El lanzamiento cayó en la Birthday Week y claramente tocó una fibra. El hilo de Hacker News llegó a 590 puntos y 284 comentarios, más que el lanzamiento del navegador Kitesurf. El anuncio de Cloudflare en X recibió una respuesta que resume por qué le importa a la gente:

"search in the same gateway as the model calls is the nice part. wiring exa into my agent tonight"

Avery Coree, X

Cómo se mueve una solicitud

Antes de hablar de dinero, conviene ver las piezas móviles, porque cada decisión interesante está en una de ellas.

Puedes llamarla de dos maneras, ambas documentadas en la página de uso:

• REST: POST https://api.cloudflare.com/client/v4/accounts/{account_id}/ai/websearch/, autenticado con un token de API de Cloudflare que tenga los permisos Workers AI Read y AI Gateway Read.
• Binding de Workers: env.AI.websearch({ gatewayId, query, provider, limit }), que devuelve una Response estándar sobre la que llamas a .json().

La solicitud tiene muy pocos ajustes, lo que dice mucho del diseño:

No hay filtro de fecha, ni lista de dominios permitidos, ni parámetro de país, ni opción de "traer la página completa". Cada proveedor funciona en un modo fijo: Exa usa su tipo de búsqueda auto con fragmentos destacados como descripción, y Linkup usa profundidad fast con resultados en bruto, según la página de proveedores. Si necesitas los modos más profundos de Exa o Linkup, los llamas directamente.

La respuesta es deliberadamente delgada: un array items y un bloque metadata con tu consulta, un ID de solicitud y latencyMs. Esa delgadez es la clave. Encaja directamente en la ventana de contexto de un modelo sin que escribas un parser por proveedor, y la documentación de Cloudflare incluye un ejemplo completo de cómo conectarla como herramienta web_search para un modelo como Gemma 4 ejecutándose en Workers AI.

Por qué el parámetro de proveedor es la verdadera decisión de precio

Esta es la tabla que importa. Todas las cifras proceden de la página de proveedores de Cloudflare, consultada el 8 de octubre de 2026:

Exa cuesta 28 veces lo que cuesta Ceramic para la misma forma de solicitud, y cambiar de uno a otro es una sola cadena. Eso es estupendo para experimentar y peligroso para los presupuestos, porque nada en tu código cambia cuando alguien del equipo pasa ceramic a exa en un archivo de configuración. Un comentarista de HN que publicó la lista de precios hizo la pregunta correcta:

"Does anyone have insights on the quality differences? Web search API pricing for AI agent usecases has always felt so expensive for what it is, but I have no grounding on the economics of running a web index."

8bite, Hacker News

La publicación del lanzamiento de Cloudflare incluye una captura de un registro que hace muy concreto el coste por búsqueda: una sola llamada exa/search facturada a 0,007 USD, exactamente 7,00 USD por 1.000.

La frase "sin recargo", leída con atención

Cloudflare dice que las búsquedas se facturan "at each provider's list API price, with no additional markup." Eso es cierto por búsqueda. Pero los créditos de AI Gateway provienen de Unified Billing, y esa página indica que se aplica una comisión del 5 % a todos los créditos comprados: una recarga de 100 USD es un cargo de 105 USD. Así que si pagas con créditos, tu tarifa efectiva está un 5 % por encima de la lista. Si traes tu propia clave, el proveedor te factura directamente y la comisión de créditos no se aplica a esas búsquedas.

Así se ve con volúmenes reales, suponiendo una búsqueda por solicitud:

El 5 % es un error de redondeo al lado de la elección del proveedor. Con un millón de búsquedas al mes, elegir Exa en lugar de Ceramic es una decisión de 6.750 USD a precio de lista; la comisión de créditos encima es de 350 USD como máximo. Además, los agentes rara vez buscan una sola vez por tarea. Un bucle de investigación que lanza cinco búsquedas por pregunta de usuario convierte 200.000 preguntas en un millón de búsquedas, que es como una función "barata" acaba en una revisión de finanzas. Si quieres poner tus propios números, esta calculadora hace la multiplicación:

Qué normalizó Cloudflare y qué no

Este es el ángulo que creo que la mayoría de la cobertura pasa por alto. Cloudflare hizo que los tres proveedores parezcan idénticos a nivel de API. No son idénticos en lo que importa a un equipo de producto.

Una publicación en X lo dijo mejor de lo que yo puedo:

"The catch is that a unified endpoint also makes search providers look interchangeable when result quality, coverage, ranking, and failure modes probably won’t be."

Hero.S, X

Hay tres diferencias que conviene revisar antes de lanzar.

La retención de datos dice dos cosas distintas

La entrada del changelog dice "all three support Zero Data Retention for requests made through Cloudflare." La página de proveedores, actualizada el mismo día, indica Exa como "Zero Data Retention: No." Ambas páginas seguían diciendo eso cuando las revisé el 8 de octubre. Un lector de HN lo detectó en pocas horas y alguien de Exa respondió:

"Thanks for raising this! We're looking into this discrepancy (I work at Exa)."

alexey-salmin, Hacker News

Hasta que coincidan, yo planificaría como si la tabla de proveedores fuera la correcta. Si tus consultas contienen nombres de clientes, números de pedido o cualquier cosa de un ticket, eso hace de Ceramic o Linkup las opciones más seguras. Ten en cuenta también que el ajuste de ZDR de Unified Billing no controla el registro de AI Gateway; es un interruptor aparte.

Lo que puedes almacenar lo fijan los términos de cada proveedor

Cloudflare unificó el JSON. No unificó la licencia. Simon Willison planteó la pregunta que debería hacerse todo producto con un botón de "compartir este chat":

"My number one question about search APIs is always if they allow you to store and resyndicate results you get from them."

simonw, Hacker News

Después citó los términos de servicio de Ceramic, que te prohíben conservar, almacenar en caché o guardar la salida más allá de lo "reasonably necessary to display such Output to your authorized end users in the ordinary and real-time course of use." Si tu agente escribe resultados de búsqueda en una transcripción guardada, una base de conocimiento o una caché, lee los términos del proveedor que elijas. Exa y Linkup enlazan sus propios términos en la misma tabla de proveedores.

La calidad de los resultados no es un parámetro

El proveedor más barato es el valor por defecto, y la documentación presenta a Ceramic como creado para "low-latency, low-cost search." Los primeros probadores encontraron su índice irregular:

"Tried one query on ceramic.ai (the default provider for cloudflare web search api): "qwen-3.8 flash next and rtx 5090 best inference setup" ... 0 results ... same query on google and ddg both yield proper results."

freakynit, Hacker News

Una anécdota no es un benchmark, y el responsable del índice de Exa señaló, con razón, en el mismo hilo que la calidad de la búsqueda varía según el tipo de consulta. Pero es un recordatorio de que un conjunto de resultados vacío es un desenlace normal que tu agente tiene que gestionar, no un caso límite. Más abajo explico por qué importa.

Web Search API frente a otras formas de dar búsqueda a un agente

Cloudflare tiene ahora dos cosas llamadas "web search", lo que confundió a algunos lectores. La página de búsqueda web más antigua de AI Gateway, actualizada en junio, cubre el uso como proxy de la herramienta de búsqueda propia de cada proveedor de modelos. La nueva API es un producto aparte.

Si usas la API de Anthropic o la API de OpenAI y estás contento con su búsqueda integrada, las herramientas nativas dan menos trabajo de conexión. La Web Search API se justifica cuando ejecutas modelos abiertos, como Kimi K3 o los modelos detrás de DeepSeek Harness, que no tienen un socio de búsqueda propio. Un comentarista de HN lo adivinó justo así: los grandes agentes de programación vienen con socios de búsqueda y los modelos abiertos necesitan la búsqueda de algún sitio.

Muchos desarrolladores preguntaron "¿por qué no llamar directamente a los proveedores?" La respuesta honesta del hilo son las compras y los presupuestos, no la tecnología. Un comentarista describió cómo dio a un agente un único token de Cloudflare con límites de gasto en lugar de montar un proxy por servicio:

"Instead I put my API keys to cloudflare, set limits, and gave the agent the CloudFlare token, and in minutes it could contact tens of services."

bayesianbot, Hacker News

Eso encaja con lo que documenta Cloudflare: límites de gasto por gateway, acotados por modelo, proveedor o metadatos personalizados. Si tu equipo ya paga a Cloudflare, añadir búsqueda es una partida de presupuesto, no una revisión de un proveedor nuevo. Si no, una integración directa con Exa o con un scraper como Firecrawl puede ser igual de rápida. El panorama también se mueve bajo los pies de todos: la Custom Search JSON API de Google está cerrada a nuevos clientes, y los existentes tienen hasta el 1 de enero de 2027 para migrar.

Dónde encaja para un agente de soporte y dónde no

Mi sesgo, por adelantado. Llevo dos años trabajando en SEO, y lo primero que enseña es que la intención de búsqueda lo decide todo. Un cliente que pregunta "¿puedo devolver esto pasados 30 días?" no le pregunta a internet. Te lo pregunta a ti. La fuente correcta es tu política de devoluciones, no los 10 primeros resultados de "política de devolución a 30 días".

Eso importa por un fallo que he visto de cerca. He visto clientes de pago de eesel cuyo bot respondía a clientes reales con afirmaciones inventadas cuando la recuperación de la base de conocimiento salía vacía; una respuesta sacó "Oxygen" de la tabla periódica. La solución no fue más búsqueda. Fue un respaldo estricto: cuando tus propias fuentes no tienen nada, pasar a una persona en lugar de dejar que el modelo rellene el hueco de donde pueda. Una API de búsqueda web general agranda ese hueco, no lo reduce, porque ahora el modelo tiene todo internet desde el que equivocarse con seguridad. Los patrones están descritos en la guía de eesel sobre las alucinaciones de IA en soporte.

Así que para soporte ordenaría las fuentes así:

1. Tu centro de ayuda, macros y tickets anteriores. Esto es lo que debería significar la generación aumentada por recuperación para soporte.
2. Tu propio sitio web y la documentación del producto, limitados a tu dominio.
3. La web abierta, al final, para preguntas que tratan de verdad del mundo exterior: la caída de un servicio de un transportista, una normativa pública, el changelog de la integración de un tercero.

La Cloudflare Web Search API es una herramienta razonable para ese tercer grupo. No sustituye a los dos primeros, y Cloudflare no la presenta como tal.

Cómo encaja eesel junto a una API de búsqueda

La búsqueda web es infraestructura. eesel es el empleado. Cloudflare le da a tu agente una forma de consultar cosas; eesel te da un compañero listo para trabajar que ya sabe dónde están tus respuestas. El compañero de helpdesk con IA se incorpora a tu cola actual en herramientas como Zendesk, aprende de tu centro de ayuda y tickets anteriores, redacta o envía respuestas y escala cuando no tiene una respuesta fundamentada. El equipo actual incluye también un redactor de blog con IA para equipos de contenido.

Si eres de los equipos que leen changelogs de Cloudflare por diversión, probablemente te guste la CLI de eesel. Ejecuta el mismo compañero desde una terminal, y todo lo que configures allí aparece en el panel. Los comandos encajan bien con la idea de "primero tus fuentes":

• npx @eesel/cli init chat-bubble --site https://your-site.com crea un agente que empieza a leer tu propio sitio, sin cuenta para un espacio de prueba de 7 días.
• eesel integrations connect website --url ... o eesel integrations connect <platform> añade tu helpdesk o tus docs como conocimiento, y eesel files upload ./refund-policy.pdf añade una política concreta.
• eesel chat "what's our refund policy?" prueba la respuesta antes de que la vea un cliente.
• eesel approvals lista las acciones retenidas para una persona, de modo que una escritura que el agente quiere hacer espera a que alguien la apruebe.

Cada comando imprime JSON y cada error devuelve un hint, así que un agente de programación como Claude Code o Codex puede ejecutar toda la configuración y leer sus propios resultados. eesel mcp token también convierte el espacio de trabajo en un servidor MCP, que es como lo conectaría a un agente que ya usa Cloudflare para la búsqueda. Es el mismo patrón que traté en CLI para atención al cliente: una terminal, scripts y agentes manejando un mismo compañero.

Dónde eesel no es la opción adecuada: si estás construyendo un agente de investigación general que vive de datos públicos de la web, quieres una API de búsqueda como la de Cloudflare, no un compañero de helpdesk.

Mi veredicto sobre la Cloudflare Web Search API

Es un producto limpio, pequeño y honesto. Tres cosas que haría antes de depender de él:

• Fijar provider explícitamente, aunque quieras Ceramic. Un valor por defecto que no escribiste es un valor que alguien cambiará sin notar una diferencia de 28 veces en la factura.
• Tratar la columna de ZDR como no resuelta para Exa hasta que el changelog y la página de proveedores coincidan, y leer los términos de almacenamiento del proveedor que conserves.
• Gestionar a propósito los resultados vacíos. Devolver "no lo sé" o pasar a una persona, en lugar de dejar que el modelo improvise. Es el único hábito que evita que el grounding de IA se convierta en alucinación de IA.

Si ya construyes sobre Cloudflare, es la forma más fácil que he visto de darle búsqueda en vivo a un modelo abierto con una factura y un registro. Si evalúas búsqueda para un agente de cara al cliente, empieza con tu propio conocimiento y añade la web como último recurso. Para más sobre el stack de agentes de Cloudflare, consulta mis notas sobre los modelos de decisión de Clef y las alternativas a Kitesurf, o explora el campo más amplio de los motores de búsqueda con IA.

Prueba eesel para respuestas de soporte fundamentadas

Si miras una API de búsqueda web porque tu bot de soporte sigue respondiendo de la nada, la solución suele estar más cerca. El compañero de helpdesk con IA de eesel aprende de tu centro de ayuda, tus macros y tus tickets anteriores, y escala a tu equipo cuando no tiene nada fundamentado que decir. Puedes probarlo con tu propia base de conocimiento antes de que toque un ticket en vivo, y ver los planes en la página de precios. Prueba eesel gratis.