Cache di 12 ore nell’API OpenAI: quando riduce il costo delle richieste lunghe

Per un agente che chiama un’API più volte nell’arco della giornata lavorativa, ritrasmettere istruzioni lunghe incide sui costi. Il 20 ottobre 2026 OpenAI ha aggiunto all’API Responses la possibilità di scegliere una durata di 12 ore per la cache: istruzioni, strumenti e contesto condivisi possono restare disponibili per il riutilizzo tra richieste distanziate di diverse ore. OpenAI indica una tariffa di scrittura pari a 2,5 volte il normale costo dei token di input; si tratta della tariffa di scrittura totale, non di un sovrapprezzo aggiuntivo. Il risparmio dipende dal riutilizzo del prefisso e dal costo di lettura dei token memorizzati nella cache. L’annuncio nel changelog di OpenAI è datato 20 ottobre 2026.

Questa durata è pensata per flussi di lavoro articolati: per esempio, un agente può analizzare documenti al mattino e riprendere l’attività più tardi con le stesse istruzioni e gli stessi strumenti. Per decidere se attivare la durata di 12 ore, è importante confrontare il costo di scrittura con quello delle letture ripetute e considerare quante richieste riutilizzano davvero lo stesso prefisso.

Che cosa viene memorizzato nella cache

Il prompt caching riutilizza una porzione iniziale dell’input che coincide tra le richieste. Le richieste successive devono mantenerla identica; è opportuno collocare i dati variabili dopo la parte stabile. La guida OpenAI al prompt caching indica che, per GPT‑5.6 e i modelli successivi nell’API Responses, è possibile impostare un TTL di `30m` o `12h`. Dodici ore è il periodo minimo durante il quale la voce deve restare disponibile per la lettura dalla cache; non è una promessa che venga eliminata esattamente dopo 12 ore. Disponibilità e parametri variano in base al modello.

Le istruzioni di sistema, le definizioni degli strumenti e le regole di elaborazione stabili sono adatte al prefisso permanente. La domanda corrente, gli identificativi dell’attività e i dati aggiornati si possono aggiungere dopo. Se si modificano le parti iniziali della richiesta, il prefisso coincidente si accorcia e può diminuire il numero di token riutilizzati.

Come valutare la convenienza

Sia P il numero di token del prefisso stabile, N il numero di invii, C il costo ordinario per token di input e R la tariffa di lettura dalla cache per il modello scelto. Con una sola scrittura e una cache hit per tutte le richieste successive, il costo del prefisso sarà approssimativamente 2,5PC + (N−1)PR. Senza cache, il suo invio costerebbe NPC. Questa stima riguarda solo il prefisso stabile: occorre conteggiare separatamente la parte variabile della richiesta, le cache miss e le scritture aggiuntive. La tariffa di lettura dipende dal modello; la documentazione indica, per esempio, 0,05 del normale costo per token di input per GPT‑6.1 Sol e 0,1 per GPT‑5.6 e i modelli successivi.

In questo modello semplificato, la cache inizia a far risparmiare sul prefisso riutilizzato quando 2,5C + (N−1)R < NC. Il punto di pareggio effettivo dipende dalle cache hit reali, dalle scritture ripetute e dalla tariffa specifica. Se le richieste sono rare, le istruzioni cambiano spesso o il prefisso è ogni volta univoco, i costi di scrittura aggiuntivi possono superare il risparmio sulle letture.

Verifica con il carico di lavoro reale

1. Definisci uno scenario di riferimento. Usa richieste tipiche, la lunghezza del prefisso stabile, gli intervalli tra le chiamate e i costi senza TTL di 12 ore.
2. Separa la parte stabile da quella variabile. Mantieni all’inizio le istruzioni condivise e gli schemi degli strumenti, poi aggiungi i dati dell’utente e l’attività corrente.
3. Confronta richieste omogenee. Calcola le scritture, il volume dei token di input memorizzati nella cache e i costi totali per il modello e la durata scelti.
4. Valuta l’intero ciclo di lavoro. Considera le cache miss, le scritture ripetute dopo la scadenza e i casi in cui le modifiche al prefisso impediscono di riutilizzarlo.

Le metriche delle risposte API aiutano a verificare il volume effettivo di token di input letti dalla cache e delle scritture; i dati riportati variano in base al modello. Una durata configurabile di 12 ore è adatta a un prefisso stabile e lungo, riutilizzato a distanza di diverse ore. Per richieste brevi o riutilizzate di rado, misurare prima scritture, cache hit e costo totale sul proprio traffico.