Web Search API y Web Fetch API: cómo funcionan y qué dan por $0.01

Las principales herramientas de búsqueda web del lado del servidor cobran lo mismo: $0.01 por búsqueda. Ese importe es lo menos relevante de la factura. En nuestras mediciones, cada solicitud recibió entre 1,500 y 3,100 tokens de resultados, facturados según la tarifa del modelo elegido. El comportamiento del turno siguiente depende de una diferencia de diseño que pocos equipos revisan: si el endpoint conserva las fuentes de la búsqueda o las descarta sin avisar, obligando al modelo a buscar de nuevo y cobrando otra vez. Medimos synthorai:web_search y synthorai:web_fetch de Synthorai con cuatro familias de modelos y comparamos los resultados con los precios publicados por Anthropic y OpenAI para sus propias búsquedas alojadas.

TL;DR

• Synthorai, Anthropic y OpenAI cobran $0.01 por búsqueda; en los registros de facturación aparece desglosado como $0.0100.
• Una búsqueda añade entre 1,500 y 3,100 tokens de resultados a la tarifa de entrada del modelo: en modelos baratos predomina la tarifa fija; en los premium, los tokens pueden representar hasta la mitad.
• max_uses es un límite, no una cuota: aunque permitimos 10, el modelo se detuvo en 3; el coste depende de las búsquedas ejecutadas.
• El segundo turno cambia según el endpoint: /v1/messages reproduce los resultados (≈3,900 tokens, sin otra tarifa); /v1/chat/completions los descarta, por lo que un seguimiento que necesite las fuentes hará una búsqueda nueva.

¿Por qué necesitan los modelos búsqueda web y obtención de páginas?

Porque el conocimiento de un modelo termina en la fecha de corte de su entrenamiento, mientras que la mayoría de las preguntas de producción no. Precios, notas de versiones, tipos de cambio, resultados deportivos o el contenido de la URL que acaba de pegar un usuario no están en los pesos. Responder con seguridad de todos modos es la forma de acabar mostrando a los usuarios datos «actuales» inventados. La búsqueda web cubre el descubrimiento, cuando el modelo no sabe dónde está la respuesta. La obtención de páginas cubre la lectura, cuando conoce la URL exacta y necesita su contenido. Se pueden implementar ambas con una API de búsqueda, un scraper y un bucle de llamadas a herramientas, y muchos equipos lo hacen. Las versiones del lado del servidor existen porque ese bucle es infraestructura genérica. Ejecutarlo dentro del proveedor elimina viajes de ida y vuelta, código de parsing y carga operativa, por una tarifa que resulta ser idéntica en todos ellos.

¿Cómo funciona realmente la búsqueda web del lado del servidor?

Todo el bucle se ejecuta dentro de una sola solicitud a la API. Con herramientas del lado del cliente, el modelo pide a tu código que busque, tu código devuelve los resultados y cada salto vuelve a enviar la conversación. Una herramienta de servidor elimina ese intermediario: declaras {"type": "synthorai:web_search"} en tools, el modelo genera una consulta, el gateway la envía a un proveedor de búsqueda especializado, incorpora los resultados al contexto del modelo y este los lee para responder o vuelve a buscar, hasta alcanzar max_uses. Entra una solicitud y sale una respuesta, con citas y factura incluidas.

Solo hace falta una línea en una solicitud normal, sin código para el bucle ni callbacks:

curl https://synthorai.io/v1/chat/completions \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash-0731",
    "messages": [{"role": "user", "content": "What is one AI news headline from this week? Name the source."}],
    "tools": [{"type": "synthorai:web_search", "max_uses": 1}]
  }'

La obtención de páginas se declara igual, pero con otro tipo. Incluye la URL en el mensaje y el gateway recuperará la página:

"messages": [{"role": "user", "content": "Fetch https://example.com/pricing and summarize the tiers."}],
"tools": [{"type": "synthorai:web_fetch", "max_uses": 1}]

