Guida ai costi di GPT-5.6: prompt caching scontato al 90%, reasoning effort

GPT-5.6 sposta entrambe le leve di costo insieme: l’input in cache scende al 10% della tariffa di input (5.x lo scontava del 50%), e con il reasoning attivo di default, non inviare reasoning_effort è costato 1,5 volte di più rispetto a fissarlo su none, con risposte identiche, nella nostra matrice di 50 chiamate. Lato input ora puoi fissare esplicitamente fino a quattro cache breakpoint; lato output è la manopola effort a decidere quanto ragionamento paghi. Abbiamo misurato entrambe le leve attraverso il gateway sui modelli disponibili al lancio: Sol ($5/$30 per 1M di token in/out), Terra ($2,50/$15) e Luna ($1/$6), con ogni tariffa verificata contro il misuratore usage.cost in tempo reale.

TL;DR

• L’input in cache viene fatturato al 10% della tariffa di input, misurato a $0,10/$0,25/$0,50 per 1M nei vari tier; 5.x lo scontava del 50%.
• I breakpoint offrono un riuso parziale: cambiare il blocco dopo un marker ha rifatturato solo 1.210 dei 2.431 token.
• I prefissi sotto i 1.024 token non vanno mai in cache e i repeat possono mancare silenziosamente; considera hit rate sotto il 100%.
• Le scritture in cache vengono fatturate a 1,25x sui token scritti; una scrittura mai letta costa più che non usare la cache.
• Omettere reasoning_effort è costato 1,5 volte di più rispetto a none su una matrice di 4 task, con risposte identiche; fissalo esplicitamente.

Misurato il 2026-07-10 attraverso il gateway Synthorai (chat completions compatibili con OpenAI), un giorno dopo che OpenAI ha annunciato la famiglia. Tutti e tre i modelli sono disponibili; i nuovi parametri di caching passano invariati.

Tre tier, una generazione

Lo schema di naming è nuovo: il numero è la generazione, e Sol, Terra e Luna sono tier di capacità che sostituiscono i suffissi pro/mini/nano. Tutti e tre condividono una context window da 1M di token e un output massimo di 128K. Ogni tariffa qui sotto quadra esattamente con usage.cost misurato su conteggi di token noti, inclusa la colonna della cache:

Sol è il modello di punta e il successore a parità di prezzo di gpt-5.5: il listino è identico, a $5/$30. Terra e Luna sono i tier ridimensionati della stessa generazione, a metà e a un quinto del prezzo di Sol, e prendono il posto che occupavano i suffissi mini e nano. Per il conteggio dei token i tre sono un unico modello: hanno restituito conteggi identici su ogni campione che abbiamo inviato.

Come funziona il caching in 5.6, secondo la documentazione

Il caching di GPT era un comportamento unico: l’API rilevava da sola i prefissi ripetuti da 1.024+ token e fatturava la quota in cache a metà prezzo. Nel nostro confronto tra provider la colonna GPT finiva sotto “completamente automatico” proprio per questo motivo. La guida al caching di 5.6 la sostituisce con un design a 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 che contano, riassunte dalla guida:

• Un breakpoint segna la fine di un prefisso in cache, coprendo quel blocco e tutto ciò che lo precede. La modalità implicit (quella di default) piazza comunque un breakpoint automatico sull’ultimo messaggio; la modalità explicit mette in cache solo ciò che marchi.
• Quattro scritture in cache per richiesta, e il breakpoint automatico della modalità implicit ne consuma una. Quindi i marker espliciti hanno tre slot nella modalità di default e quattro in modalità explicit. I breakpoint dei turni di conversazione precedenti sono in sola lettura nelle richieste successive.
• Il limite minimo di 1.024 token resta: un prefisso marcato sotto quella soglia non viene messo in cache.
• ttl: "30m" è una durata minima garantita, non un tetto massimo (“at least 30 minutes… may retain it longer”). Sostituisce prompt_cache_retention, deprecato su 5.6, e con esso sparisce anche la vecchia opzione di ritenzione estesa a 24h.
• prompt_cache_key è il modo per ottenere un matching affidabile: la guida consiglia una chiave stabile per tenant o sessione, così da instradare le richieste ripetute sulla stessa cache, con un soft limit intorno alle 15 richieste al minuto per chiave. Le cache hanno visibilità limitata alla tua organizzazione.
• Le scritture in cache si fatturano a 1,25x la tariffa di input su 5.6+, riportate nel nuovo campo usage.prompt_tokens_details.cache_write_tokens. Su 5.x e versioni precedenti le scritture erano gratuite.

GPT-5.5 e le versioni più vecchie rifiutano i nuovi parametri con un 400 pulito (prompt_cache_options is not supported on this model), quindi metti un version gate su qualsiasi rollout.

