Prompt caching

Wat is prompt caching?

Bij prompt caching houdt de AI-aanbieder het verwerkte begin van je prompt bij, zodat hij dat stuk bij je volgende oproep niet opnieuw moet uitrekenen. Het model leest nog altijd je volledige prompt. Wat wegvalt, is het herhaalde rekenwerk om diezelfde duizenden tokens instructies en achtergrondinformatie telkens opnieuw te verwerken.

Dat verschil zie je meteen op je factuur. AI-API's rekenen per token, en het vaste begin van een prompt is meestal veruit het grootste deel: de rolbeschrijving, de opmaakregels, een paar uitgewerkte voorbeelden, een productcatalogus, een reglement. Een offertebot stuurt bijvoorbeeld 15.000 identieke tokens mee voor een vraag van 40 tokens. Zonder caching betaal je elke keer voor 15.040 tokens. Met caching betaal je een sterk verlaagd tarief voor die 15.000 en het volle pond voor die 40.

Zie het als een bladwijzer, niet als een geheugen. De aanbieder onthoudt je gesprek niet. Hij onthoudt hoe ver hij geraakt was in het verwerken van één welbepaalde rij tokens, en hij pikt daar enkel weer op als je volgende oproep met exact dezelfde rij begint.

Hoe werkt een prefix cache?

De cache kijkt naar de prefix van je prompt, niet naar de betekenis. De aanbieder berekent een hash van de eerste tokens van je aanvraag en zoekt of daar al een bewaarde versie van bestaat. Azure OpenAI beschrijft de werking heel concreet: aanvragen worden gerouteerd op een hash van het begin van de prompt, meestal de eerste 256 tokens; je prompt moet minstens 1.024 tokens lang zijn om in aanmerking te komen; en die eerste 1.024 tokens moeten identiek zijn. Daarna komt er per 128 bijkomende identieke tokens een stuk cache bij.

Eén gevolg verdient een aparte zin. Eén teken anders in de prefix betekent een cache miss, en alles wat achter dat teken staat wordt aan het volle tarief opnieuw verwerkt. Azure zegt het onomwonden: één karakter verschil in de eerste 1.024 tokens levert je een cached_tokens van nul op.

De prefix wordt in een vaste volgorde samengesteld. Anthropic zet eerst tools, dan system, dan messages, en documenteert dat een wijziging op één niveau ook alle niveaus daarachter ongeldig maakt. Pas je één tooldefinitie aan, dan verdwijnen je system prompt en je hele gespreksgeschiedenis mee uit de cache. Van model wisselen zet je eveneens terug op nul, want een cache hoort bij één model.

Google zegt Gemini-ontwikkelaars hetzelfde, alleen vanuit de andere kant bekeken: zet grote en veelgebruikte inhoud vooraan in je prompt.

Cache writes en cache reads op je factuur

Er bestaan twee soorten cache-tokens en ze kosten niet hetzelfde. Een cache write is de oproep die de prefix wegschrijft. Een cache read is elke latere oproep die dat opgeslagen stuk mag hergebruiken. Anthropic rapporteert beide apart in het antwoord, naast de tokens die helemaal niet gecacht zijn:

"usage": {
  "input_tokens": 40,
  "cache_creation_input_tokens": 15000,
  "cache_read_input_tokens": 0
}

Bij de volgende oproep met dezelfde prefix wisselen die laatste twee getallen van plaats, en net daar zit je besparing. OpenAI en Azure tonen in de plaats daarvan één veld cached_tokens binnen prompt_tokens_details, dat de reads telt.

Anthropic publiceert de vermenigvuldigers ten opzichte van de basisprijs voor input: een write kost 1,25 keer de basisprijs voor de standaardcache van vijf minuten en 2 keer de basisprijs voor de variant van een uur, een read kost 0,1 keer de basisprijs. Reken het even na voor de cache van vijf minuten en je ziet dat die vanaf de tweede oproep opbrengt: 1,25 plus 0,1 is 1,35 tegenover 2,0 voor twee oproepen zonder cache. De cache van een uur heeft een derde oproep nodig voor hij wint, want 2,0 plus 0,1 verliest nog van twee gewone oproepen, terwijl 2,2 wel beter is dan drie.

Bij Azure ligt het anders en is het intussen ook veranderd. Modellen van voor gpt-5.6 rekenen niets aan om naar de cache te schrijven; vanaf gpt-5.6 worden writes wel aangerekend, bovenop de verlaagde reads. Ga de actuele prijspagina na voor je een businesscase op deze cijfers bouwt, want dit is net het stuk dat regelmatig beweegt.

De volgorde van je prompt bepaalt de prijs

Twee teams kunnen exact dezelfde functie bouwen, exact evenveel tokens versturen, en toch facturen krijgen die een factor vijf verschillen. Meestal zit het verschil in de volgorde.

