Prijzen voor gecachede invoer van GPT 5.6 en Gemini 3.6 Flash: wat het kost

DR

Geheugenprijsstelling voor invoer kan de kosten van workloads die een grote, ongewijzigde promptprefix opnieuw verzenden materieel verlagen, maar de besparing hangt af van model-specifieke regels voor cache-lezen, cache-schrijven, opslag, routing en retentie. Een algemene “caching ondersteund”-label is onvoldoende om kosten te schatten; gebruik de huidige prijs die is gepubliceerd voor het exacte model en de route.

TL;DR

• GPT-5.6 Terra heeft expliciete cache-lees- en cache-schrijfprijzen van OpenAI, CometAPI en OpenRouter, hoewel gatewayroutes en long-context-tiers de hoeveelheid kunnen veranderen.
• Google publiceert een tarief van $0.15 per 1M tokens voor Standard context-caching voor Gemini 3.6 Flash plus een opslagkosten; CometAPI publiceert momenteel de standaard input- en outputprijzen van het model zonder een aparte regel voor gecachte invoer.
• De relevante vergelijking is niet alleen standaard invoer versus cache-lezen. Het omvat ook de eerste cache-write, eventuele opslagkosten, cachelevensduur, routeconsistentie en het aantal latere cache-hits.

Key messages

• Controleer prijzen op model- en serviceniveauniveau in plaats van een gatewaybrede multiplier toe te passen.
• Houd cache-lezen, cache-schrijven, opslag en response-caching gescheiden in kostencalculaties.
• Verifieer daadwerkelijke cache-gebruik in API-responsemetadata voordat je besparingen op basis van het gepubliceerde tarief voorspelt.

Een request dat een grote, ongewijzigde prefix herhaalt — een systeemprompt, een set toolschema’s, een lang referentiedocument — hoeft niet bij elke call tegen het volledige invoertarief gefactureerd te worden. De meeste modellen van de huidige generatie ondersteunen een vorm van prijsstelling voor gecachte invoer: een gereduceerd tarief voor het deel van een prompt dat een provider herkent als recent al verwerkt. Het mechanisme, de korting en hoe duidelijk het wordt gepubliceerd verschillen per provider en per gateway, en die variatie is het waard om specifiek te benoemen in plaats van “caching wordt ondersteund” als één uniforme feature te behandelen.

What cached input pricing is, and isn't

Prijsstelling voor gecachte invoer geeft korting op de invoertokens in een request die overeenkomen met een eerder verzonden prefix. Het geeft geen korting op uitvoertokens, en het is niet hetzelfde als een gateway die twee volledig identieke requests dedupliceert en één response gratis retourneert — dat is een ander mechanisme dat sommige gateways afzonderlijk aanbieden. Prijsstelling voor gecachte invoer gaat specifiek over minder betalen voor het deel van een prompt dat een modelprovider onlangs al heeft gezien, niet over het volledig overslaan van generatie.

Het is ook niet gratis om te creëren. OpenAI’s GPT-5.6-prijsinformatie stelt dat cache-writes worden gefactureerd tegen 1.25 keer het niet-gecachede invoertarief, terwijl cache-reads 90% korting krijgen. Die first-write-premie beïnvloedt het break-evenpunt en is gemakkelijk te missen als een vergelijking alleen het kortingspercentage voor lezen toont. Andere providers kunnen opslaggebaseerde kosten gebruiken in plaats van hetzelfde schrijfmachmodel, dus schrijf- en opslagkosten moeten afzonderlijk worden gecontroleerd.

In de praktijk is de factureerbare cache-eenheid meestal een herbruikbare promptprefix in plaats van een willekeurige verzameling herhaalde zinnen. Providers tokeniseren en matchen content op volgorde, dus het herbruikbare materiaal moet vóór de request-specifieke staart verschijnen. Stabiele systeeminstructies, tooldefinities, beleidsregels en referentiemateriaal horen dichtbij het begin; een veranderend gebruikersbericht, tijdstempel, request-ID of opgehaald fragment hoort later. Zelfs een semantisch onschuldige wijziging vroeg in de prompt kan tokenisatie verschuiven of de match voor alles wat volgt breken.

