Tariffe dell'input in cache di GPT 5.6 e Gemini 3.6 Flash: quanto costa

DR

La tariffazione dell’input in cache può ridurre in modo significativo il costo dei carichi di lavoro che reinviano un ampio prefisso di prompt invariato, ma il risparmio dipende da regole specifiche del modello per lettura/scrittura della cache, archiviazione, routing e retention. Un’etichetta generale “caching supported” non è sufficiente per stimare i costi; usa il prezzo corrente pubblicato per il modello e la route esatti.

TL;DR

• GPT-5.6 Terra ha prezzi espliciti di cache-read e cache-write da OpenAI, CometAPI e OpenRouter, sebbene le route gateway e i livelli long-context possano modificarne l’importo.
• Google pubblica una tariffa di caching del contesto Standard di $0.15 per 1M token per Gemini 3.6 Flash più un addebito di archiviazione; CometAPI al momento pubblica i prezzi standard di input e output del modello senza una voce separata per l’input in cache.
• Il confronto rilevante non è solo input standard contro lettura da cache. Include anche la prima scrittura in cache, eventuali costi di archiviazione, la durata della cache, la coerenza della route e il numero di successivi cache hit.

Key messages

• Controlla i prezzi a livello di modello e di livello di servizio invece di applicare un moltiplicatore valido per tutto il gateway.
• Tieni separati lettura da cache, scrittura in cache, archiviazione e caching della risposta nei calcoli dei costi.
• Verifica l’effettivo utilizzo della cache nei metadati della risposta API prima di prevedere risparmi basandoti sulla tariffa pubblicata.

Una richiesta che ripete un grande prefisso invariato — un system prompt, un insieme di schemi di tool, un lungo documento di riferimento — non deve essere fatturata al pieno tasso di input a ogni chiamata. La maggior parte dei modelli di generazione corrente supporta una qualche forma di tariffazione dell’input in cache: una tariffa ridotta per la porzione di prompt che un provider riconosce come già elaborata. Il meccanismo, l’entità dello sconto e la chiarezza con cui è pubblicato variano per provider e per gateway, e vale la pena essere specifici invece di trattare “il caching è supportato” come una funzione uniforme.

What cached input pricing is, and isn't

La tariffazione dell’input in cache sconta i token di input in una richiesta che corrispondono a un prefisso inviato in precedenza. Non sconta i token di output e non è la stessa cosa di un gateway che deduplica due richieste totalmente identiche restituendo una risposta gratuitamente — questo è un meccanismo diverso che alcuni gateway offrono separatamente. La tariffazione dell’input in cache riguarda specificamente il pagare meno per la parte del prompt che un provider del modello ha già visto di recente, non il saltare completamente la generazione.

Crearla non è nemmeno gratuito. Le note sui prezzi di GPT-5.6 di OpenAI affermano che le scritture in cache sono fatturate a 1,25 volte la tariffa di input non in cache, mentre le letture da cache ricevono uno sconto del 90%. Questo sovrapprezzo della prima scrittura influisce sul punto di pareggio ed è facile da perdere se un confronto mostra solo la tariffa scontata di lettura. Altri provider possono usare addebiti basati sull’archiviazione invece dello stesso modello di scrittura, quindi i costi di scrittura e archiviazione vanno verificati separatamente.

In pratica, l’unità di cache fatturabile è di solito un prefisso di prompt riutilizzabile piuttosto che una raccolta arbitraria di frasi ripetute. I provider tokenizzano e fanno il matching in ordine, quindi il materiale riutilizzabile deve apparire prima della coda specifica della richiesta. Istruzioni di sistema stabili, definizioni di tool, policy e materiale di riferimento appartengono all’inizio; un messaggio utente variabile, timestamp, ID richiesta o snippet recuperati vanno dopo. Anche una modifica apparentemente innocua vicino all’inizio può cambiare la tokenizzazione o interrompere la corrispondenza per tutto ciò che segue.

Le regole di ammissibilità sono anch’esse specifiche del modello. Un provider può richiedere una lunghezza minima del prompt, riconoscere solo breakpoint documentati o esporre un campo esplicito di controllo della cache. Una voce in cache può scadere tra le chiamate e un gateway potrebbe dover mantenere le richieste correlate su una route upstream compatibile. Ciò significa che un cache hit va trattato come un esito osservato, non come un’assunzione derivata dalla somiglianza del prompt. Un prompt ben strutturato migliora la probabilità di riuso, ma sono i metadati della risposta e la fattura a determinare se la tariffa scontata sia stata effettivamente applicata.

What's actually published, by model and by gateway

La tabella seguente è un’istantanea dei prezzi verificata il 29 luglio 2026. I prezzi sono in dollari USA per 1 milione di token salvo diversa indicazione. Le righe confrontano le informazioni pubbliche correnti per GPT-5.6 Terra e Gemini 3.6 Flash tra provider del modello, CometAPI e OpenRouter; non vanno considerate come un tariffario permanente.