Dit is de misser waar bijna iedereen intrapt. Je assistent heeft een groot vast instructieblok, en iemand zet er bovenaan een nuttig lijntje bij: Huidig tijdstip: 2026-07-20 14:32:07. Die regel staat voor al de rest, dus de hash van je prefix verandert bij elke oproep. Je schrijft nu bij elke aanvraag een nieuwe cache weg, betaalt telkens de meerprijs voor die write, en leest er nooit één terug. De functie staat aan, je factuur is slechter dan zonder, en nergens in het antwoord staat dat er iets scheelt.

De oplossing is een volgorderegel die bij elke aanbieder werkt:

1. Vaste inhoud eerst. De instructies, tooldefinities en referentiedocumenten die bij elke aanvraag in het systeem letterlijk hetzelfde zijn.

2. Daarna wat per sessie stilstaat. Zaken die binnen één klant of één gesprek niet meer veranderen, zoals een opgehaald klantendossier.

3. Wisselende inhoud helemaal achteraan. Tijdstippen, aanvraagnummers, de eigenlijke vraag van je gebruiker. Azure schrijft dezelfde volgorde voor: stabiele inhoud zoals systeeminstructies en voorbeelden vooraan, variabele inhoud achteraan.

Ook de manier waarop je data serialiseert telt mee. Een dictionary die je naar JSON schrijft zonder de sleutels te sorteren, of een set die je uitleest in de volgorde die hij toevallig teruggeeft, levert bij elke run andere bytes op, ook al is de inhoud dezelfde. De cache ziet een andere prefix en mist.

Waar moet je op letten bij het gebruik van prompt caching

Een cache leeft korter dan je denkt. De in-memory cache van Azure wordt doorgaans na vijf tot tien minuten zonder activiteit opgeruimd en is sowieso binnen het uur weg. De standaardcache van Anthropic leeft vijf minuten en wordt gratis ververst telkens je hem gebruikt. Langer bewaren kan aan beide kanten: tot een uur bij Anthropic en tot 24 uur met de uitgebreide bewaartermijn van Azure. Een toepassing met om de dertig seconden een oproep houdt haar eigen cache dus warm; een toepassing met één oproep per uur cacht in de praktijk niets en betaalt elke keer opnieuw de write.

Anthropic formuleert die verversing letterlijk zo: standaard leeft de cache vijf minuten, en hij wordt zonder extra kost ververst telkens de gecachte inhoud gebruikt wordt.

Meten in plaats van veronderstellen. De cachevelden in het antwoord zijn het enige eerlijke signaal dat je hebt. Blijft de teller voor reads op nul staan bij oproepen die dezelfde prefix zouden moeten delen, dan verandert er iets vooraan. Vergelijk de bytes van twee opeenvolgende prompts en je vindt het.

Personalisatie hakt je cache in stukken. Zet je een klantnaam of dossiernummer in je system prompt, dan krijgt elke gebruiker zijn eigen prefix en deelt niemand nog iets. Schuif die gegevens achter het vaste blok.

Korte prompts komen niet in aanmerking. De ondergrens ligt rond de duizend tokens bij OpenAI en Azure en op een paar duizend bij de recente Gemini-modellen. Zit je eronder, dan wordt je prompt gewoon zonder cache verwerkt en krijg je geen foutmelding. En als je prompt echt bij elke oproep anders begint, dan is er geen herbruikbare prefix en is caching niet de knop die je zoekt.

Verschillen tussen de aanbieders

Het mechanisme is overal hetzelfde, de bediening niet.

Anthropic geeft je expliciete controle. Je duidt met een veld cache_control aan waar de cache stopt, maximaal vier keer per aanvraag, en alles tot dat punt wordt bewaard. Die precisie is handig, maar ze is ook de scherpe kant: zet je dat punt achter een blok met een tijdstip in, dan betaal je bij elke oproep een write zonder ooit een read te krijgen. Het breekpunt hoort op het laatste blok dat identiek blijft over de oproepen die samen één cache moeten delen.

OpenAI en Azure OpenAI cachen automatisch voor aanvragen die in aanmerking komen. Je hoeft niets aan te passen en je kan het ook niet uitzetten. Recentere modellen aanvaarden een prompt_cache_key die je hergebruikt bij aanvragen met dezelfde prefix, wat de matching verbetert. Azure vermeldt dat bij meer dan ongeveer 15 aanvragen per minuut op dezelfde combinatie van prefix en sleutel een deel de cache mist, dus spreid drukke toepassingen over meerdere sleutels en houd per sleutel dezelfde prefix aan.

Google Gemini cacht bij de recente modellen impliciet en standaard, en biedt daarnaast expliciete caches die je zelf aanmaakt en beheert. De minimumlengtes verschillen per model en liggen in de orde van enkele duizenden tokens.