GPT-6.1 Terra Caching: cinque centesimi per lettura, e quando la scrittura si ripaga

La tariffa di input in cache di GPT-6.1 Terra è di $0,05 per milione di token: il 95% in meno rispetto alla tariffa standard di input di $1,00, e il maggiore sconto singolo dell'intera scheda. Il rovescio della medaglia è dall'altra parte del bilancio: scrivere nella cache costa $1,25 per milione per una conservazione di 30 minuti oppure $2,50 per milione per 12 ore. Un carico di lavoro che legge due volte lo stesso prefisso ci guadagna. Un carico di lavoro che ricostruisce il proprio prefisso a ogni chiamata paga la commissione di scrittura e non incassa mai lo sconto, e la scheda tariffaria non ti dirà quale dei due stai eseguendo.

Questo articolo fa i calcoli: il punto di pareggio esatto, tre carichi di lavoro concreti su scale diverse, l'interazione con la soglia critica del contesto lungo da 272K e le abitudini di prompt engineering che distruggono silenziosamente le cache.

I quattro numeri

• Input standard — $1,00 per milione di token.

• Input in cache — $0,05 per milione, uno sconto del 95%.

• Scrittura nella cache, conservazione di 30 minuti — 1,25 $ per milione.

• Scrittura della cache, conservazione di 12 ore — $2.50 per milione.

Sopra 272.000 token di input tutto raddoppia: $2,00 per l'input, $0,10 per la cache, $2,50 per la scrittura in cache. Quindi il salto del contesto lungo non aumenta solo la tariffa dell'input — aumenta contemporaneamente il prezzo sia della cache sia della scrittura.

Per confronto, l'input in cache di GPT-6.1 Sol costa $0,10 e quello di GPT-5.6 Terra $0,20. La lettura da cinque centesimi di Terra è la più economica della famiglia, ed è lo sconto del 95% a rendere davvero economicamente possibile le chiamate ripetute con contesto lungo.

Il punto di pareggio esatto

Supponi che un prefisso di P token venga riutilizzato in N chiamate e, per un momento, ignora l'output.

• Senza caching: N × P × 1,00 $.

• Con la cache: una scrittura a $1,25 × P, poi N letture a $0,05 × P.

Uguagliandoli: 0,95N = 1,25, quindi N ≈ 1,32. In pratica ciò significa che la seconda chiamata è già redditizia: la scrittura costa 1,25 per milione e ogni lettura fa risparmiare 0,95, quindi due letture recuperano più della scrittura. Con una conservazione di 12 ore la scrittura costa $2,50 e il punto di pareggio è 2,63 letture — la terza chiamata la ripaga.

È un'asticella più bassa di quanto la maggior parte dei team presupponga. Il mito diffuso è che la cache sia conveniente solo con un riutilizzo molto elevato; su questa scheda conviene già dalla seconda richiesta, purché il prefisso corrisponda davvero.

Tre carichi di lavoro

Un prompt di sistema da 50.000 token su 10.000 richieste brevi. Senza cache: 10.000 × 50.000 × $1,00 per milione = $500 solo per il prefisso. Con cache: una scrittura di 50.000 × $1,25 per milione = $0,0625, più 10.000 letture a 50.000 × $0,05 per milione = $25. Totale $25,06 — un risparmio del 95% sul prefisso, e la scrittura in cache è un errore di arrotondamento.

Un repository da 900.000 token su 20 domande. Senza cache, ogni richiesta fa scattare la tariffa long-context: 900.000 × $2.00 per milione = $1.80 per chiamata, $36 per venti. Con la cache: una scrittura di 900.000 × $2.50 per milione = $2.25, poi venti letture a 900.000 × $0.10 per milione = $0.09 ciascuna, $1.80 in totale. Totale $4.05 — un risparmio dell'89%, e la differenza di diciotto dollari è l'intero margine su alcuni prodotti.

Un documento da 20.000 token distribuito su tre domande, ciascuna con una persona e istruzioni diverse. Questo è il caso in cui la cache fallisce: se il prefisso cambia tra una chiamata e l’altra — system prompt diverso, ordine delle istruzioni diverso, un ID utente interpolato all’inizio — il modello vede tre prefissi diversi e scrive tre cache. Senza cache e con la “cache” il costo è lo stesso, solo che hai pagato per le scritture. La soluzione è strutturale: metti tutto ciò che è variabile alla fine del prompt e mantieni il documento e le istruzioni stabili all’inizio.

