Prompt caching GPT-6: quando costa di più

Cosa è cambiato il 22 settembre 2026

Il 22 settembre OpenAI ha pubblicato l’annuncio sul prompt caching per GPT-6. I punti ufficiali sono quattro: tassi di hit più alti di default, sconto per i prefissi condivisi riusati entro una finestra di 30 minuti, un pannello dedicato nella console e uno strumento di diagnostica che spiega perché una richiesta non ha trovato la cache. Lo sconto massimo dichiarato sui token in cache è del 90%.

La parte che conta per il portafoglio sta nella guida tecnica aggiornata, che vale per GPT-5.6 e per tutti i modelli successivi, quindi anche per Astra, Sol e Luna. Tre regole la riassumono:

• la scrittura in cache costa 1,25 volte il prezzo dell’input normale, la lettura 0,1 volte;
• un prefisso resta riusabile per almeno 30 minuti dall’ultima scrittura o dall’ultimo riuso, e ogni riuso rinnova la scadenza senza una nuova scrittura;
• il prefisso minimo che entra in cache è di 1.024 token visibili: sotto quella soglia non si scrive e non si legge niente.

Con la scrittura a 1,25, un prefisso salvato che nessuno rilegge è una spesa in più rispetto a non usare la cache. È questo il dettaglio che il comunicato non mette in evidenza e che cambia il modo di configurare le chiamate.

Il conto: quando la cache conviene

La guida di OpenAI fa l’esempio in unità di prezzo. Scrivere un prefisso una volta e rileggerlo una volta costa 1,35 volte, contro 2 volte senza cache. Su dieci richieste, una scrittura e nove letture costano 2,15 volte, contro 10. Fin qui tutto bene.

Il rovescio è il caso con zero letture: 1,25 contro 1. Da qui si ricava la soglia di pareggio. Ogni scrittura costa 0,25 in più di un input normale, ogni lettura ne fa risparmiare 0,9. Il conto torna quando ogni scrittura viene riletta in media almeno 0,28 volte, cioè quando almeno una scrittura su tre o quattro trova una richiesta successiva entro i 30 minuti.

Ecco i prezzi di listino Standard per un milione di token, contesto corto, letti dalla pagina prezzi il 23 settembre 2026:

I rapporti sono identici su tutti e tre: la scrittura vale 1,25 volte l’input, la lettura un decimo. Cambia solo la scala. Su Luna il rincaro di una scrittura sprecata vale frazioni di centesimo; su Astra, con prompt lunghi, si vede in fattura.

Il caso tipico di una PMI: istruzioni fisse, testo che cambia

Prendiamo un’automazione che vedo spesso nei siti dei clienti. Un form di contatto su WordPress manda ogni richiesta a GPT-6 Sol, che la classifica (preventivo, assistenza, spam, candidatura) e prepara una bozza di risposta. Il prompt ha due parti:

• una parte fissa di 3.000 token: istruzioni, elenco dei servizi, categorie, una decina di esempi etichettati, lo schema JSON della risposta;
• una parte variabile di 400 token: il testo scritto dal visitatore.

Con la modalità implicita, dice la guida, OpenAI mette il breakpoint alla fine dell’ultimo messaggio idoneo. In una chiamata a turno singolo quel messaggio è il messaggio utente, cioè proprio la parte che cambia. Ogni richiesta scrive in cache tutti i 3.400 token, e la richiesta successiva non trova niente da riusare perché il suo testo è diverso. La guida descrive proprio questo caso: cambiando la parte dinamica, la richiesta successiva non trova il prefisso lungo salvato in cache, perché non c’è un breakpoint separato dopo la parte statica.

Ecco i numeri per 100 richieste al giorno, 3.000 al mese, solo input:

La riga dei 4,60 dollari assume due scritture al giorno, al primo contatto del mattino e dopo la pausa pranzo, e tutte le altre richieste dentro la finestra dei 30 minuti. L’output resta fuori dal conto: 300 token di risposta costano 0,003 dollari a chiamata in tutti gli scenari. Con l’output incluso, il risparmio della configurazione buona scende dal 79% al 55% circa, ed è comunque la voce che si governa più facilmente.

Venti dollari al mese non mandano in crisi nessuno. Il punto è la direzione: la stessa automazione, senza toccare una riga, può costare un quarto in più o un quinto di prima, e la differenza sta tutta in come è costruita la chiamata.

La correzione: un breakpoint esplicito dopo la parte fissa

