Preços e limites da DeepSeek Search API (guia de 2026)

A DeepSeek Search API custa US$ 0,75 a cada 1.000 requisições bem-sucedidas. O preço é baixo, mas não é o único fator da decisão: Search e Fetch têm cotas independentes de 5 requisições por segundo por conta. Ela pode ser uma boa base para agentes econômicos, desde que sua aplicação controle buscas e fetches duplicados, tentativas de novo, cobertura de fontes e o uso de tokens do modelo.

Qual opção faz sentido em cada cenário

O que a API bruta oferece

A DeepSeek documenta dois endpoints JSON somente de leitura. A autenticação é igual nos dois: envie Authorization: Bearer <DeepSeek API Key> e Content-Type: application/json para api.deepseek.com.

A API bruta é separada do produto de chat hospedado. Ter uma chave da API da DeepSeek não faz com que uma requisição comum de Chat Completions navegue automaticamente na web. Sua aplicação precisa chamar Search ou Fetch, ou usar uma integração de cliente documentada que forneça a camada de ferramentas.

Quando usar Search e quando usar Fetch

Search recebe o campo obrigatório query, com 1 a 128 caracteres Unicode. Os campos opcionais incluem count, de 1 a 50, ori_question, um valor de localization baseado em IP e need_content. O padrão para count é 10, e need_content vem como false.

Com need_content: true, o Search pode devolver o texto da página no campo content de cada resultado. Quando o conteúdo estiver disponível, isso pode eliminar uma chamada Fetch separada. Mas não há garantia: páginas indisponíveis ou bloqueadas ainda podem retornar o campo de conteúdo vazio.

O Fetch serve para uma URL que você já escolheu. Ele retorna Markdown, mas envia uma URL por requisição. A DeepSeek informa que o fetch está sujeito à disponibilidade e às políticas de acesso do site de destino; portanto, um resultado bem-sucedido no Search não assegura um Fetch bem-sucedido.

Os resultados do Search trazem um rerank_score de 0 a 3 e um nível de authority de -1 a 4. A documentação classifica scores de pelo menos 1,5 e valores de autoridade de pelo menos 3 como sinais de alta qualidade. São metadados do serviço, não benchmarks independentes de qualidade da busca.

A sintaxe de consulta oferece filtros úteis como site:, -site:, frases entre aspas, lang:, after: e before:. Por exemplo:

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

Uma precificação que afeta a arquitetura

A DeepSeek cobra tanto pelo Search quanto pelo Fetch US$ 0,75 por 1.000 requisições bem-sucedidas, ou US$ 0,00075 por requisição faturável. A cobrança é por requisição, não por token nem pela quantidade de resultados retornados. Consulte a página oficial de preços.

A taxa do endpoint não representa o custo total de uma tarefa de pesquisa com IA: tokens de entrada e saída do modelo, além das chamadas extras do agente durante a recuperação, são cobrados à parte.

Uma fórmula de custo mais realista

Em um fluxo simples, a parcela de recuperação é:

chamadas Search bem-sucedidas * $0.00075
+ chamadas Fetch bem-sucedidas * $0.00075
+ cobranças de tokens de entrada e saída do modelo

Um lote de 10.000 buscas custa US$ 7,50 quando todas as requisições de Search geram resultados. Se a aplicação buscar uma página para cada resultado, outras 10.000 chamadas Fetch bem-sucedidas acrescentam US$ 7,50, antes dos tokens do modelo. Pedir 50 resultados ao Search não multiplica o valor da requisição, mas pode aumentar o volume de texto que o modelo precisará processar.

Por isso, need_content merece uma política explícita. Use-o para conjuntos pequenos de páginas; prefira Search apenas com metadados e Fetch seletivo quando precisar filtrar primeiro por score, domínio, data ou autoridade.

@haolv511482 relatou: “Verifique o campo content antes de adicionar um loop de fetch. O Search pode devolver o texto da página com need_content=true ... Caso contrário, seu agente pode pagar para ler a mesma página duas vezes.” Fonte

Limites e falhas que a aplicação precisa prever

O guia oficial documenta um máximo de 50 resultados por requisição de Search e cotas independentes de 5 requisições por segundo por conta para Search e Fetch. Uma implantação com vários workers ainda precisa de limitadores específicos para cada endpoint.

