Novità Registrati gratis, 10 chiamate le offriamo noi. Fino a $1, senza carta.
Guida al prompting GPT-5.6: due default che costano 1.5x e 10x

Guida al prompting GPT-5.6: due default che costano 1.5x e 10x

Indice
  1. Come deve essere strutturata una richiesta a GPT-5.6?
  2. Come si imposta reasoning_effort?
  3. Come si struttura un prompt per sfruttare la cache?
  4. Cosa si rompe migrando i prompt da GPT-5.5?
  5. Quale tier deve eseguire il prompt?
  6. FAQ

Per usare bene GPT-5.6 bastano soprattutto due parametri della richiesta, ma entrambi hanno un valore predefinito costoso. Nella nostra matrice di 50 chiamate, omettere reasoning_effort è costato 1.5x rispetto a impostarlo su "none"", a parità di risposte. Inoltre, se un prefisso stabile non viene contrassegnato, ogni chiamata lo addebita a una tariffa 10x superiore a quella di una lettura dalla cache. Questa guida raccoglie le indicazioni operative ricavate dalle misurazioni della nostra guida ai costi di GPT-5.6: come strutturare correttamente una richiesta, scegliere il livello di effort per ogni attività, organizzare il prompt per sfruttare la cache e gestire le incompatibilità quando si migrano i prompt da GPT-5.5.

TL;DR

  • Impostate reasoning_effort in ogni richiesta a GPT-5.6: nella nostra matrice di 4 attività, ometterlo è costato 1.5x rispetto a "none", con risposte identiche.
  • I livelli accettati vanno da none a xhigh; "max" restituisce un errore 400 sia su Sol sia su Terra.
  • Contrassegnate i prefissi stabili con breakpoint espliciti: le letture dalla cache costano il 10% della tariffa di input, mentre le scritture costano 1.25x. Contrassegnate ciò che si ripete, non tutto ciò che sembra stabile.
  • prompt_cache_options e i breakpoint restituiscono un errore 400 su GPT-5.5 e versioni precedenti; abilitateli in base alla versione del modello.

Come deve essere strutturata una richiesta a GPT-5.6?

Partite da questa struttura ed eliminate ciò che non serve. I due parametri vengono impostati esplicitamente, evitando di ereditare i costosi valori predefiniti:

{
  "model": "gpt-5.6-terra",
  "reasoning_effort": "low",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "prompt_cache_key": "tenant-42",
  "messages": [
    { "role": "system", "content": "…stable instructions…",
      "prompt_cache_breakpoint": { "mode": "explicit" } },
    { "role": "user", "content": "…the part that changes per request…" }
  ]
}

L’ordine segue una regola semplice: tutto ciò che è stabile va prima del breakpoint, mentre i dati specifici della richiesta vanno dopo. Gli elementi dinamici, come timestamp, nomi utente o documenti recuperati che cambiano a ogni chiamata, non devono trovarsi nel blocco contrassegnato. Basta modificare un byte perché l’intero blocco venga nuovamente addebitato con il sovrapprezzo di scrittura di 1.25x. prompt_cache_key instrada le richieste ripetute verso la stessa cache; usate una chiave stabile per tenant o sessione e considerate il limite flessibile documentato di circa 15 richieste al minuto per chiave.

Come si imposta reasoning_effort?

Sempre in modo esplicito: l’unica scelta da evitare è non impostarlo. Nelle nostre misurazioni, le richieste prive di reasoning_effort sono costate 1.5x rispetto a quelle impostate su "none", con risposte identiche in tutta la matrice. I valori accettati sono none, low, medium, high e xhigh; "max" viene rifiutato con un errore 400 che elenca l’intervallo valido. Ecco cosa ha prodotto ciascun livello nel nostro semplice test matematico su Luna:

reasoning_effortToken di reasoningRispostaCosto per chiamata
none0corretta$0.000062
low52corretta$0.000410
medium85corretta$0.000608
high74corretta$0.000542

Nel nostro studio sull’anatomia del consumo di token, GPT-5.6 è stata l’unica famiglia a rispondere correttamente a questo test con il reasoning completamente disattivato. none è quindi un valore predefinito ragionevole per estrazione, classificazione, formattazione e chiamate basate sul retrieval. Quando il modello usa il reasoning, i relativi token non sono visibili e vengono addebitati alla tariffa piena di output: nell’esempio matematico con le impostazioni predefinite, l’88% del costo di output riguardava una chain of thought non accessibile. Aumentate il livello solo quando gli eval dimostrano che l’attività ne ha bisogno, non perché il valore predefinito lo consuma già.

Come si struttura un prompt per sfruttare la cache?

Disponete i contenuti in ordine di stabilità e contrassegnate i vari livelli: prima le istruzioni di sistema, poi le definizioni dei tool e infine i documenti di riferimento, ciascuno con un breakpoint finale. Il turno utente variabile va dopo l’ultimo breakpoint. Sono disponibili quattro scritture in cache per richiesta. Nella modalità implicita predefinita, un breakpoint automatico sull’ultimo messaggio ne occupa una; la modalità esplicita le rende disponibili tutte e quattro e, soprattutto, inserisce in cache solo ciò che viene contrassegnato.

