Prompt caching nelle API LLM: Anthropic, OpenAI e Gemini a confronto, e quando ti fa risparmiare davvero

In breve: il prompt caching fa pagare meno la parte del prompt che resta uguale tra una richiesta e l'altra: istruzioni di sistema, definizioni dei tool, documenti, storia della conversazione. Funziona solo sul prefisso identico, sopra una soglia minima di token e per un tempo limitato. Anthropic lo attivi tu con cache_control: la scrittura costa 1,25 volte l'input normale per 5 minuti, 2 volte per un'ora, e la lettura 0,1 volte. OpenAI lo applica da solo sui modelli supportati; da GPT-5.6 puoi scegliere i breakpoint e la durata, con una scrittura a 1,25 volte (30 minuti) o 2,5 volte (12 ore). Gemini ha una cache implicita, attiva di default da Gemini 2.5 ma senza garanzia di risparmio, e una esplicita con TTL e costo di storage. Ripaga quando lo stesso prefisso lungo torna più volte entro la durata della cache. Se il prefisso cambia a ogni richiesta, non risparmi niente.

Nessun test mio in questo pezzo: niente risparmi "misurati" né latenze rilevate da me. Uso solo la documentazione ufficiale di Anthropic, OpenAI e Google, letta il 21 ottobre 2026. Gli esempi di calcolo sono ipotetici e lo dico ogni volta. Prezzi e soglie cambiano spesso: prima di decidere, ricontrolla le pagine linkate.

La domanda sbagliata e quella giusta

Non "quale provider ha la cache più economica?". È: quanta parte del mio prompt è davvero identica tra le richieste, e quanto spesso torna. Il prompt caching non riduce l'output e non rende il modello più bravo: la documentazione di Anthropic dice che la risposta è identica a quella senza cache. Cambia solo quanto paghi l'input ripetuto, e quanto tempo passa prima del primo token.

C'è anche un equivoco da togliere subito. La cache di AI Gateway di Cloudflare è un'altra cosa: memorizza la risposta a una richiesta identica e la restituisce senza chiamare il modello. Il prompt caching del provider invece chiama sempre il modello, ma riusa il lavoro già fatto sul prefisso. La prima serve per domande ripetute uguali; il secondo per contesti lunghi riusati con domande diverse.

Tabella rapida

Verdetto di riga: Anthropic ti fa scegliere tutto e ti fa pagare la scrittura; OpenAI fa quasi tutto da solo; Gemini separa il "forse risparmi" (implicita) dal "risparmi di sicuro, ma paghi lo storage" (esplicita).

Anthropic: decidi tu dove finisce il prefisso

Con Claude la cache si attiva in due modi, secondo la guida al prompt caching. Il più semplice è un cache_control al livello più alto della richiesta: il sistema mette il breakpoint sull'ultimo blocco che si può memorizzare e lo sposta in avanti man mano che la conversazione cresce. L'altro è mettere cache_control sui singoli blocchi, fino a quattro breakpoint, per separare parti che cambiano con ritmi diversi: i tool quasi mai, il contesto una volta al giorno, la conversazione a ogni turno.

Il prefisso segue sempre l'ordine tools, system, messages. Cambiare la definizione di un tool invalida tutta la cache; cambiare tool_choice o aggiungere un'immagine invalida solo i messaggi.

I moltiplicatori di prezzo sono fissi: la scrittura con durata di 5 minuti costa 1,25 volte l'input base, quella da un'ora 2 volte, la lettura 0,1 volte. Su alcuni modelli recenti la lettura costa ancora meno: 0,05 volte su Claude Opus 5.5 e Sonnet 5.5, 0,025 volte su Fable 5.1 e Mythos 5.1. Per esempio, nella tabella ufficiale Claude Sonnet 5.5 ha un input base di 2 dollari per milione di token, la scrittura a 5 minuti a 2,50 e la lettura a 0,10.

Tre dettagli che la documentazione mette in evidenza:

• Soglia minima. Da 512 token (per esempio Opus 5.5, Sonnet 5.5, Haiku 5.5) a 4.096 (Opus 4.6, Haiku 4.5). Sotto la soglia la richiesta passa senza cache e senza errore: lo vedi solo perché cache_creation_input_tokens e cache_read_input_tokens restano a zero.
• Durata. I 5 minuti si rinnovano gratis a ogni lettura e si contano dall'inizio della richiesta, non dalla fine della risposta: se una risposta impiega 4 minuti, la richiesta successiva deve partire entro circa un minuto.
• Richieste in parallelo. La voce in cache esiste solo dopo che la prima risposta è iniziata. Se mandi dieci richieste insieme, nessuna legge la cache delle altre.

OpenAI: automatico, ma da GPT-5.6 puoi guidarlo

La guida di OpenAI dice che il prompt caching è attivo di default sui modelli supportati, con uno sconto sull'input in cache fino al 95%. Il comportamento cambia con la generazione del modello.

Da GPT-5.6 in poi la soglia è di 1.024 token visibili. Puoi lasciare a OpenAI la scelta dei breakpoint (modalità implicita) o sceglierli tu con prompt_cache_breakpoint (modalità esplicita), fino a quattro scritture per richiesta. La durata minima si imposta con prompt_cache_options.ttl: "30m" di default, con la scrittura a 1,25 volte l'input, oppure "12h" nella Responses API, a 2,5 volte. La lettura costa 0,1 volte l'input, 0,05 volte su GPT-6.1 Sol.

