Consumo di token negli LLM: perché una risposta da 4 token ne fattura 217

Fai a GPT-5.6 una domanda di matematica su una riga e l’88% del costo di output è reasoning che non vedrai mai: 10 token visibili, 81 fatturati. E GPT-5.6 è il caso più contenuto. La stessa domanda ha fatturato 217 token di completion per una risposta da 4 token su GLM 5.2, e 1.104 per la risposta identica su Qwen3.7-max. Non è un’anomalia: i modelli di reasoning fatturano così per progetto, ed è solo la prima di diverse classi di token che quasi nessuna dashboard dei costi tiene separate. Questo post analizza un oggetto usage reale, classe per classe, con i numeri misurati.

TL;DR

• Il comportamento di default di GPT-5.6 ha fatturato 81 token per una risposta da 10 token, l’88% reasoning; GLM 5.2 è arrivato al 98% e Qwen3.7-max al 99,3%.
• Claude Sonnet 5 ha fatturato 114 token di thinking per una risposta da 5 token senza che venisse inviato alcun parametro di thinking.
• Cinque famiglie hanno risposto in modo errato senza thinking (399, 400, 427, 466, 467); solo GPT-5.6 ha dato la risposta giusta senza, e ogni esecuzione con reasoning ha detto 401.
• Una scrittura in cache su Claude da 1.181 token, poi riletta, è costata 0,01246 $ e 0,00566 $, in linea esatta con i prezzi di listino.

Cosa abbiamo usato per i test

Ogni misurazione in questo post parte dallo stesso prompt single-turn, inviato a ciascun modello con le sue impostazioni di default, salvo quando una riga indica il contrario:

How many positive integers n <= 1000 are divisible by 3 or 5
but not by 15? Reply with just the number, nothing else.

La risposta corretta è 401 (333 multipli di 3, più 200 multipli di 5, meno 66 contati due volte, dà 467; togli i 66 multipli di 15 e restano 401). L’abbiamo scelta di proposito: la risposta visibile è minima e fissa a 3-4 token su ogni tokenizer, esiste una sola risposta giusta quindi “il thinking è servito?” è verificabile, ed è abbastanza difficile da spingere i modelli a ragionare, che è proprio il comportamento sotto esame.

Le cinque classi di token sulla tua fattura

Un completion moderno fattura fino a cinque classi diverse di token, a quattro tariffe diverse. Un singolo numero piatto di “token usati” nasconde tutto questo.

I nomi dei campi qui sopra seguono il formato OpenAI-compatible. Claude porta le stesse cinque classi con nomi propri: input_tokens e output_tokens, con il thinking riportato in output_tokens_details.thinking_tokens e fatturato come output, e la scrittura in cache ulteriormente divisa per TTL in un oggetto cache_creation (ephemeral_5m_input_tokens a 1.25x, ephemeral_1h_input_tokens a 2x). Stessa anatomia, etichette diverse: questo problema di parsing torna in una sezione più avanti.

Le cinque classi e i loro moltiplicatori di prezzo, etichettati con i nomi dei campi OpenAI-compatible e Anthropic. La cifra dell’88% è la quota di reasoning misurata di GPT-5.6 dall’esempio qui sopra.

Ecco l’oggetto reale dietro il numero in copertina, GPT-5.6 con l’impostazione di default che risponde alla domanda di test:

{
  "prompt_tokens": 38,
  "completion_tokens": 81,
  "total_tokens": 119,
  "prompt_tokens_details": { "cached_tokens": 0, "cache_write_tokens": 0 },
  "completion_tokens_details": { "reasoning_tokens": 71 },
  "cost": 0.000524
}

Qui vive l’aritmetica della fatturazione, e vale la pena farla una volta in modo esplicito. La risposta che hai ricevuto è completion_tokens meno reasoning_tokens: 81 − 71 = 10 token, la parola “401” e la sua formattazione. Gli altri 71 token sono chain-of-thought fatturati alla tariffa di output piena, l’88% del costo di output, e su GPT-5.6 non puoi leggerne nemmeno uno. Ogni cifra di “risposta visibile” in questo post è calcolata allo stesso modo. Il rapporto diventa solo più ripido altrove: GLM 5.2 ha risposto alla stessa domanda con 217 completion token per una risposta di 4 token, quindi un modello di costo che legge completion_tokens come “quello che il modello ha detto” sbaglia di 8x qui e di 54x là.