Cosa invalida una cache/p> p>Il prompt caching di OpenAI funziona sul prefisso invariato di una richiesta. Qualsiasi modifica nelle prime parti del prompt invalida tutto ciò che segue. Le cause più comuni:/p> p>• Un timestamp o un ID richiesta nel prompt di sistema. È la causa più comune di un tasso di hit della cache pari allo 0%./p> p>• Personalizzazione per utente inserita in cima invece che in fondo./p> p>• Definizioni degli strumenti riordinate o un elenco di strumenti che cambia tra una chiamata e l'altra./p> p>• Un passaggio di recupero che concatena i documenti in un ordine diverso ogni volta./p> p>• Modifiche agli spazi bianchi dovute ai motori di templating — riformattare un blocco JSON è sufficiente./p> p>• Passare da Chat Completions a Responses (o viceversa) a metà pipeline, il che modifica il prefisso serializzato./p> p>La diagnosi è semplice: registrare nei log i primi 2.000 token di ogni richiesta e calcolarne l'hash. Se l'hash cambia tra chiamate che dovrebbero essere identiche, la cache è morta e nessuna ottimizzazione potrà farla rivivere./p> h2>Cache e il limite di 272K

I due interagiscono in un modo facile da trascurare. Un prefisso in cache da 250.000 token costa $0,05 per milione in lettura e $1,25 in scrittura. Portalo a 300.000 token e ogni numero raddoppia: $0,10 in lettura, $2,50 in scrittura, e la porzione non in cache viene fatturata a $2,00. Una pipeline che supera la soglia paga il salto di costo sia sul lato in cache sia su quello non in cache.

Questo crea un incentivo di progettazione tutt'altro che ovvio: se un carico di lavoro si colloca appena sopra i 272K, ridurre il prefisso a 270K può dimezzare il costo senza modificare l'attività. Eliminare una sezione boilerplate, rimuovere un blocco di recupero non necessario o spostare un esempio fuori dal prompt di sistema vale di più al limite di quanto valga in qualsiasi altro punto della scheda.

Caching rispetto alle alternative

• Caching — ideale quando lo stesso lungo prefisso viene riutilizzato molte volte all'interno della finestra di conservazione, e il prefisso è davvero stabile.

• Suddivisione in blocchi — è ideale quando il documento è grande ma ogni domanda riguarda solo una piccola parte; il recupero costa meno che inviare 900K token anche alla tariffa con cache.

• Batch/Flex — 50% di sconto rispetto allo standard, ma la latenza batch si misura in ore; si cumula con il caching, non con i prodotti in tempo reale.

• Un modello più economico — GPT-6 Luna a $0.10/$0.50 può superare la tariffa con cache di Terra per le attività semplici, perché l'input non in cache di Luna costa solo il doppio dell'input in cache di Terra.

L'ultimo confronto è quello che i team dimenticano. La cache è uno sconto su Terra, non una garanzia che Terra sia il modo più economico per rispondere a una domanda. Per la classificazione su un prompt da 50.000 token, Luna in cache a $0,01 per milione di letture resta comunque l'opzione più economica se il compito è abbastanza semplice.

Cosa puoi eseguire oggi

GPT-6.1 Terra non è nel catalogo di OrcaRouter al momento della stesura, quindi il suo comportamento della cache deve essere misurato direttamente rispetto a OpenAI. I modelli attivi — GPT-6.1 Sol a $2/$10 con una tariffa cache di $0.10, GPT-5.6 Terra a $2/$12 con $0.20, GPT-6 Luna a $0.10/$0.50 — possono tutti essere testati con una singola chiave con un ricarico dello 0% rispetto al prezzo di listino del provider.

La misura da costruire non è "il caching funziona?" — funziona — ma "quale frazione del mio traffico ha un prefisso stabile". Quella frazione è l'unico numero che decide se la lettura da cinque centesimi di Terra conta per la tua bolletta, ed è una proprietà dei tuoi prompt, non del modello.