De nieuwe cache-prijzen van GPT-5.6 hebben een omslagpunt, en dat is hetzelfde voor Sol, Terra en Luna

Toen OpenAI op 9 juli GPT-5.6 uitbracht in drie varianten (Sol, Terra en Luna), ging de meeste aandacht uit naar de niveaus zelf. De stilletjes doorgevoerde verandering is interessanter: cache-writes worden nu voor het eerst gefactureerd tegen 1,25x het normale input-tarief, terwijl cache-reads hun bestaande korting van 90% behouden. Caching was voorheen vrijwel gratis winst. Nu zijn er kosten aan verbonden, wat betekent dat er ook een punt is waarop het niet langer de moeite waard is.

Waar ligt dat punt precies? We hebben een klein kostenmodel gebouwd om daar achter te komen, voor alle drie de niveaus.

De wiskunde in het kort

Bij een typische agent-workload is er sprake van een grote gedeelde context (system prompt, tool schemas, repo-context) die bij veel calls wordt hergebruikt, plus een klein uniek deel per request. Het omslagpunt komt neer op drie getallen: de volledige input-prijs, de cache-write-prijs en de cache-read-prijs. Als je de verhouding tussen writes en reads berekent waarbij caching evenveel kost als helemaal niet cachen, krijg je één enkele verhouding.

Dit is het deel dat we niet hadden verwacht: die verhouding is identiek voor Sol, Terra en Luna. Writes kunnen tot 78,3% van de requests uitmaken voordat caching niet meer rendeert, en dat getal verandert niet met contextgrootte, request-volume of het niveau dat je gebruikt. OpenAI heeft dezelfde vermenigvuldigingsfactoren van 1,25x/0,10x uniform toegepast op de hele familie, dus de keuze voor een niveau verandert je absolute kosten, niet je caching-strategie.

Waar het echt om gaat: hoeveel je bespaart, niet of je moet cachen

Contextgrootte verandert het omslagpunt niet, maar wel hoeveel er op het spel staat. Bij het toepassen van dezelfde write/read-verhouding op drie contextgroottes:

Bij een kleine gedeelde context (1k tokens) zijn de besparingen reëel maar bescheiden, zelfs bij hoge herhalingspercentages. Bij een grote context (32k tokens, denk aan lange system prompts en grote tool schemas) levert hetzelfde herhalingspercentage aanzienlijk grotere besparingen op, simpelweg omdat er bij elke read meer korting wordt toegepast.

Hoe realistisch verkeer eruitziet

Een vast, zuiver herhalingspercentage is een mooi lesvoorbeeld, maar realistisch agent-verkeer is niet zo netjes. Sessielengtes (hoeveel calls één gecachete context delen voordat deze verandert of verloopt) variëren sterk. We hebben sessielengtes gemodelleerd met een log-normale verdeling (gemiddeld 25 requests per sessie, heavy tail) en kwamen uit op een gesimuleerd write-aandeel van ongeveer 3%, met een mediane sessie van 23 requests en een 90e-percentiel sessie van 58. Dat komt niet eens in de buurt van de drempelwaarde van 78,3%. In deze simulatie kwam caching glansrijk als winnaar uit de bus: de besparingen varieerden van 24% bij een kleine context van 1k tokens tot bijna 80% bij een context van 32k tokens.

De enige foutmodus om voor uit te kijken: context die snel wisselt. Als de gedeelde context van je agent elke paar requests verandert in plaats van tientallen requests te blijven bestaan, kun je aan de verkeerde kant van die drempelwaarde belanden, waardoor caching een kostenpost wordt in plaats van een besparing.

Conclusie

Beoordeel de cache-prijzen van GPT-5.6 niet alleen op basis van de catalogusprijs. Modelleer je eigen write/read-mix afzet tegen de drempelwaarde van 78,3%. Als de context van je agent tientallen requests achter elkaar stabiel blijft, is caching onder de nieuwe prijzen vrijwel zeker nog steeds een duidelijke winst, ongeacht op welk niveau je draait.

Verder lezen

• Provider-agnostische prompt-caching: hoe een LLM-gateway Anthropic, OpenAI en Bedrock normaliseert — dezelfde wiskunde achter cache-economics toegepast op verschillende providers, met een uitgewerkt voorbeeld bij realistische hit rates.
• Semantische caching voor LLM's: voorbij prefix-caching — hoe semantische caching op basis van embeddings verschilt van de prefix-caching waarop de prijzen van GPT-5.6 zijn gebaseerd, en waar het mis kan gaan.
• Kostenoverwegingen bij het gebruik van een AI-gateway — de bredere reeks knoppen (routing, budgetten, caching) die de uitgaven aan LLM's bepalen, buiten de prijzen van één enkel model om.
• LLM-kostenoptimalisatie: waarom een AI-gateway de ontbrekende laag is — een uitgebreidere handleiding over het combineren van caching met routing en on-prem fallbacks voor cumulatieve besparingen.