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

Basta porre a GPT-5.6 una domanda di matematica da una riga: l’88% del costo dell’output deriva da reasoning che non vedrai mai. La risposta visibile occupa 10 token, ma ne vengono fatturati 81. E GPT-5.6 è il caso meno estremo. Per la stessa domanda, GLM 5.2 ha fatturato 217 completion token a fronte di una risposta di 4 token; Qwen3.7-max ne ha fatturati 1,104 per una risposta identica. Non è un’anomalia: è il modo in cui i reasoning model fatturano per design. Ed è solo la prima delle diverse classi di token che la maggior parte delle dashboard dei costi non distingue. In questo articolo analizziamo un oggetto usage reale, classe per classe, usando dati misurati.

TL;DR

• Con le impostazioni predefinite, GPT-5.6 ha fatturato 81 token per una risposta di 10 token, di cui l’88% per il reasoning; GLM 5.2 ha raggiunto il 98% e Qwen3.7-max il 99.3%.
• Claude Sonnet 5 ha fatturato 114 thinking token per una risposta di 5 token, senza che la richiesta includesse alcun parametro di thinking.
• Senza thinking, cinque famiglie hanno risposto in modo errato (399, 400, 427, 466, 467); solo GPT-5.6 ha dato la risposta corretta senza reasoning, mentre tutte le esecuzioni con reasoning hanno risposto 401.
• La scrittura e la successiva lettura di una cache Claude da 1,181 token sono costate rispettivamente $0.01246 e $0.00566, in perfetto accordo con i prezzi di listino.

Configurazione del test

Tutte le misure riportate in questo articolo provengono dallo stesso prompt single-turn, inviato a ogni modello con le impostazioni predefinite, salvo diversa indicazione nella relativa riga:

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: ci sono 333 multipli di 3 e 200 multipli di 5; sottraendo i 66 conteggiati due volte si ottiene 467, quindi eliminando i 66 multipli di 15 ne restano 401. Abbiamo scelto questa domanda apposta: la risposta visibile è minima e occupa sempre 3-4 token, indipendentemente dal tokenizer; esiste una sola risposta corretta, quindi è possibile verificare se il thinking sia servito; inoltre, la domanda è abbastanza difficile da indurre i modelli a ragionare, cioè proprio il comportamento che vogliamo analizzare.

Le cinque classi di token in fattura

Una completion moderna può fatturare fino a cinque classi di token, applicando quattro tariffe diverse. Un unico valore aggregato per i “token utilizzati” nasconde tutta questa struttura.

I nomi dei campi riportati sopra seguono il formato compatibile con OpenAI. Claude rappresenta le stesse cinque classi con nomi propri: input_tokens e output_tokens; il thinking compare in output_tokens_details.thinking_tokens e viene fatturato come output. La scrittura in cache è ulteriormente suddivisa per TTL nell’oggetto cache_creation: ephemeral_5m_input_tokens a 1.25x ed ephemeral_1h_input_tokens a 2x. La struttura è la stessa, cambiano solo le etichette. Torneremo più avanti sul problema del parsing.

Le cinque classi e i relativi moltiplicatori di prezzo, con i nomi dei campi compatibili con OpenAI e Anthropic. Il valore dell’88% corrisponde alla quota di reasoning misurata per GPT-5.6 nell’esempio precedente.

Questo è l’oggetto reale a cui si riferisce il titolo: GPT-5.6, con le impostazioni predefinite, risponde alla domanda del 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 si trova l’intero calcolo della fatturazione. Conviene farlo esplicitamente almeno una volta. La risposta ricevuta corrisponde a completion_tokens meno reasoning_tokens: 81 − 71 = 10 token, cioè la parola “401” e la relativa formattazione. Gli altri 71 token sono chain-of-thought fatturata alla tariffa piena dell’output. Rappresentano l’88% del costo dell’output e, su GPT-5.6, non è possibile leggerne nemmeno uno. Tutti i valori relativi alla “risposta visibile” in questo articolo sono calcolati nello stesso modo. Con altri modelli il rapporto diventa ancora più estremo: GLM 5.2 ha risposto alla stessa domanda con 217 completion token per una risposta di 4 token. Un modello di costo che interpreta completion_tokens come “ciò che ha detto il modello” sbaglia di 8x nel primo caso e di 54x nel secondo.

Il reasoning è il vero budget, e si può controllare