El diagrama reproduce exactamente la solicitud de búsqueda anterior, medida con deepseek-v4-flash-0731. El medidor registró 2,059 tokens de entrada, una pregunta de 30 tokens más unos 2,000 tokens de resultados añadidos, 169 tokens de salida y un total de $0.0104: $0.01 por la búsqueda y alrededor de $0.0004 por los tokens. Solo hay dos cargos: la tarifa cuando se ejecuta la búsqueda y los tokens de resultados a la tarifa de entrada habitual del modelo. Una obtención de página se factura igual, sustituyendo los snippets por el contenido recuperado.

Declarar la herramienta no cuesta nada: si una solicitud la declara pero no busca, no se cobra ninguna tarifa. Además, funciona con cualquier modelo del catálogo. Esa es la diferencia estructural frente a las alternativas propias de cada proveedor: la búsqueda alojada de Anthropic funciona con modelos Claude, la de OpenAI con modelos OpenAI y una herramienta del gateway con cualquier modelo al que dirijas la solicitud.

¿Cuánto cuesta realmente una búsqueda?

$0.01 de tarifa fija más los tokens, cuya importancia aumenta a medida que sube el precio del modelo. Ejecutamos tres veces la misma pregunta de noticias con una sola búsqueda en cuatro familias. Calculamos las tarifas exactas de tokens de cada modelo a partir de baselines sin herramientas y obtuvimos la tarifa fija como residuo:

En el modelo más barato, la tarifa de búsqueda supone el 97% de la llamada. En modelos premium, los tokens añadidos consumen la mitad de la factura. La tarifa fija no es una deducción: nuestros registros de facturación muestran el cargo de la herramienta como una línea independiente de exactamente $0.0100 por llamada, junto con otro recuento de los tokens añadidos por la herramienta. En una llamada real de obtención de página, fueron 3,454 de los 3,836 tokens de entrada. El coste total medido de una sola búsqueda quedó entre $0.010 y $0.012, según el modelo. Si presupuestas el extremo superior del intervalo, evitarás sorpresas. En la práctica, combinar una búsqueda del lado del servidor con un modelo barato hace que casi todo el coste corresponda a la búsqueda y que el modelo salga prácticamente gratis.

¿Qué tres variables determinan la factura de tokens?

El número de búsquedas, la longitud de los resultados y el tamaño de la página. El resto apenas afecta al redondeo. Las tres se pueden medir directamente y dos de ellas están bajo tu control.

Primera variable: cuántas búsquedas se ejecutan. max_uses marca un máximo, no un objetivo. En una pregunta sobre los precios de cinco proveedores, permitir 1, 2 y 3 búsquedas produjo facturas de $0.0106, $0.0216 y $0.0319. Las tarifas crecieron linealmente a razón de $0.01 por cada búsqueda ejecutada. Permitir 5 o incluso 10 no cambió nada, porque el modelo se detuvo por sí solo después de tres. El margen sin usar es gratuito, igual que los presupuestos de razonamiento que medimos en modelos de reasoning. El valor predeterminado es 3 y el límite absoluto, 10. Por tanto, en una pregunta propensa a generar búsquedas, el peor caso sin configuración son tres tarifas más tres cargas de resultados. Usa max_uses: 1 en rutas que solo necesitan un dato.

Segunda variable: cuánto ocupan los resultados. El volumen incorporado depende de la amplitud de la pregunta, no del azar. En doce ejecuciones con una sola búsqueda usando deepseek-v4-flash-0731:

Las preguntas concretas recuperan conjuntos de resultados compactos. Las comparativas recuperan conjuntos más amplios, alrededor de un 45% más pesados que los de un solo dato. Para presupuestar, 2,000 tokens por búsqueda con un margen del 20% cubre todo lo observado. Con las tarifas habituales de los modelos, la parte de tokens de una búsqueda cuesta entre una vigésima parte y la mitad de la tarifa de $0.01.

Tercera variable: cuánto pesa la página obtenida. La tarifa de obtención no cambia; el resto depende de la página. Esta fue nuestra escala, siempre con el mismo modelo:

