Prezzi e limiti della DeepSeek Search API (guida 2026)

Con $0.75 ogni 1.000 richieste riuscite, la DeepSeek Search API è una soluzione economica per gli agenti che devono cercare sul web. Il vero punto non è però solo il prezzo: Search e Fetch hanno entrambi un limite documentato di 5 richieste al secondo per account. Per usarla bene bisogna quindi tenere sotto controllo fetch duplicati, retry, copertura delle fonti e token consumati dal modello.

In sintesi: quale opzione scegliere

Cosa offre davvero l'API diretta

DeepSeek documenta due endpoint JSON in sola lettura. L'autenticazione è identica per entrambi: invia Authorization: Bearer <DeepSeek API Key> e Content-Type: application/json a api.deepseek.com.

L'API diretta è distinta dal prodotto chat ospitato. Avere una chiave API DeepSeek non significa che una normale richiesta Chat Completions navighi automaticamente sul web. L'applicazione deve chiamare Search o Fetch, oppure usare un'integrazione client documentata che fornisca il layer degli strumenti.

Quando usare Search e quando Fetch

Search richiede il campo query, lungo da 1 a 128 caratteri Unicode. Tra i campi facoltativi figurano count, da 1 a 50, ori_question, il valore localization basato sull'IP e need_content. Per impostazione predefinita, count vale 10 e need_content è false.

Con need_content: true, Search può includere il testo della pagina nel campo content di ogni risultato. Quando il contenuto è disponibile, questo può evitare una chiamata Fetch separata. Non è però garantito: le pagine non accessibili o bloccate possono comunque restituire un campo content vuoto.

Fetch serve per un URL che hai già scelto. Restituisce Markdown, ma invia un URL per richiesta. DeepSeek specifica che il fetch dipende dalla disponibilità del sito di destinazione e dalle sue policy di accesso: un risultato Search riuscito non garantisce quindi un Fetch riuscito.

I risultati di Search includono un rerank_score da 0 a 3 e un livello di authority da -1 a 4. La documentazione considera segnali di alta qualità gli score di almeno 1.5 e i valori di authority di almeno 3. Sono metadati del servizio, non benchmark indipendenti della qualità della ricerca.

La sintassi delle query supporta filtri pratici come site:, -site:, frasi tra virgolette, lang:, after: e before:. Per esempio:

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

Prezzi che incidono sull'architettura

DeepSeek indica per Search e Fetch un costo di $0.75 per 1.000 richieste riuscite, ossia $0.00075 per ogni richiesta fatturabile. La fatturazione avviene per richiesta, non per token né in base al numero di risultati restituiti. Consulta la pagina ufficiale dei prezzi.

La tariffa dell'endpoint non rappresenta l'intero costo di un'attività di ricerca con AI: token di input e output del modello, oltre agli ulteriori turni dell'agente attorno al retrieval, vengono fatturati separatamente.

Una formula di costo realistica

In un flusso semplice, la componente di retrieval è:

successful Search calls * $0.00075
+ successful Fetch calls * $0.00075
+ model input and output token charges

Un batch di 10.000 ricerche costa $7.50 se ogni richiesta Search produce risultati. Se l'applicazione esegue il fetch di una pagina per ciascun risultato, altre 10.000 chiamate Fetch riuscite aggiungono $7.50, prima di considerare i token del modello. Chiedere 50 risultati a Search non moltiplica il costo della richiesta, ma può aumentare la quantità di testo che il modello deve elaborare.

Ecco perché need_content merita una policy esplicita. Usalo per piccoli insiemi di pagine; scegli invece Search con soli metadati seguito da Fetch selettivo quando vuoi filtrare prima per score, dominio, data o authority.

@haolv511482 ha segnalato: “Check the content field before adding a fetch loop. Search can return page text with need_content=true ... Otherwise your agent may pay to read the same page twice.” Fonte

Limiti ed errori da prevedere nel design

La guida ufficiale documenta un massimo di 50 risultati per richiesta Search e quote separate di 5 richieste al secondo per account, sia per Search sia per Fetch. Anche in un deployment con più worker servono quindi limiter specifici per endpoint.