Abbiamo inviato la stessa domanda da una riga usando tutte le impostazioni di thinking accettate dalle tre famiglie configurabili, tramite lo stesso gateway, il 2026-07-13/14. Le righe sono ordinate, per ciascuna famiglia, dalla quantità minore a quella maggiore di reasoning; le impostazioni predefinite dei modelli di punta delle altre famiglie sono riportate nella sezione successiva.

Da questa tabella emergono quattro punti:

• Dove funziona, la leva è molto potente. Con reasoning_effort: none, luna ha risposto correttamente spendendo $0.000062, cioè 8.5x meno rispetto alle impostazioni predefinite. Su task più difficili abbiamo misurato un risparmio di 20x con GLM 5.2. Anche la scelta del tier agisce sulla stessa leva: il modello di punta GPT-5.6 ha risposto senza reasoning con le impostazioni predefinite, come mostra la sezione successiva. Un modello più grande che non ha bisogno di pensare può quindi costare meno di uno più piccolo che usa il reasoning.
• Dove non funziona, l’effetto è quasi nullo. L’ampiezza della regolazione dipende dalla famiglia: su Sonnet 5 è monotona e produce una variazione di costo di 5x, passando da 84 a 249 token; su GPT-5.6 è limitata e non ordinata; su Qwen3.7-max è quasi irrilevante, perché low ha comunque consumato 974 reasoning token contro i 1,096 delle impostazioni predefinite; su DeepSeek V4 Pro non produce praticamente alcun effetto, con 267 contro 269.
• Le etichette non seguono sempre un ordine monotono e le impostazioni predefinite non sono deterministiche. In questo test, high su GPT-5.6 ha consumato meno token di medium; in un articolo precedente, low su GLM ha consumato più di high; Sonnet 5 ha usato 114 thinking token in una richiesta priva di qualsiasi parametro di thinking; inoltre, due richieste GLM identiche con le impostazioni predefinite hanno consumato rispettivamente 213 e 1,312 reasoning token, una differenza di sei volte. Bisogna misurare l’effetto reale sul proprio workload, non dedurlo dal nome dell’impostazione.
• Risparmiare ottenendo la risposta sbagliata è un problema ricorrente. Entrambe le famiglie testate senza thinking hanno risposto in modo errato: GLM ha restituito 399, Sonnet 5 ha restituito 467. La sezione successiva riporta i risultati di tutte e cinque le famiglie. Il reasoning è un budget di correttezza: la convenienza di ridurlo dipende dal task, non dal modello.

La regola pratica è semplice: reasoning_tokens va trattato come una voce di costo di primo livello. Viene fatturato alla tariffa dell’output, spesso supera di gran lunga la risposta visibile e dipende da parametri il cui effetto reale deve essere misurato. Per GPT-5.6 sono cambiate anche le regole tariffarie: la guida ai costi di GPT-5.6 descrive il sovrapprezzo in scrittura e il requisito della cache key.

Puoi davvero leggere ciò per cui hai pagato?

“Separato dalla risposta” non significa necessariamente nascosto. Abbiamo controllato il corpo delle risposte, non solo i dati di utilizzo:

• GLM 5.2, DeepSeek, Qwen3.7-max e MiniMax restituiscono il testo completo del reasoning in un campo reasoning_content accanto alla risposta: rispettivamente 3,987, 1,604, 2,509 e 581 caratteri in questo test. Lo sviluppatore può leggere ogni token fatturato; gli utenti finali lo vedono solo se l’applicazione lo mostra, cosa che in genere non avviene.
• GPT-5.6 non espone la chain-of-thought originale; al massimo restituisce un riepilogo. La risposta può contenere un reasoning.summary scritto dal modello, lungo 359 caratteri in questo caso, ma i 91 token fatturati appartengono al testo originale nascosto, non al riepilogo. Il contenuto più vicino a quel testo è reasoning.encrypted_content: un blob cifrato che può essere reinviato per mantenere la continuità tra più turni, ma non può essere decifrato. I token acquistati si trovano quindi nel corpo della risposta, ma restano illeggibili.
• Con Claude dipende dalla modalità della richiesta. La chiamata a Sonnet 5 con adaptive thinking ha restituito un blocco thinking vuoto, pur fatturando 114 thinking_tokens: sappiamo che il modello ha ragionato, ma non possiamo leggere nulla. Fable 5 si è comportato allo stesso modo con le impostazioni predefinite e thinking sempre attivo: 59 token fatturati e blocco vuoto. Lo stesso Sonnet 5, chiamato con un budget di reasoning esplicito, ha invece restituito il testo effettivo del thinking: 73 token fatturati e testo presente. La modalità della richiesta determina quindi ciò che puoi vedere.