Da GPT-5.6 in poi la cache si può governare a mano. Si imposta prompt_cache_options.mode su explicit e si marca con prompt_cache_breakpoint il blocco dove finisce la parte stabile. Quello che viene dopo l’ultimo breakpoint si paga a prezzo normale, senza sovrapprezzo di scrittura. È esattamente lo schema che la guida usa per il suo esempio di valutatore a turno singolo, per cui riporta un tasso di hit intorno al 70%.

{
  "model": "gpt-6-sol",
  "prompt_cache_options": { "mode": "explicit" },
  "input": [
    {
      "role": "developer",
      "content": [
        {
          "type": "input_text",
          "text": "Istruzioni fisse, categorie, esempi etichettati...",
          "prompt_cache_breakpoint": { "mode": "explicit" }
        }
      ]
    },
    {
      "role": "user",
      "content": "Testo della richiesta arrivata dal form..."
    }
  ]
}

Due dettagli che fanno perdere tempo. Il primo: il campo instructions di primo livello non accetta breakpoint espliciti. Se il plugin o lo snippet mette tutto lì, bisogna spostare le istruzioni in un messaggio con ruolo developer, dentro un blocco input_text. Il secondo: in modalità esplicita, se non si mette nessun breakpoint, la richiesta non usa la cache e non genera scritture. È il modo documentato per spegnerla del tutto su una singola chiamata.

Ogni richiesta può creare al massimo quattro scritture. Più breakpoint servono quando il prompt ha strati che cambiano a velocità diverse, per esempio istruzioni generali stabili per mesi e un catalogo prodotti che cambia ogni settimana. In un form di contatto ne basta uno.

Quando la cache va spenta

La finestra minima è di 30 minuti. La guida aggiunge che OpenAI può conservare il prefisso più a lungo, ma su un comportamento non garantito non si costruisce un preventivo. Se le richieste arrivano a distanza di ore, come succede a un form B2B che riceve cinque contatti al giorno, quasi ogni chiamata trova la cache scaduta e paga la scrittura a 1,25. Il breakpoint esplicito non salva il conto: è la riga del +22% della tabella.

La regola pratica che uso è questa:

• richieste frequenti con la stessa parte fissa, almeno qualche volta ogni mezz’ora: breakpoint esplicito dopo la parte fissa;
• richieste rade, distanziate di ore: modalità esplicita senza breakpoint, cioè cache spenta;
• lavori che non devono rispondere subito, come descrizioni prodotto o riassunti notturni: raggrupparli e mandarli in blocco, così la parte fissa viene riletta di seguito. Il listino Batch di Sol è anche dimezzato, 1 dollaro per milione di token in input.

Lo stesso ragionamento vale per il prewarm, la nuova opzione prompt_cache_options.prewarm che prepara la cache senza generare risposta. Serve a un’applicazione interattiva che sa di dover rispondere a breve, per esempio un assistente che si apre quando l’utente entra nella pagina. I token del prewarm si pagano come scrittura: se l’utente poi non scrive, è una scrittura persa.

Cinque cose che rompono la cache in un plugin WordPress

La cache richiede che tutto il prefisso renderizzato coincida, token per token, fino al breakpoint. Nei progetti WordPress le cause di miss che vedo ricadono quasi sempre in cinque gruppi.

1. Dati dinamici in testa al prompt

«Oggi è martedì 23 settembre, ore 8:14», il nome dell’utente loggato, il contenuto del carrello WooCommerce. Se stanno all’inizio delle istruzioni, cambiano il prefisso a ogni chiamata. La guida chiede di spostarli in fondo o in un messaggio successivo al breakpoint.

2. Strumenti in ordine diverso

Nomi, descrizioni, schemi e ordine delle definizioni dei tool fanno parte del prefisso. Un array PHP costruito con un ciclo su funzioni registrate in ordine variabile basta a produrre un miss. Ordinare l’array in modo deterministico prima della chiamata costa una riga.

3. Strumenti tolti e rimessi

Togliere le definizioni dei tool che in quel passaggio non servono sembra un risparmio di token, invece rompe il prefisso. La guida indica di lasciare la lista intatta e usare allowed_tools per limitare quelli chiamabili, oppure tool_choice impostato su none quando non ne serve nessuno.

4. Sforzo di ragionamento cambiato a metà

Alzare reasoning.effort per una domanda difficile e riabbassarlo dopo può cambiare le istruzioni di ragionamento che il modello riceve in testa al prompt, e quindi il prefisso. Sui modelli GPT-6 si aggiunge invece un elemento configuration_update in coda all’input, lasciando invariato il valore di primo livello.

