API di ricerca e fetch web: come funzionano e cosa compri con $0.01

Tutti i principali strumenti di ricerca web lato server applicano ormai la stessa tariffa: $0.01 per ricerca. Ed è la voce meno interessante della fattura. Nelle nostre misurazioni, ogni richiesta ha ricevuto tra 1.500 e 3.100 token di risultati, fatturati alla tariffa del modello scelto. Il costo del turno successivo dipende invece da una differenza di protocollo che quasi nessuno considera: l’endpoint mantiene i risultati della ricerca nel contesto oppure li elimina, costringendo il modello a cercare di nuovo a pagamento? Abbiamo misurato synthorai:web_search e synthorai:web_fetch di Synthorai su quattro famiglie di modelli e confrontato i risultati con i prezzi pubblicati da Anthropic e OpenAI per i rispettivi servizi di ricerca in hosting.

TL;DR

• Synthorai, Anthropic e OpenAI applicano tutti $0.01 per ricerca; nei dati di fatturazione la voce compare come $0.0100.
• Una ricerca aggiunge 1.500-3.100 token di risultati, fatturati alla tariffa di input del modello: con i modelli economici domina il costo fisso, con quelli premium i token arrivano a pesare per metà.
• max_uses è un limite massimo, non una quota: con 10 ricerche consentite, il modello si è fermato a 3; si pagano solo le ricerche effettivamente eseguite.
• Al secondo turno il comportamento cambia in base all’endpoint: /v1/messages reinvia i risultati (≈3.900 token, nessun nuovo costo fisso); /v1/chat/completions li elimina, quindi un follow-up che richiede le fonti avvia una nuova ricerca a pagamento.

Perché i modelli hanno bisogno di ricerca e fetch web?

Perché le conoscenze di un modello si fermano alla data limite del training, mentre molte domande in produzione riguardano dati successivi. Prezzi, note di rilascio, tassi di cambio, risultati sportivi o il contenuto di un URL appena incollato dall’utente non sono presenti nei pesi. Rispondere comunque con sicurezza è il modo più semplice per mostrare agli utenti informazioni “aggiornate” ma inventate. La ricerca web colma il vuoto quando serve trovare la fonte e il modello non sa dove cercare; il fetch web serve invece a leggere una pagina già nota. È possibile implementare entrambe le funzioni con una search API, uno scraper e un ciclo di tool calling, e molti team lo fanno. Le versioni lato server esistono perché questo ciclo è solo infrastruttura indifferenziata: eseguirlo nel provider elimina round trip, codice di parsing e complessità operativa, con una tariffa che ormai è uguale ovunque.

Come funziona davvero la ricerca web lato server?

L’intero ciclo si svolge in una sola richiesta API. Con i tool lato client, il modello chiede al codice applicativo di eseguire una ricerca; il codice restituisce i risultati e, a ogni passaggio, reinvia tutta la conversazione. Un server tool esclude il codice applicativo dal ciclo: si dichiara {"type": "synthorai:web_search"} in tools, il modello genera una query, il gateway la invia a un provider di ricerca dedicato, inserisce i risultati nel contesto e il modello li legge per formulare la risposta. Se necessario, può cercare ancora, fino al limite max_uses. Una richiesta in ingresso, una risposta in uscita, citazioni e costi inclusi.

Basta una riga in una normale richiesta; non servono cicli né callback:

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}]
  }'

Il fetch web usa la stessa dichiarazione con un tipo diverso; basta inserire l’URL nel messaggio e il gateway recupera la pagina:

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

Il diagramma riproduce esattamente la richiesta di ricerca descritta sopra, misurata su deepseek-v4-flash-0731. Il contatore riportava 2.059 token di input, cioè una domanda da 30 token più circa 2.000 token di risultati, 169 token di output e un costo totale di $0.0104: $0.01 per la ricerca e circa $0.0004 per i token. Le voci di costo sono soltanto due: la tariffa applicata quando parte la ricerca e i token dei risultati alla normale tariffa di input del modello. Il fetch viene fatturato allo stesso modo, sostituendo gli snippet con il contenuto della pagina recuperata.