Sui modelli precedenti non c'è un costo di scrittura e la tariffa di lettura dipende dal modello. La durata si sceglie con prompt_cache_retention: in_memory tiene le voci per circa 5-10 minuti di inattività, fino a un'ora; 24h le può tenere fino a 24 ore. Per questi modelli OpenAI consiglia un prompt_cache_key stabile per far arrivare le richieste con lo stesso prefisso alla stessa cache. Da GPT-5.6 il routing è automatico e la chiave serve solo a separare la contabilità della cache, per esempio per cliente.

Quanto hai letto dalla cache lo trovi in usage.input_tokens_details.cached_tokens.

Gemini: implicita senza garanzia, esplicita con storage

La documentazione di Gemini distingue due meccanismi. La cache implicita è attiva di default su Gemini 2.5 e successivi: se la richiesta colpisce la cache, il risparmio ti viene girato in automatico, ma senza garanzia. Le soglie minime vanno da 2.048 token (Gemini 2.5 Flash e Pro) a 4.096 (Gemini 3.x e Gemini 4 Argon). Per aumentare le probabilità di colpirla, la stessa pagina consiglia di mettere i contenuti grandi e comuni all'inizio del prompt e di mandare richieste con lo stesso prefisso a poca distanza.

La cache esplicita, secondo la guida della Generate Content API, crea un oggetto cache con un TTL: se non lo imposti, dura un'ora. Il risparmio è garantito, ma paghi due voci: i token in cache, a tariffa ridotta quando li riusi, e lo storage per tutta la durata del TTL. È disponibile sui modelli Gemini 3 e 2.5 tramite generateContent; non è supportata nella Interactions API né da Gemini 4 Argon in poi. I prezzi sono sulla pagina dei prezzi di Gemini.

Quando ripaga: il conto in moltiplicatori

Con un costo di scrittura, la cache conviene solo se il prefisso viene letto abbastanza volte prima di scadere. Il conto si fa in multipli del prezzo di input base, senza bisogno di prezzi precisi. Prendiamo un prefisso usato *n* volte entro la durata della cache, con la lettura a 0,1×:

• Scrittura a 1,25× (Anthropic 5 minuti, OpenAI 30 minuti). Senza cache paghi *n*; con cache 1,25 + 0,1 × (*n* − 1). Già alla seconda richiesta 1,35 contro 2: conviene dal secondo uso.
• Scrittura a 2× (Anthropic 1 ora). Alla seconda richiesta 2,1 contro 2, alla terza 2,2 contro 3: conviene dal terzo uso.
• Scrittura a 2,5× (OpenAI 12 ore). Alla terza richiesta 2,7 contro 3: conviene dal terzo uso, con meno margine.

Un esempio ipotetico con i prezzi di listino di Claude Sonnet 5.5 (input 2 dollari per milione, scrittura a 5 minuti 2,50, lettura 0,10): un prefisso di 10.000 token usato 100 volte senza mai scadere. Senza cache sono 1.000.000 di token a 2 dollari, cioè 2 dollari. Con cache sono 10.000 token scritti (0,025 dollari) più 990.000 letti (0,099 dollari), circa 0,12 dollari. Non è una misura: è aritmetica sul listino, e nella realtà la cache può scadere tra una richiesta e l'altra.

Quando non ripaga: prefissi sotto la soglia minima, richieste distanti più della durata della cache, prompt dove la parte variabile sta all'inizio.

Gli errori che annullano la cache

• Un timestamp o un ID richiesta all'inizio del system prompt. Il prefisso cambia a ogni chiamata e la cache non viene mai letta. La documentazione di Anthropic lo dice chiaro: il breakpoint va sull'ultimo blocco che resta identico tra le richieste, non su quello che cambia.
• Tool che cambiano o chiavi JSON in ordine casuale. Su Claude, cambiare le definizioni dei tool invalida tutta la cache. La documentazione di Anthropic avverte anche che alcuni linguaggi, come Go e Swift, mescolano l'ordine delle chiavi nei blocchi tool_use durante la conversione in JSON, e questo rompe la cache.
• Cambiare impostazioni a metà conversazione. Su Claude, cambiare il ragionamento esteso (thinking), l'effort o tool_choice invalida almeno la parte dei messaggi.
• Mandare tutto in parallelo. Con Claude la cache esiste solo dopo che la prima risposta è partita: prima una richiesta, poi le altre.
• Dimenticare di controllare. Tutti e tre i provider riportano i token letti dalla cache nella risposta. Se restano a zero, la cache non sta lavorando.

Il modo più semplice per avere un prefisso stabile è tenere le regole del progetto in un file fisso, come spiegato in AGENTS.md, CLAUDE.md e regole di Cursor, e metterle all'inizio del prompt, prima di tutto ciò che cambia.

Cosa conviene fare adesso

• Metti in cima al prompt quello che non cambia mai (tool, istruzioni, documenti) e in fondo quello che cambia (data, domanda, contesto della richiesta).
• Su Claude parti dal cache_control automatico; passa ai breakpoint espliciti solo quando hai parti con ritmi diversi.
• Su OpenAI con GPT-5.6 o successivi, scegli "12h" solo per materiale riusato durante tutta la giornata: la scrittura costa il doppio della durata da 30 minuti.
• Su Gemini, usa la cache esplicita solo se il contesto grande torna spesso entro il TTL; altrimenti lo storage si mangia il risparmio.
• Dopo il deploy, guarda i campi di utilizzo nella risposta (cache_read_input_tokens su Claude, cached_tokens su OpenAI, i token in cache su Gemini) per una settimana, prima di dire che la cache funziona.
• Se usi un gateway, ricorda che la sua cache e quella del provider sono due livelli diversi: AI Gateway memorizza risposte, il provider memorizza prefissi.