5. Parte fissa sotto i 1.024 token

Un prompt di sistema di 600 token non entra mai in cache, per quante volte lo si ripeta. Ne parlo nella sezione sulla soglia, perché qui la soluzione controintuitiva a volte è allungarlo.

Misurare prima di fidarsi

La risposta della Responses API riporta in usage.input_tokens_details due campi: cached_tokens, i token letti dalla cache, e cache_write_tokens, quelli scritti. Il resto dell’input è a prezzo pieno. Una riga di log per chiamata basta a capire in una settimana quale delle quattro righe della tabella descrive il proprio sito.

<?php
/**
 * Classifica una richiesta arrivata dal form e registra l'uso della cache.
 *
 * La chiave sta in wp-config.php (costante LR_OPENAI_KEY), mai nel database.
 *
 * @param string $testo_utente Testo inviato dal visitatore.
 * @return array|WP_Error Risposta decodificata o errore.
 */
function lr_classifica_richiesta( $testo_utente ) {
	if ( ! defined( 'LR_OPENAI_KEY' ) ) {
		return new WP_Error( 'lr_openai_key', 'Chiave API non configurata.' );
	}

	// Parte fissa: istruzioni, categorie ed esempi. Deve superare i 1.024 token.
	$istruzioni = lr_istruzioni_classificatore();

	$corpo = array(
		'model'                => 'gpt-6-sol',
		'prompt_cache_options' => array( 'mode' => 'explicit' ),
		'input'                => array(
			array(
				'role'    => 'developer',
				'content' => array(
					array(
						'type'                    => 'input_text',
						'text'                    => $istruzioni,
						'prompt_cache_breakpoint' => array( 'mode' => 'explicit' ),
					),
				),
			),
			array(
				'role'    => 'user',
				'content' => sanitize_textarea_field( $testo_utente ),
			),
		),
	);

	$risposta = wp_remote_post(
		'https://api.openai.com/v1/responses',
		array(
			'timeout' => 30,
			'headers' => array(
				'Authorization' => 'Bearer ' . LR_OPENAI_KEY,
				'Content-Type'  => 'application/json',
			),
			'body'    => wp_json_encode( $corpo ),
		)
	);

	if ( is_wp_error( $risposta ) ) {
		return $risposta;
	}

	if ( 200 !== wp_remote_retrieve_response_code( $risposta ) ) {
		return new WP_Error( 'lr_openai_http', wp_remote_retrieve_body( $risposta ) );
	}

	$dati = json_decode( wp_remote_retrieve_body( $risposta ), true );
	$uso  = isset( $dati['usage'] ) ? $dati['usage'] : array();
	$det  = isset( $uso['input_tokens_details'] ) ? $uso['input_tokens_details'] : array();

	// Una riga per chiamata, solo con WP_DEBUG_LOG attivo: input, letti e scritti in cache.
	if ( defined( 'WP_DEBUG_LOG' ) && WP_DEBUG_LOG ) {
		error_log( // phpcs:ignore WordPress.PHP.DevelopmentFunctions.error_log_error_log
			sprintf(
				'lr-cache input=%d cached=%d write=%d',
				isset( $uso['input_tokens'] ) ? (int) $uso['input_tokens'] : 0,
				isset( $det['cached_tokens'] ) ? (int) $det['cached_tokens'] : 0,
				isset( $det['cache_write_tokens'] ) ? (int) $det['cache_write_tokens'] : 0
			)
		);
	}

	return $dati;
}

Il rapporto da tenere d’occhio è quello che la guida chiama tasso di hit sui token: token in cache diviso token totali in input, aggregati per giorno. Se write è quasi sempre uguale a input e cached resta a zero, si è nel caso del +25%.

Quando un miss non si spiega, c’è lo strumento di diagnostica della cache. Si passa in prompt_cache_options.comparison_response_id l’identificativo di una risposta precedente che avrebbe dovuto condividere il prefisso, e nella nuova risposta compare il motivo del mancato riuso.

{
  "prompt_cache_diagnostics": {
    "type": "cache_miss",
    "reason": "tools_changed",
    "comparison_reusable_tokens": 5629,
    "cache_missed_tokens": 5629
  }
}

Il confronto è solo diagnostico: non carica la conversazione precedente e non cambia il comportamento della cache. Si può lasciare attivo in staging e toglierlo in produzione.

La soglia dei 1.024 token e il prefisso da allungare

