Come calcolare il consumo di token nell’API Responses: input, output, cache e ragionamento

Dopo aver ridotto il prompt, verificate i risparmi usando usage di ogni risposta e il costo dell’intera attività. Una risposta breve può comportare un consumo notevole di ragionamento, mentre la continuazione di una conversazione può conteggiare di nuovo la cronologia. Per controllare il budget, suddividete il volume di token, le categorie tariffarie e il numero di chiamate necessarie per ottenere il risultato.

Quattro contatori e le loro relazioni

Nell’esempio dell’oggetto usage, OpenAI mostra input, output e il dettaglio di entrambi i contatori. Leggeteli così:

• input_tokens — volume totale di token in input per questa chiamata, compreso il contesto utilizzato per continuare la conversazione.
• input_tokens_details.cached_tokens — parte dell’input gestita dalla cache. È già inclusa in input_tokens.
• output_tokens — volume totale dei token generati, compreso il ragionamento.
• output_tokens_details.reasoning_tokens — parte dell’output impiegata per il ragionamento.

I token di reasoning sono già inclusi in output_tokens; non vanno sommati di nuovo all’output. OpenAI li conteggia alla tariffa dei token di output. Analogamente, aggiungere cached_tokens all’input significa conteggiare due volte la stessa parte della richiesta. Per il volume totale, usate total_tokens oppure la somma input_tokens + output_tokens.

Costo: suddividete l’input per categoria

Nell’attuale pagina dei prezzi sono indicati separatamente l’input standard, l’input memorizzato nella cache, la scrittura nella cache e l’output. Scegliete le tariffe corrispondenti al modello effettivo, alla modalità di elaborazione e alla lunghezza del contesto applicabile. Conservate i valori esatti in una configurazione di calcolo soggetta a versionamento.

Un dettaglio importante dell’attuale documentazione della cache: per GPT-5.6 e i modelli più recenti viene conteggiato input_tokens_details.cache_write_tokens. Se il vostro schema prevede un addebito separato per la scrittura nella cache, sottraete questa categoria dall’input standard e applicate la relativa tariffa.

I = input_tokens
C = input_tokens_details.cached_tokens
W = input_tokens_details.cache_write_tokens
O = output_tokens

ordinary_input = I - C - W
cost = ((I - C - W) * P_input
        + C * P_cached
        + W * P_write
        + O * P_output) / 1_000_000

Qui i prezzi sono espressi per milione di token; per uno schema senza una categoria separata per la scrittura, usate W = 0. La formula copre le categorie di token elencate. Aggiungete gli strumenti a pagamento come voci separate, in base alle relative condizioni tariffarie.

Esempio ipotetico: input — 4000, input memorizzato nella cache — 3000, scrittura nella cache — 500, output — 1000, di cui 600 di reasoning. Si ottengono 500 token di input standard e 5000 token totali. L’output viene addebitato per un volume di 1000 token; il valore 600 viene conservato a fini diagnostici.

La continuazione della conversazione consuma di nuovo input

Quando gestisce manualmente la cronologia, l’applicazione invia i messaggi precedenti insieme al nuovo input. I messaggi inclusi nella richiesta successiva diventano di nuovo contesto in input. Perciò, misurare soltanto l’ultimo messaggio dell’utente non tiene conto del consumo dovuto alla cronologia.

Con previous_response_id, l’applicazione trasmette un riferimento alla risposta precedente e l’API collega il contesto. Secondo le regole di conteggio delle continuazioni, i token di input precedenti della catena vengono addebitati di nuovo come input. La cache può modificare la categoria tariffaria di una parte di questo input; controllate l’effettivo utilizzo della cache in cached_tokens di ogni risposta.

Come verificare il risultato dell’ottimizzazione

1. Salvate un campione di riferimento. Confrontate attività identiche, lo stesso modello, gli stessi criteri di riuscita e lunghezze di conversazione comparabili.
2. Registrate ogni chiamata. Annotate gli identificativi della risposta e dell’attività, il modello, le impostazioni di reasoning, lo stato, la latenza e l’intero usage. Conservate la versione del prompt e della configurazione tariffaria.
3. Somma i costi dell’attività. Includete tutte le chiamate e le risposte ottenute nei tentativi ripetuti. La metrica principale è il costo di un’attività completata con successo.
4. Distinguete le cause delle variazioni. Monitorate input standard, lettura e scrittura della cache, output e quota di reasoning. Per la quota aggregata di cache, dividete la somma di C per la somma di I.
5. Verificate la qualità e la coda della distribuzione. Oltre al costo medio, confrontate il p95, il numero di tentativi e la percentuale di attività riuscite.

Il parametro max_output_tokens limita la generazione insieme al reasoning. Quando il limite viene raggiunto, la risposta può ricevere lo stato incomplete, anche senza testo visibile ma con consumo di token. Tenete conto di queste risposte quando verificate i risparmi: l’ottimizzazione ha raggiunto l’obiettivo quando attività comparabili vengono completate con successo a un costo totale inferiore.