Il reasoning è il budget, ed è pilotabile

La stessa domanda di una riga su ogni impostazione di thinking accettata dalle tre famiglie pilotabili, un solo gateway, 2026-07-13/14 (le righe sono ordinate dal reasoning minore al maggiore all’interno di ciascuna famiglia; i default flagship delle famiglie rimanenti sono nella prossima sezione):

Quattro cose da leggere onestamente in quella tabella:

• Dove funziona, la leva è ampia. reasoning_effort: none ha risposto correttamente per $0.000062, 8,5 volte meno del default di luna, e su task più difficili abbiamo misurato 20x su GLM 5.2. La scelta del tier fa parte della stessa leva: il flagship di GPT-5.6 ha risposto a questa domanda con zero reasoning per default (prossima sezione), quindi un modello più grande che non ha bisogno di pensare può costare meno di uno più piccolo che invece deve farlo.
• E dove non funziona, è quasi inerte. Quanto la manopola gira è una caratteristica della famiglia: monotona con uno scarto di costo di 5x su Sonnet 5 (da 84 a 249), lieve e disordinata su GPT-5.6, quasi inerte su Qwen3.7-max (low ha comunque speso 974 token di reasoning contro i 1.096 del default), morta su DeepSeek V4 Pro (267 contro 269).
• Le etichette non sono monotone e i default non sono deterministici. Qui high di GPT-5.6 ha speso meno token del suo medium; il low di GLM ha speso più del suo high nel nostro post precedente; Sonnet 5 ha pensato per 114 token su una richiesta che non inviava alcun parametro di thinking; e la stessa richiesta di default di GLM ha speso 213 token di reasoning in un run e 1.312 in un altro, sei volte tanto. Misura l’effetto reale della manopola sul tuo workload; non dedurlo dall’etichetta.
• “Economico e sbagliato” è il fallimento ricorrente. Entrambe le famiglie che qui hanno risposto senza pensare hanno risposto in modo sbagliato (GLM 399, Sonnet 5 467); l’elenco completo delle cinque famiglie è nella prossima sezione. Il reasoning è un budget di correttezza, e se tagliarlo conviene dipende dal task, non dal modello.

La regola pratica: tratta reasoning_tokens come una voce di costo di prima classe. Viene fatturato alla tariffa di output, spesso supera di gran lunga la risposta visibile, e risponde a parametri il cui effetto reale va misurato. Su GPT-5.6 nota che sono cambiate anche le regole di pricing; la guida ai costi di GPT-5.6 copre il premio di scrittura e il requisito della cache-key.

Puoi davvero leggere ciò che hai pagato?

“Separato dalla risposta” non vuol dire sempre “nascosto”, e vale la pena essere precisi sulla differenza. Abbiamo controllato i body delle risposte, non solo l’usage:

• GLM 5.2, DeepSeek, Qwen3.7-max e MiniMax restituiscono per intero il testo del reasoning in un campo reasoning_content accanto alla risposta (qui rispettivamente 3.987, 1.604, 2.509 e 581 caratteri). Uno sviluppatore può leggere ogni token fatturato; l’utente finale lo vede solo se lo mostri tu, e la maggior parte delle applicazioni non lo fa.
• GPT-5.6 trattiene la catena di pensiero grezza; al massimo ottieni un riassunto. La risposta può includere un reasoning.summary scritto dal modello (qui 359 caratteri), ma i 91 token fatturati sono il testo grezzo nascosto, non il riassunto. La cosa più vicina a quel testo è reasoning.encrypted_content: un blob cifrato che puoi rimandare indietro per mantenere la continuità multi-turno, ma che non potrai mai decifrare. I token che hai pagato stanno nel tuo stesso response body, illeggibili.
• Con Claude dipende da come chiedi. La nostra chiamata a Sonnet 5 con adaptive thinking ha restituito un blocco thinking con testo vuoto, mentre thinking_tokens fatturava 114: la prova che ha ragionato, ma niente da leggere. Fable 5 si è comportato allo stesso modo con il suo default sempre attivo (59 fatturati, blocco vuoto). Eppure lo stesso Sonnet 5, chiamato con un reasoning budget esplicito, ha restituito il testo effettivo del ragionamento (73 token fatturati, testo presente). È il modo in cui chiedi a decidere cosa puoi vedere.