Con un modelo barato, incluso el artículo de Wikipedia cuesta alrededor de un centavo y medio. Si diriges la misma obtención a un modelo de $2 por millón, esa única página cuesta seis centavos y medio, cinco veces la tarifa. Hay otro dato útil para el presupuesto: una misma página se tokeniza de forma distinta según la familia del modelo. La publicación con muchos datos ocupó 5,196 tokens en DeepSeek y 5,508 en qwen3.8-max, un sobrecoste de tokenizer del 6% coherente con nuestras mediciones de densidad.

¿Qué ocurre con los resultados de búsqueda en el turno siguiente?

Los dos protocolos de API difieren en su diseño, y eso determina el coste del seguimiento. El protocolo /v1/messages representa cada turno del asistente como una lista de bloques de contenido. La actividad de las herramientas del servidor forma parte del registro oficial del turno: la respuesta contiene server_tool_use, web_search_tool_result y después el texto. El protocolo espera recibir de nuevo esos bloques en el turno siguiente. Por diseño, las fuentes se arrastran como tokens de entrada. El protocolo /v1/chat/completions, en cambio, representa el mensaje del asistente como una sola cadena de contenido y no tiene ningún espacio para resultados de herramientas del servidor. Los resultados añadidos se absorben en el servidor. Solo la respuesta visible pasa al historial, por lo que las fuentes se pierden.

Ejecutamos el mismo par de búsqueda y seguimiento con claude-sonnet-5 mediante ambas interfaces. Con /v1/messages, el seguimiento facturó 3,911 tokens de entrada y $0.0109, todo en tokens. No hubo una búsqueda nueva porque el modelo seguía teniendo los resultados disponibles. Con /v1/chat/completions, el seguimiento facturó $0.0204, más que la reproducción. Como el modelo solo conservaba su propio resumen de una línea, ejecutó otra búsqueda: una nueva tarifa de $0.01 más otra carga de resultados. Repetir la búsqueda es una decisión, no una obligación. En una ejecución anterior del mismo seguimiento con absorción usando deepseek-v4-flash-0731, el modelo respondió directamente desde su resumen, con 460 tokens de entrada y un coste de $0.00009. Con la absorción, el coste del seguimiento tiene dos posibilidades: casi nada si basta con el resumen, o tarifa más carga si el modelo decide volver a consultar la web.

Por tanto, no se puede afirmar sin más que un endpoint sea más barato. Cada uno desplaza el coste a un lugar distinto. El estilo por bloques paga un coste predecible en tokens en cada turno y nunca vuelve a comprar fuentes que ya tiene. El estilo con absorción apuesta por que los seguimientos no necesitarán las fuentes y paga otra tarifa cuando esa apuesta falla. Los chats largos con seguimientos sencillos encajan con /v1/chat/completions. Los agentes de investigación que consultan repetidamente las fuentes encajan con /v1/messages, donde la disciplina por capas de prompt cache se aplica a los resultados arrastrados como a cualquier otro contexto voluminoso.

¿Cuánto cobran Anthropic y OpenAI, y dónde funcionan sus herramientas?

La comparación es sencilla: todos cobran $0.01 por búsqueda. El resto de la factura depende del precio de tokens del modelo. Anthropic cobra $10 por 1,000 búsquedas y factura los resultados como tokens de entrada; su obtención de páginas no tiene tarifa fija, solo se cobran los tokens. OpenAI cobra los mismos $10 por 1,000 llamadas, aunque el tratamiento de los tokens cambia según el nivel del modelo. La tarifa ya está igualada. La variable es la tarifa de entrada del modelo aplicada a los 1,500-3,100 tokens añadidos.