Geschiktheidsregels zijn ook modelspecifiek. Een provider kan een minimale promptlengte vereisen, alleen gedocumenteerde breekpunten herkennen of een expliciet cache-control-veld blootleggen. Een cache-item kan tussen calls verlopen, en een gateway kan gerelateerde requests op een compatibele upstreamroute moeten houden. Dat betekent dat een deployment een cache-hit als een geobserveerde uitkomst moet behandelen, niet als een aanname op basis van promptgelijkheid. Een goed gestructureerde prompt verhoogt de kans op hergebruik, maar de responsemetadata en de factuur bepalen of het kortingspercentage daadwerkelijk is toegepast.

What's actually published, by model and by gateway

De onderstaande tabel is een prijsmomentopname gecontroleerd op 29 juli 2026. Prijzen zijn in Amerikaanse dollars per 1 miljoen tokens tenzij een andere eenheid is vermeld. De rijen vergelijken actuele openbare informatie voor GPT-5.6 Terra en Gemini 3.6 Flash over de modelprovider, CometAPI en OpenRouter; ze moeten niet als een permanent tarief worden behandeld.

Lees de tabel als een model- en route-specifieke momentopname. De CometAPI GPT-5.6-modelpagina specificeert GPT-5.6 Terra op $2.00 standaard invoer, $0.20 gecachte invoer en $2.50 cache-schrijven per 1 miljoen tokens. De Gemini 3.6 Flash-modelpagina publiceert momenteel $1.20 invoer en $6.00 uitvoer, maar toont geen aparte prijs voor gecachte invoer of cache-opslag. Google’s Gemini Developer API-prijzen vermelden de Standard-laag op $1.50 invoer, $0.15 context-caching en $1.00 per 1 miljoen tokens per uur voor opslag. OpenRouter stelt nu modelspecifieke cachevelden bloot via zijn Models API: de standaardroute van GPT-5.6 Terra omvat lagere promotieprijzen en een aparte hogere laag voor lange context, terwijl de Gemini 3.6 Flash-vermelding verschillende waarden voor Standard, Flex en Priority toont. Dit is nauwkeuriger dan één generieke cache-multiplier op elk model toepassen.

Why gateway and provider prices can diverge

Een gatewayprijs is niet noodzakelijk een opslag op één onveranderlijke upstream-lijstprijs. Het kan onderhandelde capaciteit, een tijdelijke promotie, een ander serviceniveau of een route-specifieke commerciële afspraak weerspiegelen. Een modelnaam kan ook naar meerdere upstreamvarianten verwijzen waarvan de prijzen veranderen met contextlengte of latentiegaranties. De GPT-5.6 Terra-vermelding van OpenRouter publiceert bijvoorbeeld een standaardroute en een hoger geprijsde override zodra de invoer zijn long-context-drempel bereikt. Google scheidt Standard-, Batch-, Flex- en Priority-prijzen voor Gemini 3.6 Flash. Eén vergelijkingsrij heeft daarom een datum, route, niveau en contextaanname nodig om zinvol te blijven.

Het omgekeerde is ook belangrijk: als een gatewaypagina geen aparte cache-leesregel publiceert, mag die afwezigheid niet worden omgezet in “caching is niet beschikbaar” of “de directe korting van de provider is automatisch van toepassing.” De gateway kan een upstream-feature doorgeven zonder die uit te splitsen, die alleen op bepaalde routes blootleggen, of het request onder zijn normale invoertarief factureren. De verdedigbare aanpak is om de eigen, actuele modelpagina van de gateway voor planning te gebruiken en vervolgens het daadwerkelijke tarief te bevestigen aan de hand van gebruiksrecords of factureringsdata. Providerdocumentatie blijft nuttig om het mechanisme te begrijpen, maar stelt op zichzelf de commerciële voorwaarden van een intermediair niet vast.

Where the discount actually matters