Il vantaggio sta nel riutilizzo parziale, e lo abbiamo misurato. Con un blocco A stabile e una parte finale B sostituita, il contatore ha addebitato di nuovo solo la parte finale: su un prompt di 2,431 token, 1,212 token sono stati letti alla tariffa della cache e 1,210 sono stati riscritti con il sovrapprezzo. Il risultato coincide esattamente con il tariffario. Ne derivano tre regole per il calcolo dei costi:

  • Le letture costano il 10% della tariffa di input, quindi un prefisso stratificato già presente in cache riduce sensibilmente il costo dell’input.
  • Le scritture costano 1.25x, quindi un blocco inserito in cache ma mai più letto costa il 25% in più rispetto a non usare la cache. Contrassegnate ciò che si ripete, non tutto ciò che sembra stabile.
  • In caso di ripetizioni complete, la porzione corrispondente può risultare più corta di quella contrassegnata: in una misurazione, sono stati letti dalla cache 1,897 token su una scrittura di 2,422 token. Per le stime usate la tariffa scontata, non il numero esatto di corrispondenze; il nostro studio sulle soglie minime della cache riporta i minimi per ogni famiglia.

Il valore minimo ttl: "30m" è garantito, ma non rappresenta un limite massimo, ed è 6x superiore ai 5 minuti predefiniti di Claude. Il livello da 24 ore non esiste più: i workload batch giornalieri che facevano affidamento sulla conservazione estesa devono quindi ricalcolare il punto di pareggio.

Cosa si rompe migrando i prompt da GPT-5.5?

Due problemi sono espliciti, uno è silenzioso. Quelli espliciti: prompt_cache_options e prompt_cache_breakpoint restituiscono un errore 400 su GPT-5.5 e versioni precedenti (prompt_cache_options is not supported on this model), quindi qualsiasi prompt builder condiviso deve gestire la versione del modello. Anche il livello "max", presente in alcune configurazioni di 5.5, viene rifiutato.

Il problema silenzioso è anche il più costoso: GPT-5.6 usa il reasoning per impostazione predefinita, mentre un workload su 5.5 poteva averlo disattivato. Un prompt migrato che non imposta reasoning_effort si ritrova quindi a pagare il sovraccosto di 1.5x previsto dallo stesso tariffario. Per la cache, invece, la migrazione funziona al contrario: il rilevamento automatico dei prefissi di 5.5 non richiedeva markup, ma non poteva essere attivato o sottoposto a debug. Su 5.6 lo stesso prompt non sfrutta la cache finché non viene contrassegnato. Da quel momento, ogni scrittura compare in usage.prompt_tokens_details.cache_write_tokens; in caso di miss, il campo creato riporta zero invece di essere assente.

Quale tier deve eseguire il prompt?

La stessa struttura di richiesta funziona su tutti e tre i tier, quindi la scelta dipende dal prezzo, non dal prompting: Sol costa $5/$30 per milione di token, Terra la metà e Luna un quinto. Quando il prefisso è stabile, associato a una chiave e già presente in cache, lo sconto sulle letture riduce il costo dell’input in tutti i tier. Il prezzo dell’output diventa quindi il fattore determinante: scegliete il tier più economico compatibile con gli eval sulla qualità dell’output. I calcoli completi per ogni tier, incluso il punto di pareggio del sovrapprezzo di scrittura, sono disponibili nella guida ai costi.

FAQ

GPT-5.6 supporta reasoning_effort: “max”?

No. Le richieste con "max" restituiscono un errore 400 che indica come validi i valori da none a xhigh, sia su Sol sia su Terra. I workload che richiedono il livello massimo devono inviare esplicitamente xhigh.

I breakpoint della cache funzionano su GPT-5.5?

No. GPT-5.5 e le versioni precedenti rifiutano prompt_cache_options e i marcatori di breakpoint con un errore 400. Su questi modelli si torna al rilevamento automatico dei prefissi, che non può essere attivato, associato a una chiave o sottoposto a debug. Considerate quindi la cache come un meccanismo best effort e abilitate i nuovi campi del prompt builder solo per le versioni che li supportano.

Quanti breakpoint dovrebbe usare un prompt?

Tanti quanti sono i livelli che si ripetono davvero, entro il limite disponibile: quattro scritture per richiesta, di cui una viene occupata dal breakpoint automatico implicito se non si passa alla modalità esplicita. Un tipico prompt a livelli ne richiede due o tre, per istruzioni, tool e blocco di riferimento. Un quinto marcatore viene accettato senza errori, ma condivide semplicemente gli slot di scrittura, perché ogni marcatore successivo copre tutto ciò che lo precede.

Tutti i dati di questa guida sono stati misurati tramite il gateway Synthorai sui modelli GPT-5.6 disponibili dal primo giorno e coincidono con il contatore usage.cost attivo. La metodologia e le misurazioni grezze sono disponibili nella guida ai costi e nello studio sulle soglie minime della cache. Verificate i risultati sui vostri dati di utilizzo: tariffe e valori accettati possono cambiare.

← Torna al blog