La dichiarazione non costa nulla: se una richiesta dichiara il tool ma non esegue ricerche, non viene applicata alcuna tariffa. Il tool funziona inoltre con qualsiasi modello del catalogo. È questa la differenza strutturale rispetto alle alternative proprietarie: la ricerca in hosting di Anthropic funziona con i modelli Claude, quella di OpenAI con i modelli OpenAI, mentre un tool implementato a livello di gateway funziona con qualsiasi modello scelto per il routing.

Quanto costa davvero una ricerca?

Il costo è composto da $0.01 di tariffa fissa più i token. All’aumentare del prezzo del modello cambia la voce dominante. Abbiamo eseguito tre volte la stessa domanda di attualità, con una sola ricerca, su quattro famiglie di modelli. Abbiamo ricavato le tariffe esatte dei token da baseline senza tool e calcolato la tariffa fissa come valore residuo:

Sul modello più economico, la tariffa di ricerca rappresenta il 97% del costo della chiamata; sui modelli premium, i token aggiunti assorbono metà della spesa. La tariffa non è una stima: nei nostri dati di fatturazione il costo del tool compare come voce separata, pari esattamente a $0.0100 per chiamata, insieme al conteggio distinto dei token aggiunti dal tool. In una chiamata di fetch reale, per esempio, erano 3.454 sui 3.836 token di input totali. Il costo complessivo misurato per una singola ricerca era compreso tra $0.010 e $0.012, a seconda del modello. Usando l’estremo superiore per il budget non ci saranno sorprese. In pratica, abbinando la ricerca lato server a un modello economico si paga quasi solo il servizio di ricerca, mentre il costo del modello diventa trascurabile.

Quali sono le tre leve che determinano il costo dei token?

Numero di ricerche, lunghezza dei risultati e dimensione della pagina. Il resto è trascurabile. Tutte e tre le grandezze sono misurabili e due dipendono direttamente dalla configurazione.

Prima leva: quante ricerche vengono eseguite. max_uses indica un limite massimo, non un obiettivo. Per una domanda sui prezzi di cinque vendor, consentire 1, 2 e 3 ricerche ha prodotto costi rispettivamente di $0.0106, $0.0216 e $0.0319. Le tariffe crescono linearmente di $0.01 per ogni ricerca effettivamente eseguita. Consentirne 5 o persino 10 non ha modificato il costo, perché il modello si è fermato autonomamente a tre. La capacità inutilizzata è gratuita, proprio come i budget di thinking che abbiamo misurato sui modelli di reasoning. Il valore predefinito è 3, con un limite massimo rigido di 10. Senza configurazione, nel caso peggiore una domanda che induce molte ricerche comporta tre tariffe e tre carichi di risultati. Sulle route che richiedono un singolo dato conviene impostare max_uses: 1.

Seconda leva: la lunghezza dei risultati. La quantità di token aggiunti dipende dall’ampiezza della domanda, non dal caso. Su dodici esecuzioni con una sola ricerca su deepseek-v4-flash-0731:

Le domande circoscritte producono set di risultati compatti; quelle comparative ne producono di più ampi, circa il 45% più pesanti rispetto alla ricerca di un singolo dato. Per il budget si possono considerare 2.000 token per ricerca, con un margine del 20%: copre tutti i casi osservati. Alle tariffe tipiche dei modelli, la componente token di una ricerca varia da un ventesimo alla metà della tariffa di $0.01.

Terza leva: la dimensione della pagina recuperata. La tariffa del fetch resta invariata; il resto dipende dalla pagina. Questa è la scala misurata, sempre con lo stesso modello:

Con un modello economico, persino l’articolo di Wikipedia costa circa un centesimo e mezzo. Eseguendo lo stesso fetch con un modello da $2 per milione di token, una sola pagina costa sei centesimi e mezzo, cinque volte la tariffa fissa. Per il foglio di budget va considerato anche che la stessa pagina viene tokenizzata in modo diverso dalle varie famiglie di modelli. L’articolo ricco di dati occupava 5.196 token su DeepSeek e 5.508 su qwen3.8-max: un sovrapprezzo del 6% dovuto al tokenizer, coerente con le nostre misurazioni di densità.

Cosa succede ai risultati della ricerca nel turno successivo?

La differenza dipende dalla struttura dei due protocolli API e determina il costo dei follow-up. Il protocollo /v1/messages rappresenta un turno dell’assistente come un elenco di blocchi di contenuto. L’attività dei server tool entra quindi nel record ufficiale del turno: la risposta contiene server_tool_use, web_search_tool_result e infine il testo, e il protocollo prevede che questi blocchi vengano reinviati nel turno successivo. Le fonti restano nel contesto e vengono fatturate come token di input. Il protocollo /v1/chat/completions, invece, rappresenta il messaggio dell’assistente come un’unica stringa senza uno spazio dedicato ai risultati dei server tool. I risultati aggiunti vengono assorbiti lato server; nella cronologia resta soltanto la risposta visibile e le fonti scompaiono.

Abbiamo eseguito la stessa coppia ricerca-follow-up su claude-sonnet-5 usando entrambe le API. Con /v1/messages, il follow-up ha fatturato 3.911 token di input e $0.0109, tutti attribuibili ai token: nessuna nuova ricerca, perché il modello disponeva ancora dei risultati. Con /v1/chat/completions, il follow-up è costato $0.0204, più del replay, perché il modello aveva soltanto il proprio riepilogo di una riga e ha avviato una nuova ricerca: altri $0.01 più un nuovo carico di risultati. La nuova ricerca resta una scelta, non un comportamento obbligatorio. In un’esecuzione precedente dello stesso follow-up con risultati assorbiti, deepseek-v4-flash-0731 ha risposto direttamente dal riepilogo, usando 460 token di input per un costo di $0.00009. Con l’assorbimento, il costo del follow-up ha due modalità: quasi nullo se basta il riepilogo, oppure tariffa più nuovi risultati se il modello decide di consultare ancora il web.

Non esiste quindi un endpoint sempre più economico: i costi si distribuiscono in punti diversi. Lo stile a blocchi comporta un costo prevedibile in token a ogni turno e non riacquista mai fonti già disponibili. Lo stile con assorbimento scommette che i follow-up non avranno bisogno delle fonti e applica una nuova tariffa ogni volta che la scommessa fallisce. Le chat lunghe con follow-up semplici si adattano bene a /v1/chat/completions; gli agenti di ricerca che interrogano ripetutamente le fonti sono più adatti a /v1/messages, dove la strategia di stratificazione della prompt cache si applica ai risultati mantenuti nel contesto come a qualsiasi altro contenuto voluminoso.

Quanto costano Anthropic e OpenAI e dove funzionano i loro tool?

Il confronto è semplice: tutti applicano $0.01 per ricerca; il resto dipende dal prezzo dei token del modello. Anthropic addebita $10 ogni 1.000 ricerche e fattura i risultati come token di input; il suo web fetch non ha una tariffa fissa e si pagano solo i token. OpenAI applica gli stessi $10 ogni 1.000 chiamate, con un trattamento dei token che varia in base alla fascia del modello. La tariffa fissa è ormai uniforme; la variabile è il costo di 1.500-3.100 token di input sul modello scelto.