La diferencia real entre los tres no aparece en la tabla de precios, sino en el lugar donde funcionan las herramientas. Las herramientas propias de cada proveedor están diseñadas para sus stacks de agentes y se limitan a sus interfaces. La documentación de Anthropic indica que la búsqueda web no está disponible en Amazon Bedrock, que Google Cloud solo admite la búsqueda básica y que Microsoft Foundry requiere un despliegue alojado en Anthropic. La obtención de páginas no está disponible ni en Bedrock ni en Google Cloud. La búsqueda de OpenAI está vinculada a su Responses API. Si trasladas la carga a otro cloud o cambias de familia de modelos, la herramienta del proveedor no te acompaña. Por eso un gateway tampoco reenvía esas herramientas: no pueden seguir el tráfico. Una herramienta del gateway asume el compromiso opuesto: una sola declaración que sigue funcionando al cambiar de modelo o plataforma.

Preguntas frecuentes

¿Cuánto cuesta la API de búsqueda web por solicitud?

$0.01 por cada búsqueda ejecutada, desglosado como una línea propia en los registros de facturación, más los resultados añadidos como tokens de entrada a la tarifa del modelo. En nuestras pruebas fueron entre 1,500 y 3,100 tokens por búsqueda. Una solicitud que declara la herramienta pero no busca no paga ninguna tarifa. Presupuesta entre $0.010 y $0.012 en total por búsqueda con modelos habituales. En modelos muy baratos, la tarifa supone el 97% del total.

¿Se vuelven a facturar los resultados de búsqueda en turnos posteriores?

Depende del endpoint. Con /v1/messages, los bloques de resultados se reproducen junto con el historial, unos 3,900 tokens de entrada por turno en nuestras pruebas, sin añadir otra tarifa. Con /v1/chat/completions, los resultados se absorben tras el turno. El seguimiento cuesta casi nada si el modelo responde desde su resumen, $0.00009 en una ejecución, pero genera otra tarifa y otra carga de resultados si vuelve a buscar, $0.0204 en otra. La búsqueda propia de Anthropic documenta la reproducción como comportamiento estándar; allí, los resultados se vuelven a facturar en cada turno.

¿Cómo limito el gasto de búsqueda web por solicitud?

Con max_uses. Es un límite estricto que el modelo no puede superar, con un valor predeterminado de 3 y un máximo de 10. Las tarifas solo aumentan con las búsquedas realmente ejecutadas; el margen sin usar es gratuito. Para rutas que buscan un único dato, max_uses: 1 limita el peor caso a una tarifa más una carga de resultados.

¿Cuándo conviene obtener una página en lugar de buscar en la web?

Usa la obtención cuando ya conozcas la URL y necesites la página completa. Usa la búsqueda cuando necesites localizar la fuente. Ambas cuestan $0.01 por uso a través del gateway, pero una obtención incorpora la página entera, desde 209 tokens para una página mínima hasta 27,380 para un artículo largo en nuestra escala. Una búsqueda incorpora snippets de varias fuentes. En pipelines de lectura y resumen que usen específicamente modelos Claude, la herramienta de obtención propia de Anthropic no tiene tarifa fija y resulta más barata.

Mediciones realizadas el 2026-08-10 a través del gateway de Synthorai con synthorai:web_search y synthorai:web_fetch en deepseek-v4-flash-0731, gpt-5.6-luna, qwen3.8-max y claude-sonnet-5: tarifas de tokens por modelo calculadas a partir de baselines de dos puntos sin herramientas; tarifas de búsqueda obtenidas como residuo entre el coste facturado y el valor de los tokens (n=3 por modelo); escala de max_uses; barrido de carga de resultados por tipo de consulta (4 tipos x 3 ejecuciones); pruebas del turno de seguimiento en ambos endpoints con preguntas idénticas; y escala de obtención de cinco páginas, tres propias, una página externa mínima y un artículo largo. Las tarifas se confirmaron mediante registros de facturación desglosados, con líneas por cargo de herramienta y tokens añadidos por la herramienta en cada llamada, no solo a partir de los totales. Las cifras de Anthropic y OpenAI proceden de las tarifas publicadas en su documentación al publicar este artículo. Los números del diagrama corresponden a una llamada medida sin modificar. Las tarifas y el comportamiento pueden cambiar; compruébalos en tus propios registros de uso.

← Volver al blog