Prompt caching: come tagliare la bolletta di un'automazione AI

Il prompt caching è la voce di risparmio più sottovalutata di un'automazione AI. Non cambia il modello, non cambia le istruzioni, non peggiora la qualità delle risposte: taglia semplicemente il conto di tutto ciò che il modello rilegge da capo a ogni chiamata. In certi casi parliamo di un ottanta-novanta per cento in meno sulla voce di input. In altri, se lo configuri male, parliamo del venticinque per cento in più. La differenza tra i due scenari sta in due o tre decisioni tecniche che quasi nessuno prende consapevolmente.

Che cosa fa davvero il prompt caching

Ogni volta che un'automazione interroga un modello, non manda solo la domanda dell'utente. Manda l'intero contesto: le istruzioni di sistema, l'elenco degli strumenti che l'agente può usare, gli esempi, il documento allegato, la conversazione fino a quel punto. Quel blocco è spesso il 90% dei token in ingresso e, soprattutto, è identico a quello della chiamata precedente.

Senza cache, il modello lo rielabora da zero ogni volta e tu lo paghi ogni volta. Con il prompt caching, il fornitore conserva per un po' lo stato interno già calcolato su quella porzione iniziale e lo riusa. In pratica paghi una volta la lavorazione e molte volte solo il recupero.

Attenzione a un equivoco che vale la pena togliere subito di mezzo: non è una cache di risposte. Il modello genera comunque un output nuovo, con la sua variabilità. Quello che viene riciclato è il lavoro di lettura del contesto, non il risultato. Chi teme che la cache "congeli" le risposte sta pensando a un'altra cosa.

Quanto si risparmia: i numeri in chiaro

I meccanismi commerciali sono simili da un fornitore all'altro. Sulla documentazione di Anthropic le regole sono esplicite: scrivere in cache costa 1,25 volte il prezzo di input normale se la conservi cinque minuti, 2 volte se la conservi un'ora; leggerla costa un decimo del prezzo pieno, e sui modelli più recenti scende a un ventesimo o persino a un quarantesimo. OpenAI applica uno sconto analogo sui token letti dalla cache, attiva per impostazione predefinita, con una conservazione di base di trenta minuti. Anche Google e DeepSeek la tengono accesa in automatico sui modelli recenti.

Tradotto in bolletta. Prendi un agente di assistenza con un prefisso stabile di 30.000 token — istruzioni, listino, venti esempi di risposta — interrogato 200 volte al giorno in orario d'ufficio, quindi circa una volta ogni due o tre minuti:

• Senza cache: 6 milioni di token di input al giorno, tutti a prezzo pieno.
• Con cache calda: una scrittura (l'equivalente di 37.500 token) più 199 letture a un decimo (circa 597.000). Totale: l'equivalente di circa 635.000 token. Circa il 10% della spesa precedente.

Il secondo effetto, meno visibile in fattura ma molto visibile al cliente, è la latenza. Un prefisso già elaborato accorcia sensibilmente il tempo che passa prima della prima parola di risposta. Per un assistente che risponde dentro una chat, è la differenza tra "istantaneo" e "sta pensando".

Il prefisso è sacro: cosa manda all'aria la cache

Qui sta il punto che fa fallire la maggior parte delle implementazioni. La cache funziona per corrispondenza esatta del prefisso: un byte diverso in posizione 300 invalida tutto quello che viene dopo. Non c'è errore, non c'è avviso. Semplicemente paghi tutto a prezzo pieno e non te ne accorgi.

Le cause più frequenti, nella nostra esperienza su automazioni già in produzione:

• La data di oggi nelle istruzioni di sistema. "Oggi è 20 ottobre 2026, ore 09:14" in testa al prompt rende ogni singola chiamata un prefisso nuovo. È l'errore numero uno, e sembra innocuo.
• Il nome dell'utente o l'ID di sessione interpolati all'inizio. Ogni cliente diventa una cache a sé, senza nessun riuso.
• L'elenco degli strumenti che cambia. Le definizioni degli strumenti vengono lette prima di tutto il resto: aggiungerne uno, togliertene uno o solo riordinarli azzera l'intera cache.
• Un JSON serializzato senza ordinamento delle chiavi. Lo stesso dato, byte diversi, cache mancata.
• Sezioni condizionali del tipo "se il cliente è premium aggiungi questo paragrafo": ogni combinazione è un prefisso distinto.

La regola operativa è banale da enunciare e scomoda da applicare: il contenuto stabile va messo prima, quello volatile dopo. La data, il nome, lo stato della pratica non vanno in testa alle istruzioni; vanno in coda, nel messaggio del turno. Una cosa che invalida il turno cinque non costa nulla; una cosa che invalida la posizione zero costa tutto.

Quando il prompt caching costa di più

Questa è la parte che nessuno racconta. Scrivere in cache si paga un sovrapprezzo, e se nessuno legge quella voce resta solo un costo. Il pareggio è a due richieste con la conservazione da cinque minuti, a tre con quella da un'ora.

Riprendi l'esempio di prima, ma con un volume diverso: 20 chiamate al giorno, una ogni venti-trenta minuti. Con la cache a cinque minuti ogni chiamata arriva a cache fredda, paghi il sovrapprezzo di scrittura venti volte e spendi il 25% in più di quanto spenderesti senza cache. Portando la conservazione a un'ora — che costa il doppio in scrittura ma copre l'intervallo tra una chiamata e l'altra — la stessa automazione torna a risparmiare circa l'80%.

Tre casi in cui è meglio lasciarla stare: il prefisso cambia dall'inizio a ogni chiamata; il contesto è troppo corto (sotto il minimo del modello, che va da 512 a 4.096 token a seconda della versione, non si memorizza nulla e non te lo dice nessuno); il volume è talmente basso che la voce non si nota comunque.

Da dove si comincia

Non serve riscrivere l'automazione. Servono quattro verifiche, nell'ordine.

1. Misura prima di ottimizzare. Ogni risposta dell'API riporta quanti token sono stati letti dalla cache e quanti scritti. Se il valore in lettura è zero su chiamate ripetute, hai un invalidatore nascosto: non serve un'altra ipotesi, serve confrontare i byte di due prompt consecutivi.
2. Separa lo stabile dal volatile. Istruzioni, strumenti, esempi e documenti di riferimento da una parte; data, utente, pratica corrente dall'altra. Nell'ordine giusto.
3. Scegli la durata in base al ritmo reale del traffico, non a quello immaginato. Una chiamata ogni due minuti e una ogni mezz'ora vogliono configurazioni opposte.
4. Metti il tasso di lettura dalla cache tra le metriche che guardi ogni mese, accanto al costo per pratica. È l'indicatore che si degrada in silenzio quando qualcuno "aggiorna solo una riga" del prompt.

È lo stesso ragionamento che facciamo quando valutiamo quanto contesto dare a un agente: vale la pena leggere anche cosa significa davvero una finestra di contesto da un milione di token e come si imposta la scelta del modello per la propria azienda. Contesto, modello e cache sono tre leve della stessa fattura.

Il prompt caching non è una tecnica da specialisti: è manutenzione ordinaria di un'automazione che gira tutti i giorni. Studiollice progetta agenti e automazioni su misura, e il costo per operazione è una voce di progetto come le altre — si misura, si riduce e si tiene sotto controllo nel tempo.