Precios y límites de DeepSeek Search API (guía 2026)

DeepSeek Search API cuesta $0.75 por cada 1.000 solicitudes exitosas, pero el precio no es lo único que determina si encaja en tu stack. Tanto Search como Fetch tienen una cuota documentada de 5 solicitudes por segundo por cuenta. Puede ser una opción muy interesante para agentes de bajo coste, siempre que controles las consultas repetidas, los reintentos, la cobertura de fuentes y el consumo de tokens del modelo.

Qué opción elegir según el caso

Qué ofrece realmente la API directa

DeepSeek documenta dos endpoints JSON de solo lectura. La autenticación es idéntica en ambos: envía Authorization: Bearer <DeepSeek API Key> y Content-Type: application/json a api.deepseek.com.

La API directa es independiente del producto de chat alojado. Tener una clave de API de DeepSeek no implica que una solicitud normal de Chat Completions navegue automáticamente por la web. Tu aplicación debe invocar Search o Fetch, o utilizar una integración de cliente documentada que aporte la capa de herramientas.

Search y Fetch: cuándo usar cada uno

Search acepta un query obligatorio de entre 1 y 128 caracteres Unicode. Entre los campos opcionales están count, de 1 a 50, ori_question, un valor de localization basado en IP y need_content. El valor predeterminado de count es 10, y el de need_content es false.

Al usar need_content: true, Search puede devolver el texto de la página en el campo content de cada resultado. Cuando ese contenido está disponible, puedes ahorrarte una llamada Fetch adicional. No obstante, no es una garantía: las páginas inaccesibles o bloqueadas también pueden devolver un campo de contenido vacío.

Fetch sirve para una URL que ya has seleccionado. Devuelve Markdown, pero se envía una URL por solicitud. DeepSeek indica que el fetch depende de la disponibilidad y las políticas de acceso del sitio de destino, así que un resultado exitoso de Search no garantiza que Fetch vaya a funcionar.

Los resultados de Search incluyen un rerank_score de 0 a 3 y un nivel de authority de -1 a 4. La documentación considera señales de alta calidad una puntuación de al menos 1.5 y una autoridad de al menos 3. Son metadatos del servicio, no benchmarks independientes sobre la calidad de la búsqueda.

La sintaxis de consulta admite filtros prácticos como site:, -site:, frases entre comillas, lang:, after: y before:. Por ejemplo:

"DeepSeek Search API" site:api-docs.deepseek.com lang:en after:2026-10-01

Un precio que condiciona la arquitectura

DeepSeek establece el precio de Search y Fetch en $0.75 por cada 1.000 solicitudes exitosas, es decir, $0.00075 por solicitud facturable. La facturación se basa en solicitudes, no en tokens ni en el número de resultados devueltos. Consulta la página oficial de precios.

La tarifa del endpoint no cubre todo el coste de una tarea de investigación con IA: los tokens de entrada y salida del modelo, así como los turnos extra del agente alrededor de la recuperación, se facturan por separado.

Una fórmula de costes realista

En un flujo sencillo, la parte de recuperación se calcula así:

llamadas exitosas a Search * $0.00075
+ llamadas exitosas a Fetch * $0.00075
+ cargos de tokens de entrada y salida del modelo

Un lote de 10.000 búsquedas cuesta $7.50 si todas las solicitudes de Search generan resultados. Si la aplicación recupera una página por cada resultado, otras 10.000 llamadas exitosas a Fetch suman $7.50, antes de contar los tokens del modelo. Pedir 50 resultados a Search no multiplica el coste por solicitud, pero sí puede aumentar la cantidad de texto que debe procesar el modelo.

Por eso conviene definir una política explícita para need_content. Úsalo con conjuntos pequeños de páginas; si antes necesitas filtrar por puntuación, dominio, fecha o autoridad, opta por Search solo con metadatos y realiza Fetch de forma selectiva.

@haolv511482 señaló: “Comprueba el campo content antes de añadir un bucle de fetch. Search puede devolver texto de la página con need_content=true ... De lo contrario, tu agente podría pagar por leer dos veces la misma página.” Fuente

Límites y fallos que debes contemplar

La guía oficial documenta un máximo de 50 resultados por solicitud de Search y cuotas independientes de 5 solicitudes por segundo por cuenta para Search y Fetch. Incluso en un despliegue con varios workers, necesitas limitadores específicos para cada endpoint.

Fetch es especialmente sensible al comportamiento de cada sitio. La documentación oficial limita su garantía a la disponibilidad y las políticas de acceso del sitio de destino; no promete ejecución de JavaScript, sesión de navegador, selector de user-agent, capturas de pantalla ni conservación del HTML original. En una prueba temprana, @jiangkoumo_ indicó que los sitios con renderizado intensivo mediante JavaScript podían devolver 404, mientras que una página pública convencional se convertía a Markdown. Fuente