Fetch è particolarmente sensibile al comportamento dei siti. La documentazione ufficiale limita la garanzia alla disponibilità del sito di destinazione e alle relative policy di accesso; non promette esecuzione JavaScript, una sessione browser, selezione dello user-agent, screenshot o conservazione dell'HTML grezzo. In un primo test, @jiangkoumo_ ha riportato che siti fortemente renderizzati in JavaScript potevano restituire 404, mentre una normale pagina pubblica veniva convertita in Markdown. Fonte

Gli stessi test iniziali hanno evidenziato un trade-off rilevante nella copertura. @bei351009016 ha riportato appena il 2.1% di sovrapposizione con Exa su 29 query e 12 piattaforme, descrivendo DeepSeek come veloce e aggiornata per le fonti cinesi ma debole su WeChat e YouTube. Fonte

Considera questo test iniziale come un'indicazione di massima e verifica le tipologie di fonte che ti servono.

Un pattern di implementazione essenziale

Questo esempio separa retrieval e generazione della risposta, evita Fetch quando Search ha già restituito il contenuto e distanzia le chiamate a 5 al secondo per questo processo. In un deployment multi-worker serve comunque un unico limiter condiviso.

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))

Quando DeepSeek non basta come unico provider

DeepSeek è una scelta valida per la scoperta di fonti a basso costo, soprattutto quando il corpus include fonti cinesi e l'applicazione può convivere con il limite di 5 QPS per account. È invece meno adatta come provider unico quando il carico di lavoro dipende da YouTube, WeChat, pagine fortemente renderizzate lato client o dal ranking di uno specifico motore di ricerca.

Un'architettura ibrida è più difendibile:

1. Invia a DeepSeek query di discovery ampie ed economiche.
2. Filtra per dominio, data, authority e rerank score.
3. Usa un secondo provider per le classi di fonti che DeepSeek non trova.
4. Esegui il fetch solo degli URL selezionati.
5. Confronta il supporto alla risposta con il testo delle fonti archiviato.

Anche la gestione dei dati è una decisione di deployment. Prima di inviare query sensibili, verifica i termini correnti di DeepSeek e i tuoi requisiti di conformità; le preoccupazioni espresse dalla community non dimostrano una specifica policy di conservazione. Fonte

Checklist operativa prima della produzione

1. Registra separatamente le chiamate Search e Fetch, così da poter riconciliare la fattura.
2. Controlla content prima di eseguire il fetch di un URL restituito da Search.
3. Applica un limiter condiviso di 5 QPS a ogni worker e subagente.
4. Riprova solo le risposte 408, 429 e 5xx transitorie.
5. Archivia URL, titolo, data, authority, rerank score e ora del retrieval.
6. Rifiuta schemi non supportati e URL di reti private in ogni percorso Fetch controllato dall'utente.
7. Tratta il testo delle pagine come dati non attendibili, non come istruzioni per gli strumenti.
8. Esegui un set di test con pagine ufficiali in inglese, fonti cinesi, forum, pagine video e siti ricchi di JavaScript.
9. Misura il costo totale dell'attività, inclusi token del modello e retry, invece di riportare solo il prezzo di Search.

FAQ sulla DeepSeek Search API

L'API è disponibile automaticamente tramite chiamate compatibili con OpenAI?

L'endpoint Search diretto è una route separata, POST /v1/tools/search. Una normale richiesta al modello non naviga sul web soltanto perché il client usa un base URL compatibile con OpenAI. Aggiungi direttamente le chiamate Search/Fetch oppure usa un'integrazione client documentata da DeepSeek.

DeepSeek Search è il miglior sostituto per qualsiasi provider di ricerca?

No. È un'interessante opzione di retrieval a basso costo, ma i primi test degli utenti hanno rilevato una copertura diversa rispetto a Exa e lacune attorno a YouTube e WeChat. Prima di renderla il tuo unico provider, esegui un piccolo test sul carico di lavoro specifico.