Het scenario waarin dit de werkelijke kosten betekenisvol verandert, is een grote, statische prefix gekoppeld aan een kleine, variabele vraag — een systeemprompt of set toolschema’s die bij elke call in een agentloop opnieuw wordt verzonden, een lang referentiedocument dat herhaaldelijk met verschillende vragen wordt bevraagd, of conversatiegeschiedenis die bij elke chatbotbeurt opnieuw wordt verzonden. Voor zo’n workload neemt het gat tussen elke keer de volledige invoerprijs over de hele prefix betalen versus de schrijfpremie één keer en daarna het verlaagde leestarief betalen toe met het callvolume. Het doet niets voor workloads die geen prefix herhalen — een eenmalig request heeft in de eerste plaats geen gecachte content om te korten.

Een praktische break-evenberekening vergelijkt de niet-gecachede kosten van de herhaalde prefix over alle calls met de cache-schrijf- of opslagkosten plus verlaagde cache-lezingen bij latere calls. Het resultaat hangt af van prefixgrootte, het aantal succesvolle cache-hits, cache-verval en of de gateway requests op een compatibele providerroute houdt. Als die voorwaarden instabiel zijn, kan de headline-korting de besparingen die in productie worden gerealiseerd overschatten.

A simple cost model for a repeated prefix

Laat P het aantal tokens in de stabiele prefix zijn en N het aantal calls dat deze hergebruikt. Als U de niet-gecachede invoerprijs per token is, kost de prefix N × P × U zonder caching. Een vereenvoudigde gecachte schatting is P × W + (N − 1) × P × R + S, waarbij W de cache-schrijfprijs is, R de cache-leesprijs en S eventuele opslagkosten over de periode. De formule gaat ervan uit dat de eerste call de cache creëert en elke latere call een succesvolle hit is. Zij sluit de variabele staart van elk request, uitvoertokens, herpogingen en elke routewijziging die een miss veroorzaakt uit.

Beschouw een illustratieve prefix van 100,000 tokens die voor 20 calls wordt hergebruikt tegen het officiële GPT-5.6 Terra-tarief. Bij $2.50 per 1 miljoen niet-gecachede invoertokens zou het herhaald verwerken van die prefix $5.00 kosten. Met het gepubliceerde 1.25× schrijftarief en 90% verlaagd leestarief zou één write van 100,000 tokens ongeveer $0.3125 kosten en negentien reads ongeveer $0.475, voor een gecombineerde prefixkost van ruwweg $0.7875. Het verschil is ongeveer $4.21 vóór variabele invoer- en uitvoerkosten. Dit is een illustratie, geen offerte: het geldt alleen als alle negentien latere calls dezelfde geldige cache raken en er geen extra opslag- of routingkosten van toepassing zijn.

Het break-evenpunt volgt rechtstreeks uit hetzelfde model. Een schrijfpremie is alleen gerechtvaardigd wanneer genoeg verlaagde reads plaatsvinden vóór expiratie. Voor een workload met korte sessies, frequente promptwijzigingen of zwakke route-affiniteit kan de cache vaker worden hergecreëerd dan verwacht. Voor een langdurige agentloop of herhaalde documentanalyse met een stabiele prefix kan het aantal hits veel hoger zijn. Prognoses moeten daarom een geobserveerd hitratiebereik gebruiken in plaats van een perfect verloop na de eerste call aan te nemen.

Implementation patterns that improve cache reuse

Promptconstructie heeft een grotere invloed op de hitratio dan veel prijsspreadsheets suggereren. Plaats het meest stabiele materiaal eerst en houd de serialisatie deterministisch: systeeminstructies, toolschema’s, beleidstekst en gedeelde referentiecontext moeten dezelfde volgorde, whitespace en veldrepresentatie behouden over gerelateerde calls. Voeg vluchtige inhoud daarna toe. Vermijd het injecteren van tijdstempels, willekeurige identifiers, continu veranderende tellers of request-specifieke retrievalresultaten in de herbruikbare prefix, tenzij ze daar echt vereist zijn.