La guida contiene un calcolo che a prima vista sembra un paradosso: a volte conviene allungare il prompt. Se la parte fissa è sotto i 1.024 token non viene mai messa in cache, e la si paga intera a ogni chiamata. Portarla a 1.024 con materiale utile, cioè esempi etichettati, casi limite, il tono da tenere, costa di più alla prima scrittura e molto meno dopo.

Con i rapporti di GPT-6, dice la guida, su dieci richieste conviene allungare fino a 1.024 token qualsiasi prefisso di almeno 221 token. Con molte richieste la soglia scende verso 102 token, ma a 103 servono quasi 2.000 richieste per rientrare. In pratica: se un classificatore gira centinaia di volte al giorno e ha 500 token di istruzioni, aggiungere cinque o sei esempi etichettati migliora la qualità della classificazione e abbassa il costo dell’input nello stesso momento. Va però verificato con le proprie valutazioni che il comportamento del modello resti stabile, come la guida stessa raccomanda.

Il ragionamento vale solo se la parte fissa viene riletta davvero. Su un form che riceve cinque richieste al giorno, allungare il prompt aumenta soltanto il conto.

Privacy: la cache si può sondare

La cache non è condivisa tra organizzazioni diverse e non attraversa i confini regionali di elaborazione. Dentro la stessa organizzazione, invece, due richieste con lo stesso prefisso possono condividerla. Chi rivende una funzione AI a più clienti con la stessa chiave API ha quindi un problema che la guida chiama cache-hit probing: un utente può inviare prompt candidati e osservare quali trovano la cache, per capire se quel contenuto era già stato mandato da qualcun altro.

Il rimedio documentato è prompt_cache_key. Su GPT-6 non serve più per l’instradamento, che OpenAI gestisce da sola, ma separa la contabilità della cache per cliente o per utente. Una chiave stabile per ciascun cliente, per esempio preventivi:cliente_42, tiene divise le cache e rende anche la fatturazione più facile da spiegare. Se si ha già un proxy per la chiave API, come descritto nell’articolo su chiave API nel sito o dietro un proxy, è il punto giusto dove aggiungerla. Per il quadro completo su cosa resta salvato lato fornitore vale la pena rileggere anche retention dei dati nelle API AI.

La mia posizione

Il nuovo sistema è disegnato attorno agli agenti che lavorano per ore, ed è lì che l’annuncio mette i numeri: GitHub Copilot dichiara di aver ridotto di oltre il 50% la quota di token da elaborare da zero. Per quei carichi, conversazioni lunghe che si allungano in coda, il default implicito funziona bene: nell’esempio della guida, con un breakpoint esplicito in più dopo ogni risultato dei tool, il tasso di hit supera il 90%.

Le automazioni che fanno girare le PMI sono un’altra cosa: chiamate brevi, a turno singolo, con istruzioni fisse e testo che cambia, spesso distanziate di ore. Per loro il default implicito, unito al sovrapprezzo di scrittura, produce un rincaro silenzioso. Nessun errore, nessun avviso, solo una fattura più alta. Il rischio sta nel lasciarla com’è.

La mia raccomandazione è decidere la modalità chiamata per chiamata e scriverla nel codice. Esplicita con breakpoint dove il traffico è denso, esplicita senza breakpoint dove è rado. È lo stesso principio che applico quando si prezza una funzione AI al cliente: il costo per evento va conosciuto prima, non scoperto a fine mese. E vale anche per la scelta del modello: su un classificatore, passare da Sol a Luna, come discusso in modello di punta o medio, sposta il conto molto più di qualsiasi ottimizzazione della cache.

Cosa fare questa settimana

1. Elencare le automazioni che chiamano modelli GPT-5.6 o GPT-6 e, per ognuna, stimare quante richieste arrivano ogni 30 minuti nelle ore di punta.
2. Aggiungere il log di cached_tokens e cache_write_tokens e lasciarlo girare sette giorni.
3. Dove le scritture sono tante e le letture zero, spostare le istruzioni in un messaggio developer e mettere un breakpoint esplicito subito dopo la parte fissa.
4. Dove il traffico è rado, passare alla modalità esplicita senza breakpoint, oppure raggruppare i lavori non urgenti.
5. Controllare che date, nomi utente e dati del carrello stiano dopo il breakpoint, e che l’ordine dei tool sia sempre lo stesso.

Fonti

• OpenAI, Better prompt caching for GPT-6, 22 settembre 2026.
• OpenAI API, guida al prompt caching.
• OpenAI API, diagnostica della cache.
• OpenAI API, prezzi, consultata il 23 settembre 2026.