La differenza decisiva non compare nel listino: riguarda l’ambiente in cui funzionano i tool. I server tool proprietari sono progettati per gli stack agentici dei rispettivi vendor e restano confinati alle loro piattaforme. La documentazione Anthropic specifica che la ricerca web non è disponibile su Amazon Bedrock; Google Cloud supporta soltanto la ricerca di base, mentre Microsoft Foundry richiede un deployment ospitato su Anthropic. Il web fetch non è disponibile né su Bedrock né su Google Cloud. La ricerca di OpenAI è legata alla Responses API. Spostando il workload tra cloud o famiglie di modelli, il tool proprietario non segue il traffico. Per lo stesso motivo un gateway non si limita a inoltrare questi tool: non potrebbero accompagnare le richieste. Un tool a livello di gateway sceglie il compromesso opposto: una sola dichiarazione che continua a funzionare anche cambiando modello o piattaforma.

FAQ

Quanto costa la ricerca web API per richiesta?

$0.01 per ogni ricerca eseguita, registrati come voce separata nei dati di fatturazione, più i risultati aggiunti e fatturati come token di input alla tariffa del modello: nelle nostre esecuzioni erano 1.500-3.100 token per ricerca. Una richiesta che dichiara il tool ma non esegue ricerche non paga alcuna tariffa. Per i modelli tipici, conviene preventivare $0.010-0.012 complessivi per ricerca; sui modelli molto economici, la tariffa rappresenta il 97% del totale.

I risultati della ricerca vengono fatturati di nuovo nei turni successivi?

Dipende dall’endpoint. Con /v1/messages, i blocchi dei risultati vengono reinviati insieme alla cronologia, circa 3.900 token di input per turno nelle nostre prove, senza nuove tariffe di ricerca. Con /v1/chat/completions, i risultati vengono assorbiti al termine del turno. Il follow-up costa quasi nulla se il modello risponde dal riepilogo, $0.00009 in una prova, ma comporta una nuova tariffa e un nuovo carico di risultati se avvia un’altra ricerca, $0.0204 in un altro caso. La ricerca proprietaria di Anthropic documenta il replay come comportamento standard; in quel caso i risultati vengono fatturati di nuovo a ogni turno.

Come posso limitare la spesa per la ricerca web in una richiesta?

Con max_uses. È un limite rigido che il modello non può superare, con valore predefinito 3 e massimo 10. Le tariffe dipendono soltanto dalle ricerche effettivamente eseguite e la capacità inutilizzata non costa nulla. Per le route che richiedono un singolo dato, max_uses: 1 limita il caso peggiore a una tariffa e un solo carico di risultati.

Quando conviene usare il web fetch invece della ricerca web?

Il fetch è indicato quando l’URL è già noto e serve leggere l’intera pagina; la ricerca serve invece a trovare le fonti. Tramite il gateway entrambi costano $0.01 per utilizzo, ma il fetch aggiunge l’intera pagina, da 209 token per una pagina minimale fino a 27.380 per un articolo lungo nella nostra scala, mentre la ricerca aggiunge snippet provenienti da più fonti. Nelle pipeline di lettura e riepilogo basate specificamente sui modelli Claude, il tool di fetch di Anthropic è più economico perché non applica una tariffa fissa.

Misurazioni effettuate il 2026-08-10 tramite il gateway Synthorai usando synthorai:web_search e synthorai:web_fetch su deepseek-v4-flash-0731, gpt-5.6-luna, qwen3.8-max e claude-sonnet-5: tariffe dei token per modello ricavate da baseline a due punti senza tool, tariffe di ricerca calcolate come residuo tra costo fatturato e valore dei token (n=3 per modello), scala di max_uses, analisi del carico dei risultati per tipo di query (4 tipi x 3 esecuzioni), prove dei turni successivi su entrambi gli endpoint con domande identiche e scala di fetch su cinque pagine (tre pagine nostre, una pagina esterna minimale e un articolo lungo). Le tariffe sono state verificate sui dati di fatturazione dettagliati, con voci separate per il costo del tool e i token aggiunti, non dedotte soltanto dai totali. I valori di Anthropic e OpenAI provengono dalle rispettive tariffe pubblicate al momento della pubblicazione. I numeri del diagramma corrispondono a una singola chiamata misurata e non modificata. Tariffe e comportamento possono cambiare; verificate i vostri dati di utilizzo.

← Torna al blog