La regola di fatturazione è universale, ma la visibilità no: tutte le famiglie applicano la tariffa di output al reasoning. La possibilità di verificare il testo acquistato varia invece da “completo” a “solo riepilogo”, fino a “blocco vuoto firmato”.

Quando il testo viene restituito, è possibile valutarlo automaticamente. La domanda del test ha cinque risultati intermedi fissi: 333, 200, 66, 467 e 401. Tutti i testi di reasoning restituiti li contenevano: GLM 5.2, DeepSeek V4 Pro, Qwen3.7-max, Kimi K2.7 Code e MiniMax M3 hanno prodotto una derivazione completa, mentre le varianti low-effort hanno omesso un passaggio ciascuna. Per chi ha bisogno del procedimento e non solo della risposta, la distinzione è questa: con reasoning_content puoi verificare ciò per cui hai pagato; con un riepilogo o un blocco vuoto devi fidarti. Token invisibili, fatture visibili formalizza questo problema di accountability, mentre PALACE stima dall’esterno il reasoning nascosto.

La stessa domanda al modello migliore di ogni famiglia

La tabella precedente usa tier specifici per mostrare l’effetto delle diverse impostazioni. Qui confrontiamo invece il modello di punta più recente di ogni famiglia sulla stessa domanda, con le impostazioni predefinite:

Token di output fatturati da ciascun modello di punta per la stessa domanda: l’arancione tratteggiato rappresenta la quota di reasoning, il verde la risposta visibile. L’asterisco su MiniMax indica che i dati di utilizzo non contengono il conteggio del reasoning, quindi la quota è stata ricostruita per sottrazione e verificata rispetto al testo di reasoning restituito. Il segno di spunta su GPT-5.6 sol indica l’unica esecuzione corretta senza reasoning; la croce su Gemini 3.5 Flash indica l’unica risposta errata tra i modelli di punta, 466.

Il grafico raccoglie tutti i tipi di reporting:

• Sette modelli di punta su otto hanno risposto correttamente, con costi molto diversi per lo stesso 401. Qwen3.7-max ha consumato 1,096 reasoning token, impiegato 22 secondi e speso $0.0084; il modello di punta GPT-5.6 non ha usato reasoning ed è costato $0.00031. A parità di risposta corretta, il costo varia di 27x e la latenza di 7x: è l’effetto diretto del budget di reasoning.
• MiniMax restituisce il testo del reasoning, ma non il conteggio. Ha fatturato 260 completion token per una risposta visibile di 3 token. La risposta contiene l’intera derivazione in reasoning_content, ma completion_tokens_details non espone una voce dedicata al reasoning. Quando il conteggio manca, è possibile ricostruirlo per sottrazione: completion token meno token visibili equivale al conteggio dell’output nascosto.
• Gemini 3.5 Flash è l’eccezione: è l’unico modello di punta ad aver risposto in modo errato, 466, con 3 completion token e nessun conteggio di reasoning. Il modello affine 2.5 Flash ha impiegato una volta 12.5 secondi per produrre un 401 di 3 token, senza che la fattura spiegasse il motivo; in una seconda esecuzione ha risposto 427.
• Le risposte errate si concentrano nei tier più piccoli e nelle configurazioni con thinking disattivato. GLM senza thinking ha risposto 399; Sonnet 5 con thinking disattivato ha risposto 467; il precedente qwen3-max non ha usato reasoning, ha prodotto 3 token e ha risposto 400; Kimi K2.5, privo di un canale di reasoning, ha ragionato esplicitamente in 144 token visibili e fatturati, ha ricavato 401 nel proprio testo e poi ha concluso 400. Cinque famiglie hanno prodotto cinque risposte errate diverse: 399, 400, 427, 466 e 467. Solo GPT-5.6 ha risposto correttamente senza reasoning.

Token della cache: due direzioni con una differenza di 12x