Se il design ti suona familiare, è normale: marker sui blocchi di contenuto, quattro breakpoint, un sovrapprezzo sulle scritture e una history in sola lettura che scorre sono esattamente la forma che cache_control di Claude ha sempre avuto. La differenza sta nel TTL: i 30 minuti garantiti di OpenAI sono 6 volte i 5 minuti di default di Claude.

Cosa dice il contatore

La documentazione fa promesse; qui c’è cosa ha restituito il contatore del gateway, sonda dopo sonda. I record grezzi completi sono nel log dell’esecuzione; ogni costo qui sotto quadra alla cifra con le tariffe dei tier.

Tre di quelle righe meritano un approfondimento.

Il riuso parziale è reale, ed è il motivo per adottare i breakpoint. Con un blocco A stabile e una coda B sostituita, il contatore ha rifatturato solo la coda: 1.212 token riletti alla tariffa cached, 1.210 scritti per il nuovo B al premium di write, su un prompt da 2.431 token, e il totale quadra con il listino alla cifra. È il comportamento del prefisso a strati (system prompt, poi tools, poi documenti, ciascuno marcato) attorno a cui gli utenti Claude strutturano i prompt, e la modalità automatica di GPT non ha mai potuto garantirlo. Una nota: sulle ripetizioni complete la lunghezza combaciata a volte scende sotto il mark (1.897 su un write da 2.422 token in una sonda), quindi calcola il budget sulla tariffa scontata, non su un match esatto dei conteggi.

Il floor e i miss silenziosi sono le trappole operative. Un blocco marcato di 621 token non ha memorizzato nulla in cache, due volte, senza errori e senza alcun suggerimento sull’utilizzo oltre agli zeri; se il tuo “prefisso stabile” è un breve prompt di sistema, stai pagando il prezzo pieno e nulla te lo segnala. E un miss può arrivare senza una scrittura, a prezzo pieno, in modo altrettanto silenzioso. L’hit rate è una distribuzione, non una promessa, qualunque percorso prendano le tue richieste: leggi cached_tokens in produzione e imposta degli avvisi su di esso, nel modo in cui fa il nostro audit della cache in cinque minuti.

Il premium di write è reale, e cambia il punto di pareggio. I token scritti vengono fatturati esattamente a 1.25x la tariffa di input su tutti e tre i tier (i write su Luna registrano $1.25 per milione, Terra $3.125, Sol $6.25), quadrando alla cifra su ogni sonda nella nostra ultima esecuzione. Quel premium si ripaga solo quando il prefisso viene riletto: un write che non ottiene mai un hit costa il 25% in più rispetto a non usare affatto la cache, la stessa trappola misurata sul premium di write di Claude nel post su LangChain. Marca i prefissi che sai che si ripeteranno, non tutto ciò che sembra stabile.

Il limite dei 30 minuti ha retto fin dove lo abbiamo sondato. Una rilettura con chiave 15 minuti dopo la scrittura è tornata completamente in cache (1.313 token su 1.313, riconciliati al tasso del 10%), ben oltre il vecchio orizzonte in memoria di 5-10 minuti, e una seconda prova con chiave allo stesso intervallo ha ripetuto il risultato. Non abbiamo sondato i 30 minuti completi.

Lo stesso workload su GPT-5.5, per confronto

Il confronto onesto è a parità di prezzo: Sol ha esattamente lo stesso listino di gpt-5.5 ($5/$30), quindi è il suo successore diretto, con Terra e Luna come tier ridotti sotto di esso. Stesso prezzo di listino, ma condizioni di caching molto diverse:

A parità di prezzo di listino, le condizioni di caching sono il vero miglioramento. Un prefisso da 3.000 token costa $0,0075 per chiamata su 5.5 quando la sua cache automatica decide di andare a segno, e $0,0015 su Sol caldo, 5 volte meno sulla quota memorizzata in cache. Il cambiamento più profondo riguarda il controllo e la visibilità: gli hit di 5.5 dipendono da un rilevamento del prefisso opaco che non puoi né attivare né debuggare, mentre 5.6 ti permette di contrassegnare esattamente cosa dovrebbe essere messo in cache, instradare le ripetizioni con una prompt_cache_key e osservare ogni scrittura arrivare in usage. Un miss ora appare come uno zero in un campo che hai creato tu, non come silenzio. Il percorso di riduzione progressiva si somma a tutto questo: se 5.5 stava sovra-servendo il carico di lavoro, Terra dimezza l’intero listino prezzi e Luna lo divide per cinque, e lo stesso prefisso caldo scende a $0,00075 e $0,0003. L’unica cosa che 5.5 mantiene è la conservazione opzionale per 24 ore; se il tuo traffico è un batch giornaliero contro un prefisso gigante, questo compromesso va nella direzione opposta. E nota che la seconda leva agisce in senso opposto durante la migrazione: 5.6 ragiona per impostazione predefinita, quindi un carico di lavoro 5.5 spostato senza fissare reasoning_effort acquisisce nuova spesa di output con lo stesso listino prezzi.