Quindi la fatturazione è universale, la visibilità no: ogni famiglia addebita il reasoning alla tariffa di output, e la possibilità di verificare il testo che hai comprato va da “per intero” a “solo riassunto” fino a “un blocco vuoto firmato”.

Quando il testo torna indietro, puoi valutarlo in modo meccanico. La nostra domanda ha cinque risultati intermedi fissi (333, 200, 66, 467, 401), e ogni testo di reasoning restituito li conteneva tutti: GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code e MiniMax M3 hanno prodotto una derivazione completa, mentre le varianti a basso sforzo saltavano un passaggio ciascuna. Per chi ha bisogno del processo e non solo della risposta, la differenza è questa: con reasoning_content puoi verificare ciò che hai pagato; con un riassunto o un blocco vuoto ti tocca fidarti. Invisible Tokens, Visible Bills formalizza questo divario di accountability, e PALACE stima il reasoning nascosto dall’esterno.

La stessa domanda per il modello migliore di ogni famiglia

La tabella sullo steering usava tier specifici per mostrare le manopole. Qui invece c’è l’ultimo flagship di ciascuna famiglia sulla stessa domanda, con le impostazioni di default:

Token di output fatturati per modello di punta per la stessa domanda (tratteggiato arancione = quota di ragionamento; verde = la risposta visibile). L’asterisco su MiniMax: il suo utilizzo non riporta alcun conteggio di ragionamento, quindi la quota è ricostruita per sottrazione, verificata rispetto al testo di ragionamento che restituisce. Il segno di spunta su GPT-5.6 sol contrassegna l’unica esecuzione corretta a ragionamento zero; la croce su Gemini 3.5 Flash contrassegna l’unica risposta errata di un modello di punta (466).

Tutti gli stili di reporting in un unico grafico:

• Sette flagship su otto hanno risposto correttamente, a prezzi enormemente diversi per lo stesso 401. Qwen3.7-max ha speso 1.096 token di reasoning, 22 secondi e $0,0084; il flagship di GPT-5.6 ha speso zero token di reasoning e $0,00031. Un divario di costo di 27x e un divario di latenza di 7x per la stessa identica risposta corretta: è il reasoning budget reso visibile.
• MiniMax restituisce il testo del suo reasoning ma nessun conteggio. 260 token di completion per una risposta visibile di 3 token: la response contiene l’intera derivazione in reasoning_content, ma completion_tokens_details non ha alcuna riga per il reasoning. Quando il conteggio manca, lo si ricostruisce per sottrazione: completion meno i token visibili è il numero di output nascosto.
• Gemini 3.5 Flash è il caso anomalo: l’unico flagship a rispondere in modo errato (466), con 3 token di completion e nessun conteggio di reasoning da nessuna parte. Il fratello 2.5 Flash una volta ha speso 12,5 secondi per produrre un 401 di 3 token senza che nulla nel conto spiegasse il perché, e a un run ripetuto ha risposto 427.
• Gli errori si concentrano nei tier più piccoli e con il thinking disattivato. GLM con il thinking off ha detto 399; Sonnet 5 disabilitato ha detto 467; il vecchio qwen3-max non ha ragionato affatto (3 token) e ha detto 400; Kimi K2.5, che non ha un canale di reasoning, ha ragionato ad alta voce per 144 token visibili fatturati, ha derivato 401 dentro la propria prosa e poi ha concluso 400. Cinque famiglie, cinque risposte sbagliate diverse: 399, 400, 427, 466, 467; solo GPT-5.6 ha risposto correttamente senza reasoning.

Cache token: due direzioni, un fattore 12 di differenza