Il prompt caching divide l’input in altre due classi. La differenza di prezzo tra le due spiega perché questa distinzione sia necessaria: su Claude, le scritture vengono fatturate a 1.25x la tariffa di input, oppure a 2x con TTL di 1 ora; le letture costano 0.1x. Due chiamate misurate a Opus 4.8 con un system prompt in cache da 1,181 token sono costate $0.01246 per la scrittura e $0.00566 per la lettura. Entrambi i valori coincidono con i prezzi di listino fino alla sesta cifra decimale, mentre il costo lato input è diminuito di circa 11x tra la prima e la seconda chiamata. Ai fini di questo articolo conta soprattutto la contabilizzazione: aggregando cache_creation_input_tokens e cache_read_input_tokens sotto la voce generica “input token”, non è possibile né verificare lo sconto né accorgersi quando smette di essere applicato senza alcun avviso. Succede più spesso di quanto suggerisca la documentazione: le nostre misure sul caching hanno rilevato soglie effettive da 1.4 a 2.4x superiori ai minimi documentati. La guida al prompt caching descrive nel dettaglio il funzionamento di ogni provider.

Perché la stima locale non coincide mai con la fattura

Una pratica comune consiste nello stimare il costo lato client con una libreria di tokenizzazione, per poi riconciliare i dati in seguito. I valori non coincidono per tre motivi:

• Ogni vendor usa tokenizer diversi. Contare il testo destinato a Claude con un tokenizer OpenAI significa usare lo strumento sbagliato: la stessa stringa viene tokenizzata diversamente da ogni famiglia.
• La fattura include più del messaggio. I system prompt e gli schemi dei tool vengono conteggiati come input token in ogni richiesta che li include, ma è facile ometterli da una stima locale.
• Il reasoning è imprevedibile fino alla risposta. Nessun conteggio lato client può prevedere quanti thinking token consumerà un modello. Il dato diventa disponibile solo nel campo usage restituito.

L’oggetto usage restituito è il record di fatturazione prodotto direttamente dall’upstream. Il modo più economico per ottenere un conteggio accurato è smettere di fare stime e leggere quei dati. Il problema è che ogni provider usa una struttura diversa: a seconda della famiglia, i soli token in cache possono comparire come cached_tokens, prompt_cache_hit_tokens, total_cached_tokens o cache_read_input_tokens.

Nemmeno gli oggetti di dettaglio hanno uno schema fisso. La documentazione di OpenAI definisce quattro campi lato completion: reasoning_tokens, audio_tokens e la coppia 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, mentre in produzione abbiamo visto anche video_tokens. I vendor estendono liberamente questi oggetti: Kimi K2.7 ha restituito un campo non documentato, completion_tokens_details.text_tokens, mentre Gemini conteggia separatamente i token di thinking e quelli di utilizzo dei tool, con nomi propri. Il parser deve essere difensivo: i campi di dettaglio sconosciuti sono normali e un campo assente non equivale mai automaticamente a zero. I campi audio seguono inoltre una logica economica distinta: abbiamo misurato separatamente il costo del riconoscimento vocale per minuto audio fatturato su sette modelli ASR dedicati.

È qui che un gateway diventa utile: Synthorai normalizza tutte queste varianti in un unico oggetto, popolando reasoning_tokens e le due direzioni della cache per OpenAI, Anthropic, Gemini e le famiglie open-weight. Un solo parser può quindi gestire tutti i modelli verso cui viene instradato il traffico.

Dall’osservazione al controllo

Leggere i dati di fatturazione risolve solo metà del problema. L’altra metà consiste nel rendere impossibili gli sforamenti, invece di limitarsi a osservarli. Le dashboard mensili segnalano la sorpresa quando il denaro è già stato speso, e un agent bloccato in un ciclo di retry non consulta le dashboard. Nel gateway, ogni chiave ha una quota, con used_quota monitorata e un limite RPM applicato al momento della richiesta. Quando una chiave esaurisce il budget, la richiesta successiva riceve un errore esplicito, non una fattura più alta tre settimane dopo. L’attribuzione per richiesta, cioè quale chiave, quale modello e fatturazione BYOK o della piattaforma, viene restituita nello stesso envelope della risposta. Il costo per feature si ottiene quindi con un group-by, senza doverlo ricostruire.

I dati misurati indicano una sequenza operativa precisa: prima di ottimizzare, leggere reasoning_tokens e i campi della cache; configurare poi il livello di reasoning per ogni task; infine applicare una quota rigida a ogni chiave il cui failure mode può generare un ciclo. Per calcolare il costo di una combinazione specifica di modelli e classi di token sul proprio volume, l’ottimizzatore dei costi usa le stesse tariffe per token impiegate sopra.

← Torna al blog