La seconda leva: reasoning effort

Il caching governa quanto paghi in input; reasoning_effort governa il lato output, perché i reasoning token vengono fatturati alla tariffa di output e, a differenza del tuo prefisso, non possono mai essere messi in cache. GPT-5.6 accetta da none fino a xhigh su tutti i tier. Il post di lancio introduce anche un effort max per Sol; tramite chat completions non esiste (400: 'reasoning_effort' does not support 'max' with this model, sia su Sol che su Terra), quindi xhigh è il tetto pratico sul percorso API usato da gateway e SDK.

Abbiamo eseguito una matrice di 50 chiamate: quattro tipi di task (classificare una recensione, estrarre un campo da una riga di log, un problema aritmetico a più passaggi, un piccolo task di generazione di codice) su tutti e sei i settaggi, da none a xhigh più il parametro omesso, su Terra e Luna con un controllo a campione su Sol. Tutte e 50 le risposte erano corrette a ogni settaggio. A variare era il conto. Sono chiamate a output breve (decine di token visibili), quindi qualche decina di reasoning token alla tariffa di output domina il totale; la colonna del rapporto confronta il costo dell’intera chiamata:

Tre risultati. Primo, 5.6 è adattivo da solo: sui due tipi banali nessun settaggio ha speso un solo reasoning token, quindi lì la leva è gratis. Secondo, sui tipi che sembrano meritare ragionamento (math, code), il default ragiona anche quando non porta alcun vantaggio: omettere il parametro è costato dalle 2.5x alle 3.5x il prezzo di none su math e code di Luna e su math di Terra (la run di code di Terra al default non ha speso nulla) a parità di risposte corrette, e 1.5x in più sommando l’intera griglia Terra e Luna. Terzo, i settaggi intermedi (non riportati in tabella) sono rumore, non una manopola: la run di math di Terra ha speso 19 reasoning token a low, zero a medium, 21 a high e di nuovo zero a xhigh, e la run di code di Luna ne ha spesi 101 a xhigh contro 41 a high. I nomi sono intenti, non budget: lo stesso comportamento misurato su GLM 5.2.

Invia reasoning_effort esplicitamente a ogni chiamata, e imposta il default a none per classificazione, estrazione, routing e trasformazioni brevi. Alza il settaggio su uno specifico punto di chiamata solo quando le tue eval mostrano che il valore più alto cambia i risultati, non perché il task ti sembra difficile. I nostri quattro tipi sono workload API a output breve; un lavoro davvero difficile a più passaggi può giustificare la spesa in reasoning, ma lascia che siano le misure a dirlo.

Le due leve si sommano. Una volta che un prefisso è caldo, il lato input di una chiamata Luna costa un decimo del prezzo di listino, e il default di reasoning diventa la voce di costo residua più grande sui task brevi: la chiamata di math di Luna costava in totale $0.00007 a none e $0.00025 con il parametro omesso: il solo default di reasoning ha aggiunto $0.00018, più del doppio dell’intera chiamata gestita. Se fai caching senza fissare l’effort, i risparmi rientrano dall’altra parte.

Cosa consigliare in base al workload

Ora che la decisione ha una struttura chiara, ecco cosa diciamo ai clienti del gateway:

Indipendentemente dalla forma: invia una prompt_cache_key stabile per tenant o sessione (la documentazione rende la chiave la base per un matching affidabile), mantieni ogni layer marcato al di sopra del limite minimo di 1.024 token e monitora i cached_tokens perché esistono miss silenziosi. Ricorda che le cache sono per modello: un test A/B tra tier riparte da zero su ciascun lato. E imposta l’altra leva nello stesso commit: fissa reasoning_effort secondo la matrice sopra, none a meno che una valutazione non indichi altrimenti.

Sulla scelta del tier, lo sconto del 90% cambia i conti più di quanto faccia il tier stesso. Un workload che rigioca un prefisso da 3.000 token paga circa $0,30 ogni mille chiamate per quel prefisso su traffico Luna caldo e $1,50 su Sol caldo; il divario tra tier sulla quota cached è minore del divario sui token di output. Scegli quindi il tier per qualità di output e prezzo, e lascia che il caching appiattisca il lato input. Chi arriva da gpt-5.5 trova in Sol l’upgrade drop-in allo stesso rate card, con cache read 5x più economiche e controllo su quando avvengono; scendi a Terra o Luna dove le tue eval dicono che il tier più piccolo regge, e il rate card si dimezza o si divide per cinque sopra a questo.

