Token input e output: perché Claude costa di più
I token di output costano cinque volte quelli di input in Claude: scopri perché il decoding è più lento del prefill e come cambia il costo mensile di un agente.
Perché i token di output costano più dei token di input
I token di output costano cinque volte i token di input in ogni modello Claude del catalogo attuale. La causa è il modo in cui viene eseguito il calcolo. La lettura di un prompt richiede un'unica passata sul modello. La generazione di una risposta richiede una passata per ogni token, e ogni passata deve attendere il completamento di quella precedente.
Questo rapporto è identico in ogni riga del listino prezzi, quindi il modello scelto non modifica la quota della fattura attribuibile all'output. A determinarla è la struttura del carico di lavoro. Un passaggio di un agente che legge 60,000 token e risponde con 800 incide quasi per nulla sull'output. Un'attività di redazione che legge 2,000 token e ne genera 12,000 incide quasi per nulla sull'input. Di seguito vengono analizzati entrambi i casi usando le tariffe pubblicate da Anthropic, verificate il 27 ottobre 2026.
Il prefill viene eseguito una volta, il decoding una volta per token
Un server di inferenza gestisce una richiesta in due fasi, con costi molto diversi. Il prefill legge il prompt. Il decoding genera la risposta.
Il prefill elabora l'intero prompt in una volta sola. Tutti i token del prompt entrano nella rete nello stesso forward pass, quindi il lavoro di attention e feed-forward diventa un numero ridotto di grandi moltiplicazioni matriciali che coprono migliaia di token per volta. Una sola lettura dei pesi del modello dalla memoria è sufficiente per l'intero prompt. Le unità matriciali dell'acceleratore restano occupate, quindi il prefill è solitamente limitato dal calcolo: il limite è la velocità con cui il chip può eseguire le moltiplicazioni. La documentazione NVIDIA per il serving indica le eccezioni: i prefill molto brevi e quelli in cui un prefisso lungo è già presente nella cache diventano invece limitati dalla memoria.
Il decoding ordinario non può funzionare nello stesso modo, perché il token 2 dipende dal token 1. Il token appena prodotto dal modello diventa parte dell'input per il passaggio successivo, quindi i passaggi vengono eseguiti uno dopo l'altro. Ogni token generato richiede un proprio forward pass, e ognuno di questi passaggi legge dalla memoria ad alta larghezza di banda l'intero insieme dei pesi del modello, oltre alla KV cache (key/value cache, lo stato di attention memorizzato per ogni token generato fino a quel momento), per produrre un solo token. Questo rende il decoding solitamente limitato dalla memoria: il limite è la velocità con cui si possono trasferire i pesi e lo stato memorizzato nella cache, non la velocità con cui possono essere eseguite le moltiplicazioni. Nei contesti lunghi, NVIDIA indica in particolare le letture della KV cache come collo di bottiglia. Lo stesso traffico dei pesi che durante il prefill elabora un intero prompt consente di generare un solo token durante il decoding.
Il decoding speculativo modifica questa regola senza eliminarla. Un modello draft di dimensioni ridotte anticipa diversi token, mentre il modello più grande li verifica tutti in parallelo con un singolo passaggio. NVIDIA afferma che questo può spostare il decoding verso un comportamento limitato dal calcolo. Il modello più grande accetta comunque le ipotesi nell'ordine e si ferma al primo token errato, quindi una risposta lunga richiede ancora molti passaggi.
I sistemi di serving compensano questa limitazione usando il batching. Molte richieste eseguono il decoding insieme, quindi una lettura dei pesi produce un token per ogni richiesta del batch. È questo che rende il decoding sostenibile. Anche in questo caso il limite è la memoria. Ogni richiesta in corso mantiene la propria KV cache, che cresce a ogni token generato. Quando la memoria dell'acceleratore è piena, il batch non può più crescere.
Nulla di tutto questo fornisce un numero esatto, e non si dovrebbe interpretare 5x come un rapporto hardware misurato. È un prezzo stabilito da Anthropic e determinato da questa asimmetria. Quello che si può verificare direttamente è la direzione della differenza, e richiede circa un minuto.
Misura personalmente il tempo di attesa tra input e output
Installa gli strumenti su qualsiasi sistema Ubuntu:
sudo apt update && sudo apt install -y curl jq moreutilsOra invia in streaming un prompt breve che richiede una risposta lunga e stampa ogni riga con l’ora di arrivo.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
"messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
| ts -s '%.s'ts -s antepone a ogni riga i secondi trascorsi dall’avvio del comando. Dall’output si possono ricavare due informazioni. La prima riga con content_block_delta indica il tempo al primo token; tutto il prefill è avvenuto al suo interno. Ogni riga successiva corrisponde a un piccolo passaggio di decoding e i valori continuano ad aumentare finché non arriva message_stop.
Ora inverti la situazione. Inserisci un documento lungo nel prompt e limita la risposta a pochi token.
curl -sN https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d "$(jq -n --rawfile doc ./long-document.txt \
'{model:"claude-sonnet-5", max_tokens:16, stream:true,
messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
| ts -s '%.s'Il primo intervallo è più lungo rispetto a quello del prompt breve, perché il prefill deve leggere molto più testo. Dopo il suo arrivo, la risposta termina quasi subito, perché restano da decodificare soltanto pochi token. Sono entrate decine di migliaia di token e il tempo è aumentato appena. Ne sono usciti alcune centinaia e il clock ha continuato a scorrere per tutta la durata.
Ogni risposta non in streaming termina con i numeri usati per calcolare l’addebito.
{
"usage": {
"input_tokens": 41283,
"output_tokens": 6,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 0
}
}Registra tutti e quattro i campi per ogni richiesta. output_tokens include i token di ragionamento, quindi un modello che ragiona prima di rispondere addebita anche questi token alla tariffa di output. Per stimare il costo di un prompt prima di inviarlo, POST /v1/messages/count_tokens accetta lo stesso corpo della richiesta per la maggior parte delle richieste, restituisce {"input_tokens": N} come stima senza eseguire il modello ed è gratuito, entro il proprio limite di richieste. Rifiuta alcuni corpi che la Messages API accetta: la maggior parte degli strumenti server, come la ricerca sul web, il connettore MCP e i blocchi immagine o documento con una sorgente url o file; per contarli, invia quindi immagini e PDF in formato base64. Non è l’unica parte dell’API che non comporta costi: prima di definire il budget del primo progetto, conviene verificare anche quali parti della Claude API non vengono mai addebitate.
Quanto addebita Claude per milione di token a ottobre 2026
I dati alla base di questo grafico
[
{
"label": "Haiku 4.5",
"input_usd": 1,
"output_usd": 5,
"output_multiple": 5
},
{
"label": "Sonnet 5",
"input_usd": 2,
"output_usd": 10,
"output_multiple": 5
},
{
"label": "Opus 5",
"input_usd": 5,
"output_usd": 25,
"output_multiple": 5
},
{
"label": "Fable 5",
"input_usd": 10,
"output_usd": 50,
"output_multiple": 5
}
]L'ultima colonna è l'output diviso per l'input e riporta 5 in ogni riga. Haiku 4.5 addebita $1 per l'input e $5 per l'output. Opus 5 addebita $5 e $25. Fable 5, il più costoso, addebita $10 e $50; vale la pena leggere cosa si ottiene con queste tariffe di Fable 5 prima di scartare quella riga. Salendo nella gamma, entrambi i valori vengono moltiplicati per lo stesso fattore. Il totale cambia, ma la ripartizione tra input e output resta esattamente la stessa.
Sonnet 5 addebita $2 per l'input e $10 per l'output. Anthropic lo ha lanciato a questa tariffa come prezzo introduttivo fino al 31 August 2026, con un aumento a $3 e $15 previsto per il 1 September. In seguito ha invece fissato il prezzo standard a $2 e $10. L'aumento non è mai entrato in vigore, quindi la tariffa riportata in ogni esempio seguente è quella applicata oggi.
Anthropic ha rilasciato anche modelli più recenti da quando questa pagina è stata pubblicata per la prima volta. Ora claude.com/pricing elenca i quattro modelli precedenti come modelli legacy ancora disponibili. I nuovi modelli mantengono lo stesso rapporto 5x. Opus 5.5 addebita $4 e $20, Sonnet 5.5 addebita $2 e $10, Fable 5.1 addebita $10 e $50, mentre Haiku 5.5 addebita $0.10 e $0.50 per prompt fino a 100,000 token, aumentando a $0.50 e $2.50 oltre tale soglia. Il costo del passaggio dell'agente da 60,000 token, calcolato più avanti, rientra nella prima fascia. Tuttavia, un agente la cui cronologia continua a crescere supererà prima o poi la soglia. Come si applicano le due fasce di prezzo di Haiku 5.5 ai lavori reali mostra l'effetto di questo passaggio sul costo. Le tariffe di base per input e output di Opus 5.5 sono inferiori del 20% rispetto a quelle di Opus 5. Pertanto, ogni valore seguente relativo a Opus 5 senza cache è inferiore del 20% su Opus 5.5. I valori con cache diminuiscono ulteriormente, perché Opus 5.5 legge gli accessi alla cache a $0.20 per milione di token, contro $0.50 per Opus 5: una riduzione del 60%. Il passaggio dell'agente con cache che più avanti costa $0.0725 su Opus 5 costa circa $0.047 su Opus 5.5, con una riduzione di circa il 35%.
Le tariffe cambiano e questa pagina non è la fonte da consultare per verificarle. claude.com/pricing è la fonte ufficiale. Ciò che resta valido dopo una variazione di prezzo è il metodo.
Una precisazione si trova nelle note sotto la tabella dei prezzi di Anthropic, non nelle tariffe vere e proprie. La pagina dei prezzi di Anthropic afferma che Claude 4.7 e i modelli successivi usano un tokenizer più recente, che produce circa il 30% di token in più per lo stesso testo rispetto al tokenizer di Sonnet 4.6 e dei modelli precedenti. Confrontare due modelli soltanto in base al prezzo per milione di token favorisce artificialmente quello più recente, perché lo stesso documento contiene più token su quel modello. Il confronto corretto è il costo per attività completata; conta i prompt reali usando il modello che intendi adottare. Lo stesso problema si presenta tra provider diversi, perché anche i loro tokenizer non coincidono. Per questo, calcolare il costo di un lavoro reale su Claude e ChatGPT è più utile che mettere semplicemente a confronto le due tabelle tariffarie. Quanto valgono in pratica un milione di token Claude spiega che cosa rappresenta realmente questo volume di testo.
Quando l'output inizia a incidere maggiormente sul costo?
Con l'output tariffato a 5 volte il costo dell'input, il punto di pareggio è facile da calcolare mentalmente. Indichiamo con I i token di input e con O i token di output. Il costo dell'input è I. Il costo dell'output è 5 volte O. L'output supera la metà della spesa quando 5 volte O è maggiore di I, cioè quando il rapporto tra i token è di 5 token di input per 1 token di output.
Quindi, se il prompt è più di cinque volte più lungo della risposta, l'input rappresenta la voce di costo maggiore. Al di sotto di questo rapporto, prevale l'output.
I dati alla base di questo grafico
[
{
"label": "100:1",
"input_share_pct": 95.2,
"output_share_pct": 4.8
},
{
"label": "75:1",
"input_share_pct": 93.75,
"output_share_pct": 6.25
},
{
"label": "20:1",
"input_share_pct": 80,
"output_share_pct": 20
},
{
"label": "10:1",
"input_share_pct": 66.7,
"output_share_pct": 33.3
},
{
"label": "5:1",
"input_share_pct": 50,
"output_share_pct": 50
},
{
"label": "1:1",
"input_share_pct": 16.7,
"output_share_pct": 83.3
},
{
"label": "1:6",
"input_share_pct": 3.2,
"output_share_pct": 96.8
}
]Con un rapporto di 100 a 1, l'output rappresenta il 4.8% della spesa e ridurre il prompt è l'unico intervento utile. Con un rapporto di 5 a 1, le due componenti hanno lo stesso costo. Con un rapporto di 1 a 6, l'output rappresenta il 96.8% e il costo del prompt è trascurabile. La maggior parte delle persone valuta in modo errato il proprio rapporto, quindi ricavalo dai log prima di ottimizzare qualsiasi cosa.
Un workload di un agente: molto contesto in ingresso, risposta breve in uscita
Esegui un passaggio di un agente di recupero: 60,000 token di documenti recuperati e cronologia della conversazione in ingresso, e una risposta di 800 token. Il rapporto è 75 a 1, un valore normale per qualsiasi sistema che legge prima di scrivere.
I dati alla base di questo grafico
[
{
"label": "Haiku 4.5",
"input_cost": 0.06,
"output_cost": 0.004,
"total_cost": 0.064
},
{
"label": "Sonnet 5",
"input_cost": 0.12,
"output_cost": 0.008,
"total_cost": 0.128
},
{
"label": "Opus 5",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "Fable 5",
"input_cost": 0.6,
"output_cost": 0.04,
"total_cost": 0.64
}
]L’output rappresenta il 6.25% di quella chiamata su ogni modello, perché il rapporto è fisso nell’intero listino prezzi. La chiamata costa $0.32 su Opus 5, $0.128 su Sonnet 5 e $0.064 su Haiku 4.5. Duecento di questi passaggi al giorno su Opus 5 costano $64 al giorno.
Una volta osservata la suddivisione, la leva è evidente. Ridurre la risposta da 800 token a 400 consente di risparmiare circa il 3% del costo della chiamata. Eliminare dal prompt 20,000 token di contesto obsoleto consente di risparmiare circa un terzo del costo. Ridurre la lunghezza dell’output in un agente che dedica la maggior parte del lavoro alla lettura è quasi inutile. dove finiscono realmente i token di un agente di programmazione analizza che cosa riempie il prompt.
Un carico di generazione: prompt breve, bozza lunga
Ora invertiamo la proporzione. Un brief di 2,000 token e una bozza di 12,000 token, con un rapporto di 1 a 6.
I dati alla base di questo grafico
[
{
"label": "Haiku 4.5",
"input_cost": 0.002,
"output_cost": 0.06,
"total_cost": 0.062,
"batch_total_cost": 0.031
},
{
"label": "Sonnet 5",
"input_cost": 0.004,
"output_cost": 0.12,
"total_cost": 0.124,
"batch_total_cost": 0.062
},
{
"label": "Opus 5",
"input_cost": 0.01,
"output_cost": 0.3,
"total_cost": 0.31,
"batch_total_cost": 0.155
},
{
"label": "Fable 5",
"input_cost": 0.02,
"output_cost": 0.6,
"total_cost": 0.62,
"batch_total_cost": 0.31
}
]L'output rappresenta il 96.8% di questo costo. Opus 5 costa $0.31 per bozza, contro $0.062 di Haiku 4.5. Questa differenza di cinque volte dipende quasi interamente dall'output, proprio la componente in cui un modello più economico consente il maggiore risparmio.
L'ultima colonna mostra lo stesso lavoro tramite Batch API, che dimezza i costi di input e output. Opus 5 scende a $0.155 per bozza. Batch è asincrono e non restituisce il risultato immediatamente. Anthropic dichiara che la maggior parte dei batch viene completata in meno di un'ora, ma un batch ancora in elaborazione dopo 24 ore scade; tutte le richieste non ancora raggiunte entro quel momento vengono restituite come scadute, senza addebito e senza messaggio. È quindi adatto alla generazione notturna di report e alla classificazione in blocco, prevedendo un nuovo invio per gli elementi scaduti. Non è adatto alle attività per cui una persona deve attendere il risultato.
Il routing tra modelli è vantaggioso in questo caso, ma non lo è mai nella fase dell'agente. Se la parte prolissa del lavoro è meccanica, come riformattare il testo o ampliare una struttura già approvata, il modello economico genera quei token a un quinto del prezzo. scegliere tra Opus, Sonnet e Haiku spiega dove si colloca effettivamente la soglia di qualità.
La memorizzazione nella cache riduce il costo degli input, e solo degli input
La memorizzazione nella cache dei prompt conserva un prefisso del prompt sul server e applica una frazione della tariffa degli input quando viene letto nuovamente. Al 27 ottobre 2026, i moltiplicatori sono 1.25x la tariffa base degli input per scrivere una cache di 5 minuti, 2x per scrivere una cache di 1 ora e 0.1x per leggere un riscontro positivo nella cache sui modelli con i prezzi indicati in questa pagina. I modelli più recenti applicano una tariffa inferiore ai riscontri positivi: 0.05x su Opus 5.5 e Sonnet 5.5 e 0.025x su Fable 5.1.
L'output non rientra in questa agevolazione. Non esiste output memorizzato nella cache. Ogni token generato dal modello viene addebitato ogni volta alla tariffa completa degli output, indipendentemente dalla quantità di prompt restituita come riscontro positivo nella cache.
Esegui lo stesso passaggio dell'agente su Opus 5, con 55,000 dei 60,000 token di input forniti da una cache calda.
I dati alla base di questo grafico
[
{
"label": "No cache",
"input_cost": 0.3,
"output_cost": 0.02,
"total_cost": 0.32
},
{
"label": "55k prefix cache read",
"input_cost": 0.0525,
"output_cost": 0.02,
"total_cost": 0.0725
}
]La chiamata passa da $0.32 a $0.0725. La riga dell'output non cambia: $0.02 prima e $0.02 dopo. La memorizzazione nella cache riduce il costo e ne modifica la composizione. L'output rappresentava il 6.25% di quella chiamata. Ora supera un quarto del totale, e cambia la leva da utilizzare per prima.
La prima chiamata sostiene il costo di scrittura. Scrivere una cache di 5 minuti costa 1.25x la tariffa base degli input, quindi il costo viene recuperato dopo un solo riscontro positivo. Scrivere una cache di 1 ora costa 2x, quindi ne servono due. lavorano sull'aritmetica dei moltiplicatori di scrittura e lettura e indicano quando la memorizzazione nella cache non è più conveniente.
Quattro leve sotto il tuo controllo
- Imposta
max_tokenssulla lunghezza p95 dell'output, non sul limite massimo del modello. - Invia i passaggi verbosi a un modello più economico.
- Esegui in batch tutto ciò per cui nessuno sta aspettando una risposta.
- Elimina le istruzioni che allungano le risposte.
max_tokens è un limite massimo rigido. Impostarlo su un valore alto non ha costi diretti, perché paghi i token prodotti e mai il limite massimo. Un limite generoso serve a rimuovere il vincolo da una risposta che prende una direzione errata. Ricava dai log la distribuzione output_tokens, imposta il limite poco sopra il 95° percentile e gestisci stop_reason: "max_tokens" nel codice, continuando la risposta o riprovando. Rilevare una troncatura costa meno di pagare e scartare una risposta prolissa da 4,000 token. Anche il ragionamento confluisce in output_tokens e conta ai fini di max_tokens. Dimensiona quindi il limite usando gli stessi dati. Sui modelli con ragionamento adattivo, riduci il livello di sforzo se il ragionamento continua a consumare la risposta.
Il routing funziona quando la parte costosa di un passaggio è il volume, non la capacità di giudizio. Mantieni il modello più potente per la decisione e affida la stesura a un modello più economico. Misura prima la versione con routing sul tuo set di valutazione, perché il dato importante è il costo per attività completata. Nel passaggio dell'agente descritto sopra, due tentativi con Haiku 4.5 costano $0.128, contro $0.32 per un tentativo con Opus 5. La differenza di prezzo assorbe quindi uno o due tentativi aggiuntivi. Non assorbe invece una risposta errata che nessuno rileva.
L'elaborazione in batch è l'unica leva che applica uno sconto all'output. Lo sconto è del 50% su entrambi i lati. La maggior parte dei batch viene completata entro un'ora. Qualsiasi attività pianificata è idonea, purché il job reinvii ciò che scade al raggiungimento delle 24 ore.
L'ultima leva è quella che molti trascurano. Frasi come "sii esaustivo" e "spiega il tuo ragionamento" aumentano la lunghezza dell'output in ogni chiamata futura. Sostituiscile con la forma desiderata: "Rispondi in non più di tre frasi" oppure "Restituisci solo l'oggetto JSON, senza testo introduttivo". Un prompt di sistema che aggiunge 300 token a ogni risposta costa cinque volte quanto gli stessi 300 token nel prompt. tenere sotto controllo i costi di un agente in esecuzione tratta l'aspetto del monitoraggio, mentre stabilire se l'API o un abbonamento a tariffa fissa è più economico per il tuo utilizzo è una decisione da prendere prima di passare una settimana a ottimizzare una spesa per token che un abbonamento avrebbe coperto. Per uno sviluppatore, la questione si riduce soprattutto a capire se i $20 al mese di Claude Pro e i relativi limiti di utilizzo coprono il lavoro che altrimenti misureresti a consumo. Se raggiungi già questi limiti durante la sessione, capire quale finestra temporale stai aspettando viene prima di tutto, perché da lì le soluzioni sono un modello più piccolo, un contesto più leggero, crediti di utilizzo aggiuntivi oppure lo spostamento del lavoro sull'API a consumo. Se l'API a consumo risulta la soluzione più economica per quel lavoro, passare a un piano più piccolo o annullarlo non modifica il mese già pagato. Il cambio non comporta quindi costi aggiuntivi. Se il piano con cui stai confrontando Pro è quello di ChatGPT, anziché l'API a consumo, i due livelli di abbonamento con i prezzi affiancati mostrano quale sia più economico per il lavoro di sviluppo. Se la domanda riguarda un team anziché un singolo sviluppatore, considera che Claude Enterprise combina un costo per postazione con token fatturati alle stesse tariffe dell'API, quindi ogni leva descritta in questa pagina resta applicabile alla parte della fattura calcolata a consumo.
FAQ
Perché i token di output costano più dei token di input?
La loro generazione richiede molto più tempo di elaborazione dell'acceleratore per token. Un prompt viene elaborato in un'unica forward pass sull'intero contenuto, quindi una singola lettura dei pesi del modello copre migliaia di token e l'hardware è solitamente limitato dalla velocità delle operazioni di moltiplicazione. Nel decoding ordinario, una risposta viene generata un token alla volta; ogni token richiede una propria forward pass, che legge nuovamente i pesi del modello e la cache KV in crescita. Di conseguenza, l'hardware è solitamente limitato dalla larghezza di banda della memoria. Tecniche come speculative decoding riducono questa differenza, ma non la eliminano. Anthropic applica agli output un prezzo cinque volte superiore a quello degli input nell'intero catalogo attuale, da Haiku 5.5 a Fable 5.1.
Il prompt caching rende più economici i token di output?
No. Il prompt caching si applica solo all'input. Al 27 October 2026, una lettura dalla cache costa 0.1x della tariffa base per l'input nella maggior parte dei modelli (0.05x per Opus 5.5 e Sonnet 5.5, 0.025x per Fable 5.1), mentre la scrittura nella cache costa 1.25x per la durata di 5 minuti o 2x per la durata di 1 ora. L'output viene fatturato alla tariffa piena a ogni chiamata, indipendentemente da ciò che è stato memorizzato nella cache. Per questo il caching modifica sia la struttura sia l'importo della fattura: quando il costo dell'input crolla, l'output diventa la voce su cui intervenire.
Un valore elevato di max_tokens mi costa denaro se la risposta è breve?
No. Ti vengono addebitati i token prodotti effettivamente dal modello, quindi max_tokens è un limite massimo e non una prenotazione. Il valore resta importante perché è l'unico limite rigido per una risposta che continua a crescere senza controllo. Impostalo leggermente al di sopra del 95° percentile di output_tokens rilevato, quindi gestisci stop_reason: "max_tokens" nel codice invece di distribuire una risposta troncata senza segnalarlo.
Come posso determinare il mio rapporto tra token di input e token di output?
Registra input_tokens, output_tokens, cache_read_input_tokens e cache_creation_input_tokens dall'oggetto usage di ogni risposta, quindi dividi i totali calcolati nell'arco di una settimana. Oltre il rapporto di 5 token di input per 1 di output, il costo principale è nel prompt: memorizza nella cache la parte stabile e riduci il resto. Al di sotto di questo rapporto, il costo principale è nella risposta: limita la sua lunghezza e sposta i passaggi che ne generano la maggior parte su un modello più economico o sulla Batch API.