El periodo gratuito de las llamadas a Search y Fetch realizadas mediante herramientas del servidor de DeepSeek terminó, según el calendario del proveedor, el 31 de octubre de 2026 a las 16:00 UTC: las 17:00 en Madrid. La documentación expresa también ese instante como el 1 de noviembre a las 00:00 en Pekín. No son dos cambios distintos ni un lanzamiento de hoy: DeepSeek anunció estas API el 17 de octubre.
La consecuencia para quien integra búsquedas en un agente es separar dos consumos: las solicitudes de recuperación y los tokens del modelo. El anuncio original incluye las herramientas del servidor utilizadas a través de la API de DeepSeek desde DeepSeek Harness, Claude Code y Codex. Esto no significa que cualquier usuario de esas aplicaciones pase a pagar a DeepSeek: importa qué proveedor y qué herramientas utiliza la integración.
Qué se factura y qué queda fuera
Según la guía de Search y Fetch, cada servicio cuesta 0,75 USD por cada 1.000 solicitudes exitosas. Search busca páginas; Fetch recupera el contenido de una URL como texto Markdown. Son API independientes, con rutas /v1/tools/search y /v1/tools/fetch.
Para facturar no basta con recibir HTTP 200: Search debe devolver una lista de resultados no vacía y Fetch debe producir contenido de la página. Los fallos, las búsquedas sin resultados y los tiempos de espera agotados no se cobran. El parámetro count, que admite de 1 a 50 resultados, cambia cuántos se devuelven, pero no el precio por solicitud.
La tabla de precios mantiene aparte el consumo de tokens. Pedir contenido con need_content puede aportar texto para el agente; no convierte la tarifa de recuperación en una tarifa que incluya toda la inferencia posterior. El valor predeterminado es false; el campo content queda vacío cuando no se pide contenido o este no está disponible.
Un cálculo para dimensionar el cambio
Ejemplo hipotético, sin llamadas a la API ni facturación comprobada por Puntoes: 100 preguntas que provocan una búsqueda y tres recuperaciones exitosas cada una producirían 100 solicitudes Search y 300 Fetch.
El cálculo de recuperación sería (100 + 300) × 0,75 / 1.000 = 0,30 USD. Esa cifra excluye los tokens del modelo, impuestos, conversión de moneda y otros servicios. No es el coste total de resolver las preguntas ni demuestra ahorro frente a otra solución. Un agente que vuelve a buscar o recupera más páginas cambia el número de solicitudes aunque atienda las mismas 100 preguntas.
Nuestra recomendación es registrar ambos contadores junto con el consumo del modelo. Así puede distinguirse si un aumento de gasto procede de respuestas más largas, de más recuperación o de reintentos exitosos adicionales.
Límites que conviene incorporar al agente
Los límites documentados son 100 solicitudes por segundo para Search y 25 para Fetch, independientes y por cuenta, no por clave. Fetch tiene además un límite por dominio. Repartir el tráfico entre claves de una misma cuenta no amplía esos límites.
La guía recomienda esperar y reintentar ante HTTP 408, 429 o errores 5xx. Un 402 indica saldo insuficiente; repetirlo sin resolver el saldo no arregla el problema. Para otros errores 4xx pide cambiar la solicitud antes de reintentar.
Fetch depende de la disponibilidad y las políticas de acceso del sitio de destino. Obtener contenido tampoco demuestra que sea verdadero: nuestra recomendación editorial es contrastar las afirmaciones y tratar el texto recuperado como datos, sin concederle autoridad para cambiar las instrucciones del agente.
Este cambio afecta al servicio alojado. Es una cuestión distinta de operar un motor propio, como explicamos en DeepInfer y las piezas necesarias para construir un servicio. No hemos ejecutado pruebas de rendimiento ni verificado cargos en una cuenta; describimos las condiciones oficiales consultadas el 1 de noviembre. La novedad ya figuraba brevemente en el resumen del 31 de octubre.