Leggi la tabella come un’istantanea specifica per modello e route. La pagina del modello GPT-5.6 di CometAPI dettaglia GPT-5.6 Terra a $2.00 input standard, $0.20 input in cache e $2.50 scrittura in cache per 1 milione di token. La sua pagina del modello Gemini 3.6 Flash attualmente pubblica $1.20 input e $6.00 output, ma non mostra una tariffa separata per input in cache o archiviazione della cache. Il pricing della Gemini Developer API di Google elenca lo Standard a $1.50 input, $0.15 context caching e $1.00 per 1 milione di token all’ora per l’archiviazione. OpenRouter ora espone campi di cache specifici per modello tramite la sua Models API: la route predefinita di GPT-5.6 Terra include prezzi promozionali più bassi e un livello long-context separato più alto, mentre la sua voce Gemini 3.6 Flash espone valori diversi per Standard, Flex e Priority. Questo è più preciso che applicare un moltiplicatore di cache generico a ogni modello.

Why gateway and provider prices can diverge

Il prezzo di un gateway non è necessariamente un ricarico su un listino upstream immutabile. Può riflettere capacità negoziata, una promozione temporanea, un diverso livello di servizio o un accordo commerciale specifico per route. Un nome di modello può anche mappare a più varianti upstream i cui prezzi cambiano con la lunghezza del contesto o con le garanzie di latenza. L’entry GPT-5.6 Terra di OpenRouter, per esempio, pubblica una route predefinita e un override dal prezzo più alto una volta raggiunta la soglia di long-context dell’input. Google separa prezzi Standard, Batch, Flex e Priority per Gemini 3.6 Flash. Una singola riga di confronto richiede quindi una data, una route, un livello e un’ipotesi di contesto per restare significativa.

L’inverso è altrettanto importante: se una pagina di gateway non pubblica una riga separata per la lettura da cache, questa assenza non andrebbe convertita né in “il caching non è disponibile” né in “lo sconto diretto del provider si applica automaticamente”. Il gateway può trasferire una funzione upstream senza dettagliarla, esporla solo su certe route oppure fatturare la richiesta alla sua normale tariffa di input. L’approccio difendibile è usare la pagina modello corrente del gateway per la pianificazione, quindi confermare la tariffa effettiva dai registri d’uso o dai dati di fatturazione. La documentazione del provider resta utile per capire il meccanismo, ma non stabilisce di per sé i termini commerciali di un intermediario.

Where the discount actually matters

Lo scenario in cui questo cambia significativamente i costi reali è un grande prefisso statico abbinato a una piccola parte variabile della richiesta — un system prompt o un set di schemi di tool reinviati a ogni chiamata in un loop agentico, un lungo documento di riferimento consultato ripetutamente con domande diverse o la cronologia della conversazione reinviata a ogni turno del chatbot. Per un carico di lavoro di questo tipo, il divario tra pagare il prezzo pieno di input per l’intero prefisso ogni volta e pagare una tantum il sovrapprezzo di scrittura e poi la tariffa scontata di lettura si amplifica con il volume di chiamate. Non fa nulla per carichi che non ripetono un prefisso — una richiesta una tantum non ha contenuti in cache da scontare.

Un calcolo pratico del punto di pareggio confronta il costo non in cache del prefisso ripetuto su tutte le chiamate con il costo di scrittura o di archiviazione della cache più le letture scontate su quelle successive. Il risultato dipende dalla dimensione del prefisso, dal numero di cache hit riusciti, dalla scadenza della cache e dal fatto che il gateway mantenga le richieste su una route del provider compatibile. Se queste condizioni sono instabili, lo sconto in evidenza può sovrastimare i risparmi realizzati in produzione.

A simple cost model for a repeated prefix

Sia P il numero di token nel prefisso stabile e N il numero di chiamate che lo riutilizzano. Se U è il prezzo di input non in cache per token, il prefisso costa N × P × U senza caching. Una stima semplificata con caching è P × W + (N − 1) × P × R + S, dove W è la tariffa di scrittura in cache, R è la tariffa di lettura da cache e S è un eventuale addebito di archiviazione nel periodo. La formula presume che la prima chiamata crei la cache e che ogni chiamata successiva sia un hit riuscito. Esclude la coda variabile di ciascuna richiesta, i token di output, i retry e qualsiasi cambio di route che causi un miss.

Considera un prefisso illustrativo da 100.000 token riutilizzato per 20 chiamate alla tariffa ufficiale GPT-5.6 Terra. A $2.50 per 1 milione di token di input non in cache, elaborare ripetutamente quel prefisso costerebbe $5.00. Usando la tariffa di scrittura al 1,25x e la tariffa di lettura scontata del 90%, una scrittura da 100.000 token costerebbe circa $0.3125 e diciannove letture circa $0.475, per un costo totale del prefisso di circa $0.7875. La differenza è di circa $4.21 prima dei costi variabili di input e output. Questa è un’illustrazione, non un preventivo: vale solo se tutte le diciannove chiamate successive colpiscono la stessa cache valida e non si applica alcun costo aggiuntivo di archiviazione o routing.