Il tokenizer non è cambiato

I nostri 24 campioni (un brano narrativo in nove lingue, versioni tecnica e giornalistica in sei di esse, una funzione Python e una tool-call JSON) contano in modo identico su GPT-5.5, Sol, Terra e Luna in ogni confronto che si è completato. I budget di token e le stime del cache-floor calibrati su 5.5 restano validi senza modifiche; il comportamento cross-lingua è nel nostro post sul tokenizer per lingua e vale su 5.6 così com’è.

In sintesi

• Lo sconto sulla cache che passa dal 50% al 90%, con un TTL garantito di 30 minuti, è il vero taglio di prezzo di questa release; i prezzi dei tier fanno da titolo, ma sono i termini del caching a spostare le bollette reali.
• Adotta i breakpoint espliciti per i prompt a strati: il riuso parziale è misurato, non teorico, e il modello mentale si trasferisce da Claude uno a uno.
• Rispetta il floor dei 1.024 token, manda un prompt_cache_key e monitora cached_tokens; esistono sia i miss silenziosi sia i not-cached-at-all silenziosi.
• Manda reasoning_effort in modo esplicito, con default none: il default non gestito ha fatturato 1,5x di più su tutta la nostra matrice, fino a 3,5x su singoli task, per risposte identiche.
• xhigh è il tetto raggiungibile (max 400s tramite chat completions); nessuna re-baseline del tokenizer rispetto a 5.5.

FAQ

GPT-5.6 supporta il prompt caching esplicito come Claude? Sì. Basta prompt_cache_options: {"mode": "explicit"} insieme ai marker prompt_cache_breakpoint sui blocchi di contenuto, fino a quattro scritture per richiesta (tre in modalità implicita, dove il breakpoint automatico occupa uno slot). Testando su un gateway compatibile con OpenAI, un prefisso marcato di 3.012 token è stato scritto alla prima chiamata e riletto per intero al prezzo cached alla seconda.

Quanto costa l’input cached su GPT-5.6? Il 10% del prezzo dell’input, misurato su tutti e tre i tier: $0,10 per milione su Luna, $0,25 su Terra, $0,50 su Sol. GPT-5.x fatturava i token cached al 50% dell’input, quindi su 5.6 il prezzo dei token cached è 5 volte più basso.

Il caching di GPT-5.6 è migliore di quello di GPT-5.5? Su profondità dello sconto e controllo, sì: prezzo cached al 10% contro il 50%, quattro breakpoint espliciti contro il solo rilevamento automatico che non puoi né innescare né debuggare, e una soglia minima keyed di 30 minuti contro i 5-10 minuti best effort. L’unico vantaggio che resta a 5.5 è il tier opzionale di retention a 24 ore, che 5.6 elimina.

Quanto dura la cache di GPT-5.6? La documentazione garantisce almeno 30 minuti (ttl: "30m" è l’unico valore accettato), forse più a lungo; l’opzione sostituisce il deprecato prompt_cache_retention, incluso il vecchio livello esteso di 24 ore. Nei nostri test le riletture con chiave a 15 minuti dopo la scrittura hanno colpito completamente; non abbiamo testato l’intero intervallo di 30.

Ho bisogno di prompt_cache_key? Invialo: la documentazione rende una chiave stabile per tenant o sessione la base di una corrispondenza affidabile su 5.6, con un limite morbido di circa 15 richieste al minuto per chiave. Includerla non costa nulla, e abbinarla al monitoraggio di cached_tokens è il modo per verificare che lo sconto venga effettivamente applicato.

Quanto incide reasoning_effort sul costo di GPT-5.6? Sulla nostra matrice di 50 chiamate (quattro tipi di task, sei impostazioni, Terra e Luna), ogni impostazione ha prodotto risposte corrette, e omettere il parametro ha fatturato 1,5 volte di più rispetto a none in generale, fino a 3,5 volte sul task aritmetico. Sui task banali (classificazione, estrazione) nessuna impostazione ha speso token di reasoning. Fissa none e alza solo sulla base delle eval.

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

Quale tier di GPT-5.6 conviene usare per un carico API? Sol è il successore a parità di prezzo di gpt-5.5 (stesso listino $5/$30, letture cached 5 volte più economiche); Terra e Luna sono i tier ridimensionati a metà e a un quinto di quel prezzo. Una volta che il tuo prefisso è stabile e con key, lo sconto del 90% sulla cache appiattisce il lato input, quindi scendi di tier quanto le tue eval sulla qualità dell’output consentono e lascia che sia il tier a fissare il prezzo dell’output.

← Torna al blog