Las mismas pruebas iniciales también revelaron un compromiso importante en cobertura. @bei351009016 informó de solo un 2.1% de solapamiento con Exa en 29 consultas y 12 plataformas, y describió a DeepSeek como rápido y actualizado para fuentes chinas, pero débil en WeChat y YouTube. Fuente

Toma esta prueba inicial como una indicación, no como una conclusión definitiva, y valida los tipos de fuentes que necesitas.

Patrón mínimo de implementación

Este ejemplo separa la recuperación de la generación de respuestas, evita llamar a Fetch cuando Search ya devolvió contenido y espacia las llamadas a 5 por segundo para este proceso. En un despliegue con varios workers, seguirá haciendo falta un único limitador compartido.

import os
import threading
import time
import requests

BASE = "https://api.deepseek.com"
HEADERS = {
    "Authorization": f"Bearer {os.environ['DEEPSEEK_API_KEY']}",
    "Content-Type": "application/json",
}
RATE_LOCK = threading.Lock()
LAST_CALL = 0.0


def post_json(path, payload, attempts=3):
    global LAST_CALL
    for attempt in range(attempts):
        with RATE_LOCK:
            wait = 0.2 - (time.monotonic() - LAST_CALL)
            if wait > 0:
                time.sleep(wait)
            LAST_CALL = time.monotonic()
        response = requests.post(
            BASE + path, headers=HEADERS, json=payload, timeout=30
        )
        if response.status_code in {408, 429, 500, 502, 503, 504}:
            if attempt == attempts - 1:
                response.raise_for_status()
            time.sleep(2 ** attempt)
            continue
        response.raise_for_status()
        return response.json()


search = post_json(
    "/v1/tools/search",
    {
        "query": 'DeepSeek Search API pricing site:api-docs.deepseek.com',
        "count": 10,
        "need_content": True,
    },
)

usable = [
    result for result in search.get("results", [])
    if result.get("rerank_score", 0) >= 1.5
]

for result in usable:
    content = result.get("content") or ""
    if not content:
        fetched = post_json("/v1/tools/fetch", {"url": result["url"]})
        content = fetched.get("content", "")
    # Store title, URL, date, authority, score, and content before summarizing.
    print(result["title"], result["url"], len(content))

Cuándo DeepSeek no basta como proveedor único

DeepSeek es una buena elección para descubrimiento de bajo coste, especialmente si tu corpus incluye fuentes chinas y tu aplicación puede trabajar con un límite de 5 QPS por cuenta. Como proveedor único resulta menos adecuado cuando la carga de trabajo depende de YouTube, WeChat, páginas con fuerte renderizado en cliente o el ranking de un motor de búsqueda concreto.

Un diseño híbrido es más sólido:

1. Envía las consultas amplias y económicas de descubrimiento a DeepSeek.
2. Filtra por dominio, fecha, autoridad y puntuación de reranking.
3. Recurre a un segundo proveedor para las clases de fuentes que DeepSeek no cubre.
4. Haz Fetch solo de las URL seleccionadas.
5. Contrasta el respaldo de las respuestas con el texto de las fuentes almacenado.

El tratamiento de datos es otra decisión de despliegue. Revisa los términos vigentes de DeepSeek y tus requisitos de cumplimiento antes de enviar consultas sensibles; las inquietudes de la comunidad no demuestran una política concreta de retención. Fuente

Checklist operativo antes de pasar a producción

1. Registra por separado las llamadas a Search y Fetch para poder conciliar la factura.
2. Comprueba content antes de hacer Fetch de una URL devuelta por Search.
3. Aplica un limitador compartido de 5 QPS a todos los workers y subagentes.
4. Reintenta solo las respuestas 408, 429 y 5xx transitorias.
5. Guarda la URL, el título, la fecha, la autoridad, la puntuación de reranking y el momento de recuperación.
6. Rechaza esquemas no compatibles y URL de redes privadas en cualquier ruta Fetch controlada por el usuario.
7. Trata el texto de las páginas como datos no confiables, no como instrucciones para herramientas.
8. Ejecuta un conjunto de pruebas que incluya páginas oficiales en inglés, fuentes chinas, foros, páginas de vídeo y sitios con mucho JavaScript.
9. Mide el coste total de la tarea, incluidos los tokens del modelo y los reintentos, en lugar de informar solo del precio de Search.

Preguntas frecuentes sobre DeepSeek Search API

¿La API está disponible automáticamente mediante llamadas compatibles con OpenAI?

El endpoint directo de Search es una ruta independiente: POST /v1/tools/search. Una solicitud normal al modelo no navega por la web solo porque el cliente utilice una URL base compatible con OpenAI. Añade tú mismo las llamadas a Search y Fetch, o utiliza una integración de cliente documentada por DeepSeek.

¿DeepSeek Search es el mejor sustituto de cualquier proveedor de búsqueda?

No. Es una opción de recuperación atractiva por su bajo coste, pero las primeras pruebas de usuarios detectaron una cobertura distinta a la de Exa y carencias en torno a YouTube y WeChat. Haz una prueba pequeña y adaptada a tu carga de trabajo antes de convertirlo en tu único proveedor.