O Fetch é especialmente sensível ao comportamento dos sites. A documentação oficial limita sua garantia à disponibilidade e às políticas de acesso do site de destino; ela não promete execução de JavaScript, sessão de navegador, seleção de user-agent, capturas de tela ou preservação do HTML bruto. Em um teste inicial, @jiangkoumo_ relatou que sites fortemente renderizados por JavaScript podiam retornar 404, enquanto uma página pública comum era convertida em Markdown. Fonte

Os mesmos testes iniciais também apontaram uma troca importante em cobertura. @bei351009016 relatou apenas 2,1% de sobreposição com a Exa em 29 consultas e 12 plataformas, descrevendo a DeepSeek como rápida e atualizada para fontes chinesas, mas fraca para WeChat e YouTube. Fonte

Trate esse teste inicial como indicativo e valide os tipos de fonte de que você precisa.

Padrão mínimo de implementação

Este exemplo separa a recuperação da geração de respostas, evita uma chamada Fetch quando o Search já retornou conteúdo e espaça as chamadas em 5 por segundo neste processo. Em uma implantação com vários workers, ainda será necessário um limitador compartilhado.

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", "")
    # Armazene título, URL, data, autoridade, score e conteúdo antes de resumir.
    print(result["title"], result["url"], len(content))

Quando a DeepSeek não deve ser seu único provedor

A DeepSeek é uma escolha forte para descoberta a baixo custo, especialmente quando seu corpus inclui fontes chinesas e sua aplicação pode trabalhar com o limite de 5 QPS por conta. Ela é uma opção mais fraca como provedor único se a carga de trabalho depender de YouTube, WeChat, páginas pesadamente renderizadas no cliente ou do ranking de um mecanismo de busca específico.

Um desenho híbrido é mais defensável:

1. Envie consultas amplas e baratas de descoberta para a DeepSeek.
2. Filtre por domínio, data, autoridade e score de reranking.
3. Use um segundo provedor para classes de fontes que a DeepSeek não cobre.
4. Faça Fetch apenas das URLs selecionadas.
5. Compare o suporte à resposta com o texto das fontes armazenadas.

O tratamento dos dados é outra decisão de implantação. Analise os termos atuais da DeepSeek e suas exigências de conformidade antes de enviar consultas sensíveis; preocupações da comunidade não comprovam uma política específica de retenção. Fonte

Checklist operacional antes de ir para produção

1. Registre chamadas de Search e Fetch separadamente para conseguir conciliar a cobrança.
2. Verifique content antes de fazer Fetch de uma URL retornada pelo Search.
3. Aplique um limitador compartilhado de 5 QPS entre todos os workers e subagentes.
4. Tente novamente apenas respostas 408, 429 e 5xx transitórias.
5. Armazene URL, título, data, autoridade, score de reranking e horário da recuperação.
6. Rejeite esquemas não suportados e URLs de redes privadas em qualquer fluxo de Fetch controlado pelo usuário.
7. Trate o texto das páginas como dado não confiável, não como instruções para ferramentas.
8. Execute um conjunto de testes com páginas oficiais em inglês, fontes chinesas, fóruns, páginas de vídeo e sites pesados em JavaScript.
9. Meça o custo total da tarefa, incluindo tokens do modelo e tentativas de novo, em vez de informar apenas o preço do Search.

Perguntas frequentes sobre a DeepSeek Search API

A API fica disponível automaticamente em chamadas compatíveis com OpenAI?

Não. O endpoint bruto de Search é uma rota separada, POST /v1/tools/search. Uma requisição comum ao modelo não navega só porque o cliente usa uma URL base compatível com OpenAI. Adicione as chamadas Search/Fetch você mesmo ou use uma integração de cliente documentada pela DeepSeek.

DeepSeek Search é a melhor substituta para qualquer provedor de busca?

Não. É uma opção atraente de recuperação a baixo custo, mas testes iniciais de usuários encontraram cobertura diferente da Exa e lacunas em torno de YouTube e WeChat. Antes de torná-la seu único provedor, faça um teste pequeno e específico para sua carga de trabalho.