Costi GPT-5.6: 90% di sconto con prompt caching e reasoning effort

GPT-5.6 interviene contemporaneamente su entrambi i fattori di costo: l’input in cache scende al 10% della tariffa di input, mentre la serie 5.x applicava uno sconto del 50%. Inoltre, dato che il reasoning è attivo per impostazione predefinita, nei nostri 50 test omettere reasoning_effort è costato 1.5x rispetto a impostarlo su none, a parità di risposte. Sul lato input è ora possibile definire esplicitamente fino a quattro cache breakpoint; sul lato output, il livello di effort determina quanto reasoning si paga. Abbiamo misurato entrambi tramite il gateway sui modelli disponibili dal primo giorno: Sol ($5/$30 per 1M token di input/output), Terra ($2.50/$15) e Luna ($1/$6). Tutte le tariffe sono state verificate sul contatore live usage.cost.

TL;DR

• L’input in cache viene fatturato al 10% della tariffa di input: abbiamo misurato $0.10/$0.25/$0.50 per 1M nei tre tier. La serie 5.x applicava uno sconto del 50%.
• I breakpoint consentono il riutilizzo parziale: modificando il blocco successivo a un marker, sono stati rifatturati solo 1,210 token su 2,431.
• I prefissi sotto 1,024 token non vengono mai memorizzati in cache e le richieste ripetute possono non trovare corrispondenza senza alcun errore; nei budget va considerato un hit rate inferiore al 100%.
• Le scritture in cache vengono fatturate a 1.25x sui token scritti; una scrittura mai riletta costa più che non usare la cache.
• Nella nostra matrice di 4 task, omettere reasoning_effort è costato 1.5x rispetto a none, con risposte identiche; impostatelo sempre in modo esplicito.

Misurazioni effettuate il 2026-07-10 tramite il gateway Synthorai, usando chat completions compatibili con OpenAI, il giorno dopo che OpenAI ha annunciato la famiglia. Tutti e tre i modelli sono attivi; i nuovi parametri di caching vengono inoltrati senza modifiche.

Tre tier, una generazione

Lo schema dei nomi è nuovo: il numero indica la generazione, mentre Sol, Terra e Luna sono tier di capacità che sostituiscono i suffissi pro/mini/nano. Tutti e tre condividono una context window da 1M token e un output massimo di 128K. Le tariffe riportate di seguito coincidono esattamente con il valore misurato da usage.cost su conteggi di token noti, compresa la colonna relativa alla cache:

Sol è il modello di punta e il successore di gpt-5.5 a parità di prezzo: il tariffario è identico, $5/$30. Terra e Luna sono i tier ridotti della stessa generazione, rispettivamente a metà e a un quinto del prezzo di Sol. Occupano le fasce che prima usavano i suffissi mini e nano. Per il conteggio dei token, i tre si comportano come un unico modello: hanno restituito conteggi identici per ogni campione inviato.

Come funziona il caching di 5.6 secondo la documentazione

In precedenza, il caching di GPT seguiva un solo meccanismo: l’API rilevava automaticamente i prefissi ripetuti di almeno 1,024 token e fatturava la parte in cache a metà prezzo. Per questo motivo, nel nostro confronto tra provider avevamo classificato GPT come “completamente automatico”. La guida al caching di 5.6 introduce invece due modalità:

{
  "model": "gpt-5.6-luna",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    {
      "role": "system",
      "content": [
        {
          "type": "text",
          "text": "...stable system prompt, 1024+ tokens...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    { "role": "user", "content": "the varying part" }
  ]
}

Le regole principali, sintetizzate dalla guida:

• Un breakpoint segna la fine di un prefisso memorizzato in cache e include quel blocco e tutto ciò che lo precede. La modalità implicit, usata per impostazione predefinita, continua a inserire automaticamente un breakpoint sull’ultimo messaggio; la modalità explicit memorizza solo ciò che viene marcato.
• Sono consentite quattro scritture in cache per richiesta. Il breakpoint automatico della modalità implicit ne occupa una, quindi restano tre slot per i marker espliciti nella modalità predefinita e quattro nella modalità explicit. Nelle richieste successive, i breakpoint dei turni precedenti sono disponibili solo in lettura.
• Resta la soglia minima di 1,024 token: un prefisso marcato ma più corto non viene memorizzato.
• ttl: "30m" garantisce una durata minima, non massima (“almeno 30 minuti… potrebbe essere conservato più a lungo”). Sostituisce prompt_cache_retention, deprecato su 5.6; scompare quindi anche la precedente opzione di conservazione estesa 24h.
• prompt_cache_key serve per ottenere corrispondenze affidabili: la guida consiglia una chiave stabile per tenant o sessione, così da instradare le richieste ripetute verso la stessa cache. Il soft limit è di circa 15 richieste al minuto per chiave. Le cache sono limitate alla vostra organizzazione.
• Le scritture in cache costano 1.25x la tariffa di input su 5.6 e versioni successive e sono riportate nel nuovo campo usage.prompt_tokens_details.cache_write_tokens. Su 5.x e versioni precedenti erano gratuite.

GPT-5.5 e i modelli precedenti rifiutano i nuovi parametri con un errore 400 chiaro (prompt_cache_options is not supported on this model), quindi il rollout va gestito in base alla versione.

La struttura ricorda quella adottata da tempo dal cache_control di Claude: marker sui blocchi di contenuto, quattro breakpoint, un sovrapprezzo in scrittura e uno storico scorrevole disponibile solo in lettura. Cambia il TTL: il minimo garantito di 30 minuti di OpenAI è 6x rispetto ai 5 minuti predefiniti di Claude.

Cosa indicano le misurazioni

La documentazione descrive il comportamento previsto; qui riportiamo ciò che ha restituito il contatore del gateway in ogni test. I record completi sono disponibili nel log dell’esecuzione. Tutti i costi coincidono fino all’ultima cifra con le tariffe del relativo tier.

Tre di questi risultati richiedono qualche dettaglio in più.

Il riutilizzo parziale funziona ed è il motivo principale per adottare i breakpoint. Con un blocco A stabile e una parte finale B sostituita, il contatore ha rifatturato solo la parte finale: 1,212 token letti alla tariffa della cache e 1,210 token scritti per la nuova B con il relativo sovrapprezzo, su un prompt di 2,431 token. Il totale coincide fino all’ultima cifra con il tariffario. È lo stesso comportamento a prefissi stratificati attorno al quale gli utenti Claude organizzano i prompt: system prompt, poi tool, poi documenti, ciascuno con un marker. La modalità automatica di GPT non poteva garantirlo. Un’ultima precisazione: nelle ripetizioni complete, la lunghezza corrispondente a volte si ferma prima del marker. In un test ha riutilizzato 1,897 token su una scrittura di 2,422. Nei budget conviene quindi usare la tariffa scontata, non presumere conteggi di corrispondenza esatti.

La soglia minima e i miss silenziosi sono i principali rischi operativi. Un blocco marcato di 621 token non è stato memorizzato in nessuna delle due richieste. Non è stato restituito alcun errore né altro indizio nell’usage oltre agli zeri. Se il vostro “prefisso stabile” è un system prompt corto, pagate il prezzo pieno senza ricevere alcun avviso. Anche un miss può arrivare senza scrittura e a prezzo pieno, sempre senza segnalazioni. Qualunque sia il percorso delle richieste, l’hit rate è una distribuzione, non una garanzia: leggete cached_tokens in produzione e configurate alert, come facciamo nel nostro audit della cache a cinque minuti.

Il sovrapprezzo di scrittura è effettivo e modifica il punto di pareggio. Su tutti e tre i tier, i token scritti vengono fatturati esattamente a 1.25x la tariffa di input: Luna misura $1.25 per milione di token scritti, Terra $3.125 e Sol $6.25. In ogni test dell’esecuzione finale, i costi coincidevano fino all’ultima cifra. Il sovrapprezzo viene recuperato solo se il prefisso viene riletto: una scrittura che non produce mai un hit costa il 25% in più rispetto a non usare affatto la cache. È lo stesso rischio rilevato per il sovrapprezzo di scrittura di Claude nell’articolo su LangChain. Marcate solo i prefissi che sapete verranno ripetuti, non tutto ciò che sembra stabile.

La soglia minima di 30 minuti ha retto per tutto il periodo che abbiamo testato. Una rilettura con chiave eseguita 15 minuti dopo la scrittura ha trovato l’intero contenuto in cache: 1,313 token su 1,313, fatturati alla tariffa del 10%. È ben oltre il precedente intervallo in memoria di 5-10 minuti. Un secondo test con chiave e lo stesso intervallo ha dato lo stesso risultato. Non abbiamo verificato l’intera durata di 30 minuti.

Confronto con lo stesso workload su GPT-5.5

Il confronto corretto è a parità di prezzo: Sol mantiene esattamente il tariffario di gpt-5.5 ($5/$30) ed è quindi il successore direttamente comparabile, mentre Terra e Luna sono i tier inferiori. Il prezzo nominale è lo stesso, ma le condizioni del caching cambiano radicalmente:

A parità di prezzo nominale, il miglioramento sta nelle condizioni del caching. Un prefisso di 3,000 token costa $0.0075 per chiamata su 5.5 quando la cache automatica produce un hit, contro $0.0015 su Sol con cache calda: 5x in meno per la parte in cache. Il cambiamento più importante riguarda controllo e visibilità. Su 5.5, gli hit dipendono da un rilevamento opaco dei prefissi che non è possibile attivare né sottoporre a debug. Con 5.6 potete invece marcare esattamente cosa memorizzare, instradare le ripetizioni con prompt_cache_key e osservare ogni scrittura in usage. Un miss ora appare come zero in un campo che avete scelto di usare, anziché restare completamente invisibile. A questo si aggiunge la possibilità di scendere di tier: se 5.5 era sovradimensionato per il workload, Terra dimezza l’intero tariffario e Luna lo divide per cinque. Lo stesso prefisso con cache calda scende rispettivamente a $0.00075 e $0.0003. GPT-5.5 conserva un solo vantaggio: la conservazione opzionale di 24 ore. Per un batch giornaliero con un prefisso enorme, il compromesso potrebbe favorire il modello precedente. Nella migrazione va considerato anche il secondo fattore: 5.6 usa il reasoning per impostazione predefinita, quindi spostare un workload da 5.5 senza impostare reasoning_effort aggiunge costi di output pur mantenendo lo stesso tariffario.

Il secondo fattore: reasoning effort

Il caching determina quanto si paga per l’input; reasoning_effort interviene sull’output. I token di reasoning vengono fatturati alla tariffa di output e, a differenza del prefisso, non possono mai essere memorizzati in cache. GPT-5.6 accetta valori da none a xhigh su tutti i tier. L’annuncio introduce anche un livello max per Sol, ma non è disponibile tramite chat completions: su Sol e Terra restituisce 400: 'reasoning_effort' does not support 'max' with this model. Per il percorso API usato da gateway e SDK, xhigh è quindi il massimo effettivo.

Abbiamo eseguito una matrice di 50 chiamate: quattro tipi di task, ossia classificazione di una recensione, estrazione di un campo da una riga di log, problema aritmetico a più passaggi e generazione di un breve frammento di codice. Li abbiamo provati con tutte e sei le impostazioni, da none a xhigh, più il parametro omesso, su Terra e Luna, con una verifica aggiuntiva su Sol. Tutte le 50 risposte erano corrette con ogni impostazione. È cambiato solo il costo. Si tratta di chiamate con output breve, nell’ordine di poche decine di token visibili; bastano quindi alcune decine di token di reasoning, fatturati alla tariffa di output, per dominare il costo totale. La colonna del rapporto confronta il costo dell’intera chiamata:

Emergono tre risultati. Primo: 5.6 si adatta autonomamente. Nei due task più semplici, nessuna impostazione ha consumato token di reasoning, quindi in quei casi il parametro non incide sul costo. Secondo: nei task che sembrano richiedere ragionamento, come matematica e codice, l’impostazione predefinita usa reasoning anche quando non migliora il risultato. Su Luna, omettere il parametro è costato da 2.5x a 3.5x rispetto a none per matematica e codice. Lo stesso è avvenuto per il task matematico su Terra, mentre nel test di generazione del codice Terra non ha usato reasoning con il valore predefinito. Le risposte erano identiche e, sull’intera griglia Terra e Luna, il costo totale è stato 1.5x. Terzo: i livelli intermedi, non mostrati nella tabella, si comportano più come indicazioni che come una scala prevedibile. Nel test matematico su Terra sono stati consumati 19 token di reasoning con low, zero con medium, 21 con high e di nuovo zero con xhigh. Nel test di codice su Luna, xhigh ne ha consumati 101 contro i 41 di high. I nomi esprimono un’intenzione, non un budget, come avevamo già misurato su GLM 5.2.

Inviate reasoning_effort esplicitamente in ogni chiamata e usate none come valore predefinito per classificazione, estrazione, routing e trasformazioni brevi. Aumentatelo solo nei punti in cui gli eval dimostrano che un livello superiore cambia i risultati, non perché il task sembra difficile. I nostri quattro casi rappresentano workload API con output breve. Un lavoro a più passaggi realmente complesso può giustificare il costo del reasoning, ma deve emergere dalle misurazioni.

I due fattori si combinano. Con un prefisso già in cache, il lato input di una chiamata Luna costa un decimo del prezzo di listino, mentre nei task brevi il reasoning predefinito diventa la voce di costo più alta. La chiamata matematica su Luna è costata in totale $0.00007 con none e $0.00025 omettendo il parametro: il solo reasoning predefinito ha aggiunto $0.00018, oltre il doppio dell’intero costo della chiamata controllata. Usare la cache senza fissare l’effort fa riemergere i costi sul lato opposto.

Raccomandazioni per tipo di workload

La decisione dipende ora da più fattori. Queste sono le indicazioni che diamo ai clienti del gateway:

Indipendentemente dal workload, inviate un prompt_cache_key stabile per tenant o sessione: secondo la documentazione, la chiave è alla base di corrispondenze affidabili. Mantenete ogni livello marcato sopra la soglia di 1,024 token e monitorate cached_tokens, perché i miss silenziosi esistono. Le cache sono specifiche del modello: un test A/B tra tier parte da cache vuota su entrambi. Nello stesso commit, impostate anche l’altro fattore: fissate reasoning_effort in base alla matrice precedente, usando none salvo diversa indicazione degli eval.

Nella scelta del tier, lo sconto del 90% incide sui calcoli più del tier stesso. Un workload che riutilizza un prefisso di 3,000 token paga circa $0.30 ogni mille chiamate su Luna con cache calda e $1.50 su Sol. La differenza tra i tier sulla parte in cache è inferiore a quella sui token di output. Scegliete quindi il tier in base a qualità e prezzo dell’output, poi usate la cache per ridurre il costo dell’input. Per chi arriva da gpt-5.5, Sol è l’upgrade diretto allo stesso tariffario, con letture dalla cache 5x più economiche e controllo esplicito su quando avvengono. Passate a Terra o Luna se gli eval confermano che il tier inferiore mantiene la qualità: il tariffario viene rispettivamente dimezzato o diviso per cinque.

Il tokenizer non è cambiato

I nostri 24 campioni, composti da un testo narrativo in nove lingue, versioni tecniche e giornalistiche in sei lingue, una funzione Python e una tool call JSON, hanno prodotto conteggi identici tra GPT-5.5, Sol, Terra e Luna in ogni confronto completato. I budget di token e le stime della soglia minima della cache calibrati su 5.5 restano validi senza modifiche. Il comportamento tra lingue descritto nel nostro articolo sui tokenizer per lingua si applica invariato a 5.6.

In sintesi

• Il passaggio dello sconto sulla cache dal 50% al 90%, insieme al TTL minimo garantito di 30 minuti, è il vero taglio dei prezzi di questa release. I prezzi dei tier fanno notizia, ma le nuove condizioni del caching incidono di più sui costi reali.
• Usate breakpoint espliciti per i prompt stratificati: il riutilizzo parziale è stato misurato, non è solo teorico, e il modello mentale di Claude si applica direttamente.
• Rispettate la soglia di 1,024 token, inviate un prompt_cache_key e monitorate cached_tokens: esistono sia i miss silenziosi sia i casi, altrettanto silenziosi, in cui il contenuto non viene memorizzato affatto.
• Inviate reasoning_effort esplicitamente e usate none come valore predefinito: nella nostra matrice, il valore predefinito non controllato è costato 1.5x, fino a 3.5x su singoli task, a parità di risposte.
• xhigh è il massimo disponibile (max restituisce 400 tramite chat completions); non serve ricalibrare il tokenizer rispetto a 5.5.

FAQ

GPT-5.6 supporta il prompt caching esplicito come Claude? Sì. Si usa prompt_cache_options: {"mode": "explicit"} insieme ai marker prompt_cache_breakpoint sui blocchi di contenuto, con un massimo di quattro scritture per richiesta. In modalità implicit sono tre, perché il breakpoint automatico occupa uno slot. Nei test tramite un gateway compatibile con OpenAI, un prefisso marcato di 3,012 token è stato scritto alla prima chiamata e riletto interamente alla tariffa della cache nella seconda.

Quanto costa l’input in cache su GPT-5.6? Il 10% della tariffa di input, misurato su tutti e tre i tier: $0.10 per milione su Luna, $0.25 su Terra e $0.50 su Sol. GPT-5.x fatturava i token in cache al 50% dell’input, quindi su 5.6 la tariffa è 5x inferiore.

Il caching di GPT-5.6 è migliore di quello di GPT-5.5? Sì, per profondità dello sconto e controllo: tariffa del 10% anziché del 50%, quattro breakpoint espliciti anziché un rilevamento esclusivamente automatico che non è possibile attivare né sottoporre a debug, e un minimo di 30 minuti con chiave anziché 5-10 minuti best effort. L’unico vantaggio rimasto a 5.5 è l’opzione di conservazione per 24 ore, rimossa in 5.6.

Quanto dura la cache di GPT-5.6? La documentazione garantisce almeno 30 minuti; ttl: "30m" è l’unico valore accettato, ma la cache potrebbe durare più a lungo. L’opzione sostituisce il deprecato prompt_cache_retention, compreso il precedente tier esteso di 24 ore. Nei nostri test, le riletture con chiave effettuate 15 minuti dopo la scrittura hanno riutilizzato l’intero contenuto. Non abbiamo verificato l’intera durata di 30 minuti.

È necessario usare prompt_cache_key? Inviatelo: secondo la documentazione, una chiave stabile per tenant o sessione è alla base di corrispondenze affidabili su 5.6, con un soft limit di circa 15 richieste al minuto per chiave. Includerla non costa nulla. Insieme al monitoraggio di cached_tokens, consente di verificare che lo sconto venga effettivamente applicato.

Quanto incide reasoning_effort sul costo di GPT-5.6? Nella nostra matrice di 50 chiamate, composta da quattro tipi di task e sei impostazioni su Terra e Luna, ogni configurazione ha prodotto risposte corrette. Nel complesso, omettere il parametro è costato 1.5x rispetto a none, con un massimo di 3.5x nel task aritmetico. Nei task semplici, classificazione ed estrazione, nessuna impostazione ha consumato token di reasoning. Impostate none e aumentate il livello solo in base agli eval.

Il massimo reasoning effort è disponibile su GPT-5.6 Sol? Non tramite chat completions. Le richieste con reasoning_effort: "max" restituiscono un errore 400 che elenca i valori da none a xhigh, sia su Sol sia su Terra.

Quale tier GPT-5.6 dovrebbe usare un workload API? Sol è il successore di gpt-5.5 a parità di prezzo: stesso tariffario $5/$30 e letture dalla cache 5x più economiche. Terra e Luna sono i tier inferiori, rispettivamente a metà e a un quinto del prezzo. Quando il prefisso è stabile e associato a una chiave, lo sconto del 90% riduce fortemente il costo dell’input. Scendete quindi fino al tier consentito dagli eval sulla qualità dell’output e lasciate che il tier determini il costo dell’output.

Altre guide di questa serie basate su costi misurati: costo della trascrizione audio su sette modelli ASR, costo della generazione di immagini e prezzi della voce GPT Realtime.

← Torna al blog