Versieer stabiele inhoud doelbewust. Als een toolschema of beleid verandert, wijs de nieuwe versie consequent toe in plaats van meerdere bijna identieke varianten te laten circuleren. Voor conversatie- of agentische workloads kun je een stabiele sessie-ID of cache-sleutel hergebruiken wanneer de API die ondersteunt, en vermijd het wisselen van provider binnen dezelfde cache-afhankelijke sequentie. OpenRouter documenteert provider-sticky routing voor promptcaching en stelt besturingselementen bloot zoals session_id en prompt_cache_key; die controles kunnen de continuïteit verbeteren, maar ze garanderen geen hit wanneer de upstreamcache koud of verlopen is.

Applicaties moeten ook netjes terugvallen bij een miss. Caching is een kosten- en latentie-optimalisatie, geen afhankelijkheid voor correctheid. Het request moet nog steeds hetzelfde geldige resultaat opleveren wanneer de cache niet beschikbaar is, en herpogingslogica mag niet blind herhaalde writes creëren. Die scheiding maakt het veiliger om routes te vergelijken: teams kunnen cachingbeleid of gatewayconfiguratie wijzigen zonder het semantische gedrag van de applicatie te veranderen.

How to verify cache economics in production

Begin met telemetrie per verzoek in plaats van met de maandelijkse factuur. Log de exacte modelidentifier, gatewayroute of provider wanneer blootgelegd, serviceniveau, totaal aantal invoertokens, cached-read-tokens, cache-write-tokens, uitvoertokens, latentie en gefactureerde kosten. Het usage-object van OpenRouter bevat cached_tokens en cache_write_tokens; andere providers leggen equivalente details onder verschillende veldnamen bloot. Bewaar ruwe gebruiksvelden zodat een latere prijswijziging het bewijs dat nodig is om kosten te reconstrueren niet uitwist.

Aggregeer de gegevens per promptversie en workload, niet alleen per model. Nuttige maten omvatten het aandeel van in aanmerking komende requests die een cache raken, het aandeel invoertokens dat tegen het leestarief is gefactureerd, writes per succesvolle read, tijd tussen write en laatste hit, en gerealiseerde kosten per request. Een hoge hitratio op verzoekniveau kan nog steeds weinig waarde opleveren als de gecachte prefix klein is, terwijl een lagere hitratio op een zeer grote prefix meer kan besparen. Combineer die maten met latentiepercentielen, omdat een goedkopere route die herhaaldelijk mist of reroute, operationeel slechter kan zijn.

Evalueer ten slotte anomalieën in plaats van ze weg te middelen. Een plotselinge daling in gecachte tokens kan wijzen op een promptversie-uitrol, onstabiele serialisatie, verlopen entries, een drempel van de laag voor lange context, of een gatewayroutewijziging. Vergelijk de getroffen requests met de huidige modelpagina en providerdocumentatie, en verifieer vervolgens het gefactureerde tarief. Dit verkleint de kloof tussen een gepubliceerde korting en de besparingen die de applicatie daadwerkelijk realiseert.

What to check before assuming a rate applies

Bevestig vijf punten voordat je een gepubliceerd tarief in een budget gebruikt: het exacte model en serviceniveau, de minimale herbruikbare prefix of expliciete cachebreekpunten, de first-write- of opslagkosten, de cachelevensduur, en bewijs dat requests de cache daadwerkelijk raken. OpenAI stelt momenteel een minimale cachelevensduur van 30 minuten voor GPT-5.6, maar dat is geen universele retentieregel. Google publiceert verschillende tarieven voor de Standard-, Batch-, Flex- en Priority-serviceniveaus. Gateways kunnen ook tussen providers of niveaus routen, dus de geselecteerde route is van belang. OpenRouter’s promptcaching-documentatie raadt aan om responagebruikvelden zoals cached_tokens en cache_write_tokens te controleren. Gebruik voor elke productie-inschatting de huidige modelpagina en vergelijk die met daadwerkelijke facturering en gebruiksmetadata in plaats van alleen op een algemene “caching ondersteund”-label te vertrouwen.