Il punto di pareggio deriva direttamente dallo stesso modello. Un sovrapprezzo di scrittura è giustificato solo quando si verificano sufficienti letture scontate prima della scadenza. Per un carico con sessioni brevi, modifiche frequenti al prompt o scarsa affinità di route, la cache potrebbe essere ricreata più spesso del previsto. Per un loop agentico di lunga durata o un’analisi ripetuta di documenti con un prefisso stabile, il numero di hit può essere molto più alto. Le previsioni dovrebbero quindi usare un intervallo di hit-rate osservato invece di assumere una sequenza perfetta dopo la prima chiamata.

Implementation patterns that improve cache reuse

La costruzione del prompt ha un effetto sul tasso di hit maggiore di quanto molte tabelle di prezzo implichino. Metti il materiale più stabile per primo e mantieni deterministica la sua serializzazione: istruzioni di sistema, schemi dei tool, testo delle policy e contesto di riferimento condiviso dovrebbero conservare lo stesso ordine, spaziatura e rappresentazione dei campi tra le chiamate correlate. Accoda il contenuto volatile in seguito. Evita di inserire nel prefisso riutilizzabile timestamp, identificatori casuali, contatori in continuo cambiamento o risultati specifici della richiesta ottenuti via retrieval, a meno che non siano davvero necessari lì.

Versiona il materiale stabile in modo deliberato. Se uno schema di tool o una policy cambia, assegna coerentemente la nuova versione invece di consentire la circolazione di varianti quasi identiche. Per carichi di lavoro conversazionali o agentici, riusa un identificatore di sessione stabile o una cache key quando l’API lo supporta ed evita di cambiare provider all’interno della stessa sequenza dipendente dalla cache. OpenRouter documenta un routing aderente al provider per il prompt caching ed espone controlli come session_id e prompt_cache_key; tali controlli possono migliorare la continuità, ma non garantiscono un hit quando la cache upstream è fredda o scaduta.

Le applicazioni dovrebbero anche degradare correttamente in caso di miss. Il caching è un’ottimizzazione di costo e latenza, non una dipendenza di correttezza. La richiesta deve comunque produrre lo stesso risultato valido quando la cache non è disponibile, e la logica di retry non dovrebbe creare scritture ripetute alla cieca. Questa separazione rende più sicuro confrontare le route: i team possono cambiare policy di caching o configurazione del gateway senza cambiare il comportamento semantico dell’applicazione.

How to verify cache economics in production

Inizia con la telemetria per richiesta anziché con la fattura mensile. Registra l’identificatore esatto del modello, la route del gateway o il provider quando esposti, il livello di servizio, il totale dei token di input, i token di lettura da cache, i token di scrittura in cache, i token di output, la latenza e il costo fatturato. L’oggetto di utilizzo di OpenRouter include cached_tokens e cache_write_tokens; altri provider espongono dettagli equivalenti con nomi di campo diversi. Conserva i campi grezzi di utilizzo in modo che un cambio di prezzo successivo non cancelli le evidenze necessarie a ricostruire il costo.

Aggrega i dati per versione del prompt e carico di lavoro, non solo per modello. Misure utili includono la quota di richieste ammissibili che colpiscono una cache, la quota di token di input fatturati alla tariffa di lettura, le scritture per ogni lettura riuscita, il tempo tra scrittura e ultimo hit e il costo realizzato per richiesta. Un alto tasso di hit a livello di richiesta può comunque offrire scarso valore se il prefisso in cache è piccolo, mentre un tasso di hit più basso su un prefisso molto grande può far risparmiare di più. Abbina queste misure alle percentile di latenza, perché una route più economica che manca ripetutamente o effettua rerouting può essere operativamente peggiore.

Infine, esamina le anomalie invece di appiattirle. Un calo improvviso dei token in cache può indicare un rilascio di versione del prompt, una serializzazione instabile, voci scadute, una soglia di livello long-context o un cambio di route del gateway. Confronta le richieste interessate con la pagina del modello corrente e la documentazione del provider, quindi verifica la tariffa fatturata. Questo colma il divario tra uno sconto pubblicato e i risparmi effettivamente realizzati dall’applicazione.

What to check before assuming a rate applies

Conferma cinque elementi prima di usare una tariffa pubblicata in un budget: il modello e il livello di servizio esatti, il prefisso riutilizzabile minimo o i breakpoint espliciti della cache, il costo della prima scrittura o dell’archiviazione, la durata della cache e l’evidenza che le richieste stiano effettivamente colpendo la cache. OpenAI attualmente indica una durata minima della cache di 30 minuti per GPT-5.6, ma questa non è una regola universale di retention. Google pubblica tariffe diverse per i livelli Standard, Batch, Flex e Priority. Anche i gateway possono instradare tra provider o livelli, quindi la route selezionata è importante. La documentazione sul prompt caching di OpenRouter consiglia di controllare i campi di utilizzo della risposta come cached_tokens e cache_write_tokens. Per qualsiasi stima di produzione, confronta la pagina del modello corrente con la fatturazione e i metadati di utilizzo effettivi invece di fare affidamento solo su un’etichetta generale “caching supported”.