Il prompt caching divide l’input in due classi aggiuntive, e la differenza di prezzo tra le due è la ragione stessa della divisione: le scritture vengono fatturate a 1,25x rispetto alla tariffa input su Claude (2x con il TTL di 1 ora), le letture a 0,1x. Una coppia misurata di chiamate a Opus 4.8, con un system prompt di 1.181 token in cache, è costata $0,01246 (scrittura) e poi $0,00566 (lettura), entrambe riconciliate con i prezzi di listino fino alla sesta cifra decimale, con l’addebito lato input che cala di circa 11x da una chiamata all’altra. Il punto di questo post è la contabilità: se accorpi cache_creation_input_tokens e cache_read_input_tokens sotto la voce “input token”, non puoi né verificare lo sconto né accorgerti quando smette silenziosamente di applicarsi. E smette più spesso di quanto suggerisca la documentazione: le nostre misurazioni sul caching hanno trovato soglie effettive da 1,4 a 2,4x superiori ai minimi documentati, e la guida al prompt caching copre in dettaglio la meccanica per singolo provider.

Perché la tua stima locale non coincide mai con il conto

Un pattern comune è stimare il costo lato client con una libreria tokenizer e riconciliare in seguito. Tre motivi per cui i numeri non torneranno:

• I tokenizer variano da vendor a vendor. Contare testo destinato a Claude con un tokenizer OpenAI significa misurare con il righello sbagliato; la stessa stringa viene tokenizzata in modo diverso su ogni famiglia.
• Fatturi più della tua richiesta. System prompt e schemi degli strumenti sono input token su ogni richiesta che li include, ed è facile dimenticarli in una stima locale.
• Il reasoning è imprevedibile finché non arriva la risposta. Nessun conteggio lato client può prevedere quanti thinking token spenderà un modello; lo scopri solo dallo usage restituito.

L’oggetto usage restituito è il registro di fatturazione dell’upstream stesso, quindi il contatore accurato più economico è smettere di stimare e leggerlo. Il problema è che ogni provider lo struttura in modo diverso: i soli token in cache compaiono come cached_tokens, prompt_cache_hit_tokens, total_cached_tokens o cache_read_input_tokens a seconda della famiglia.

Nemmeno gli oggetti di dettaglio hanno uno schema fisso. Il riferimento di OpenAI documenta quattro campi lato completion: reasoning_tokens, audio_tokens e la coppia dei Predicted Outputs accepted_prediction_tokens / rejected_prediction_tokens; i rejected prediction token non compaiono mai nell’output ma vengono comunque fatturati come completion token. Lato prompt, la stessa struttura aggiunge text_tokens, audio_tokens e image_tokens accanto a cached_tokens; GPT-5.6 aggiunge cache_write_tokens, e abbiamo visto video_tokens in produzione. I vendor la estendono liberamente: Kimi K2.7 ha restituito un completion_tokens_details.text_tokens non documentato, e Gemini conta thinking token e tool-use token separatamente con nomi propri. Fai il parsing in modo difensivo: tratta i campi di dettaglio sconosciuti come previsti, e non dare mai per scontato che un campo mancante valga zero.

È qui che un gateway si guadagna il suo posto: Synthorai normalizza tutto questo in un unico oggetto, con reasoning_tokens e le due direzioni di cache popolate su OpenAI, Anthropic, Gemini e le famiglie open-weight, così un solo parser copre ogni modello verso cui instradi.

Dal vedere al fermare

Leggere il registro è metà del lavoro; l’altra metà è rendere gli sforamenti impossibili, non solo visibili. I dashboard di fine mese segnalano la sorpresa quando i soldi sono già spesi, e un agente bloccato in un loop di retry non legge i dashboard. Sul gateway, ogni chiave porta con sé una quota con used_quota tracciato e un tetto RPM, applicato al momento della richiesta: una chiave che esaurisce il proprio budget riceve un errore esplicito alla richiesta successiva, non una fattura più salata tre settimane dopo. L’attribuzione per singola richiesta (quale chiave, quale modello, BYOK o fatturazione della piattaforma) torna nello stesso envelope di risposta, quindi il costo per funzionalità è un group-by, non un progetto di ricostruzione.

Dalle misurazioni segue questo ordine delle operazioni: leggi i reasoning_tokens e i campi della cache prima di ottimizzare qualsiasi cosa, imposta il livello di reasoning per ogni task e metti una quota rigida su ogni chiave il cui failure mode è un loop. Per vedere quanto costa al tuo volume un mix specifico di modelli e classi di token, il cost optimizer lo calcola a partire dalle stesse tariffe per-token usate sopra.

← Torna al blog