Door Wanneer is Claude prompt caching rendabel?
Cache-schrijfacties kosten 1,25x en leesacties 0,1x de basisprijs. Ontdek hier de wiskundige formule om te berekenen vanaf welk aantal verzoeken u daadwerkelijk bespaart.
Wanneer prompt caching kosten bespaart
Met prompt caching kan Claude het begin van uw prompt hergebruiken in plaats van dit bij elke aanroep opnieuw te lezen. De afweging hangt af van twee vermenigvuldigers op de basisprijs voor invoer van uw model. Sinds augustus 2026 kost een cache-schrijfactie 1,25x de basisinvoerprijs voor een levensduur van 5 minuten, of 2x voor een levensduur van 1 uur. Een cache-leesactie kost 0,1x. Deze vermenigvuldigers gelden voor het gehele modeloverzicht, waardoor het omslagpunt niet verandert wanneer de prijs per token wijzigt.
Het is een ruil tussen een toeslag nu en een korting later. U betaalt eenmalig extra om een voorvoegsel op te slaan. Elk volgend verzoek dat begint met exact dezelfde bytes, betaalt vervolgens een tiende van de normale invoerprijs voor dat gedeelte. Een voorvoegsel dat binnen de levensduur nooit wordt hergebruikt, heeft u 25 procent extra gekost zonder resultaat.
Het break-evenpunt in één algebraïsche vergelijking
Noem B de basisinvoerkosten van het prefix als u deze zonder caching verstuurt. Zonder caching kosten N verzoeken N maal B. Met de cache van 5 minuten schrijft het eerste verzoek het prefix tegen 1,25B en lezen de overige N min 1 verzoeken dit tegen 0,1B. Stel deze twee aan elkaar gelijk en u krijgt 0,9N = 1,15, dus N = 1,28. Het tweede verzoek is al goedkoper dan helemaal niet cachen.
Herhaal dit met de 2x schrijfkosten van de cache van 1 uur en u krijgt 0,9N = 1,9, dus N = 2,11. De lange cache heeft twee leesacties nodig voordat het break-evenpunt wordt bereikt; daarom is dit niet de standaardkeuze.
De onderstaande grafiek berekent dit voor een prefix van 20.000 tokens op Claude Opus 5, waarvan het basistarief voor invoer per augustus 2026 $5 per miljoen tokens bedraagt. Schaal elk cijfer met 0,6 voor een model van $3 per miljoen. De vorm van de curve verandert niet.
The data behind this chart
[
{
"requests": 1,
"uncached_usd": "0.10",
"cached_5m_usd": "0.125",
"cached_1h_usd": "0.20"
},
{
"requests": 2,
"uncached_usd": "0.20",
"cached_5m_usd": "0.135",
"cached_1h_usd": "0.21"
},
{
"requests": 3,
"uncached_usd": "0.30",
"cached_5m_usd": "0.145",
"cached_1h_usd": "0.22"
},
{
"requests": 5,
"uncached_usd": "0.50",
"cached_5m_usd": "0.165",
"cached_1h_usd": "0.24"
},
{
"requests": 10,
"uncached_usd": "1.00",
"cached_5m_usd": "0.215",
"cached_1h_usd": "0.29"
},
{
"requests": 20,
"uncached_usd": "2.00",
"cached_5m_usd": "0.315",
"cached_1h_usd": "0.39"
}
]Eén enkel verzoek kost $0.10 zonder caching en $0.125 met caching, dus het cachen van een eenmalige prompt is puur verlies. Bij het tweede verzoek staat de cache van 5 minuten op $0.135 tegenover $0.20. De cache van 1 uur loopt op dat punt nog achter, $0.21 tegenover dezelfde $0.20, en deze passeert de lijn zonder caching pas bij het derde verzoek: $0.22 tegenover $0.30. Bij 20 verzoeken is het verschil $2.00 tegenover $0.315.
Een cache-hit ververst ook het item, wat de reden is dat de gepubliceerde prijstabel die kolom cache-hits en verversingen noemt. Een druk eindpunt houdt een item van 5 minuten daarom voor onbepaalde tijd in leven tegen leestarieven, en de levensduur van 1 uur verdient zijn 2x schrijfkosten alleen terug wanneer uw verkeer daadwerkelijke hiaten vertoont.
Wat een lage hit rate kost
Echt netwerkverkeer mist de cache. Een verzoek dat de cache mist maar wel een breakpoint bevat, wordt in rekening gebracht als een schrijfoperatie. De eerlijke manier om dit te modelleren is daarom de kosten als functie van de hit rate. De onderstaande grafiek toont dit voor 1.000 verzoeken, elk met hetzelfde prefix van 20.000 tokens.
The data behind this chart
[
{
"hit_rate_percent": 0,
"cost_5m_usd": "125.00",
"cost_1h_usd": "200.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 25,
"cost_5m_usd": "96.25",
"cost_1h_usd": "152.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 50,
"cost_5m_usd": "67.50",
"cost_1h_usd": "105.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 75,
"cost_5m_usd": "38.75",
"cost_1h_usd": "57.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 90,
"cost_5m_usd": "21.50",
"cost_1h_usd": "29.00",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 95,
"cost_5m_usd": "15.75",
"cost_1h_usd": "19.50",
"uncached_usd": "100.00"
},
{
"hit_rate_percent": 99,
"cost_5m_usd": "11.15",
"cost_1h_usd": "11.90",
"uncached_usd": "100.00"
}
]Bij een hit rate van 0 procent betaalt u $125.00 in plaats van $100.00, en de cache van 1 uur verdubbelt de rekening naar $200.00. Los 1.25 min 1.15h = 1 op en de cache van 5 minuten begint geld te besparen bij een hit rate van ongeveer 22 procent; daarom toont 25 procent al $96.25. Dezelfde berekening voor de 2x schrijfoperatie geeft ongeveer 53 procent voor de cache van 1 uur, waardoor een hit rate van 50 procent nog steeds $105.00 kost, wat boven de lijn voor ongecachte verzoeken ligt. Bij 90 procent komen de twee uit op $21.50 en $29.00. Bij 99 procent bereikt de korte cache $11.15, dicht bij de ondergrens van een tiende van de ongecachte prijs.
De hit rate is de waarde die u moet monitoren, omdat dit de enige variabele is die u beheert nadat de prefixgrootte is vastgesteld.
Welke prefixen zijn een breakpoint waard
Een verzoek kan maximaal vier cache-breakpoints bevatten, dus de vraag is welke blokken er een verdienen. De kandidaten zijn blokken die bij verschillende aanroepen byte-identiek zijn en groot genoeg zijn om relevant te zijn. De onderstaande tabel toont de kosten van vier veelvoorkomende vormen over 1.000 verzoeken bij een hitrate van 90 procent op de 5-minuten-cache.
The data behind this chart
[
{
"label": "System prompt",
"prefix_size_tokens": "2,000",
"uncached_usd": "10.00",
"cached_usd": "2.15",
"saved_usd": "7.85"
},
{
"label": "System plus tools",
"prefix_size_tokens": "8,000",
"uncached_usd": "40.00",
"cached_usd": "8.60",
"saved_usd": "31.40"
},
{
"label": "Policy document",
"prefix_size_tokens": "25,000",
"uncached_usd": "125.00",
"cached_usd": "26.88",
"saved_usd": "98.12"
},
{
"label": "Codebase context",
"prefix_size_tokens": "120,000",
"uncached_usd": "600.00",
"cached_usd": "129.00",
"saved_usd": "471.00"
}
]Een kaal 2,000 token systeem-prompt bespaart $7.85 per 1.000 verzoeken ten opzichte van $10.00 zonder caching. Dit is echt geld bij grote volumes, maar dat is niet wat caching interessant maakt. Voeg de tooldefinities toe en u zit op 8,000 tokens en $31.40 besparing. Een 25,000 token beleidsdocument waar elk verzoek vragen over stelt, bespaart $98.12. De laatste rij is degene die de architectuur verandert: 120,000 tokens aan codebase- of transcriptcontext kost $600.00 zonder caching en $129.00 met caching, een besparing van $471.00.
Besparingen schalen met de prefixgrootte en de hitrate, en met niets anders. Dat verandert wat het waard is om überhaupt in een prompt op te nemen: wat een miljoen Claude tokens werkelijk kost daalt tot een tiende van de catalogusprijs voor alles wat u vaker dan één keer verstuurt.
Hoe dit eruitziet op een maandelijkse factuur
De onderstaande grafiek gebruikt het 8,000 token-prefix van hierboven, een systeemprompt plus tooldefinities, bij een hitrate van 90 procent, en schaalt dit naar maandelijkse aanvraagvolumes.
The data behind this chart
[
{
"label": "10k requests",
"uncached_usd": "400.00",
"cached_usd": "86.00",
"saved_usd": "314.00"
},
{
"label": "100k requests",
"uncached_usd": "4,000.00",
"cached_usd": "860.00",
"saved_usd": "3,140.00"
},
{
"label": "1M requests",
"uncached_usd": "40,000.00",
"cached_usd": "8,600.00",
"saved_usd": "31,400.00"
}
]Bij 10.000 aanvragen per maand bedraagt de besparing $314.00, het verschil tussen $400.00 en $86.00. Bij 100.000 aanvragen is dit $3,140.00. Bij een miljoen aanvragen is de factuur voor ongecachte input $40,000.00 en caching verwijdert daar $31,400.00 van. Dit betreft uitsluitend input-tokens. Output wordt afzonderlijk geprijsd en caching heeft hier geen invloed op; dit is belangrijk om te onthouden voordat u iemand een factuurverlaging van 90 procent belooft. Caching is een aanvulling op de bredere gewoonten voor het beheersen van de kosten van een AI-agent op een VPS.
Hoe u controleert of de cache werkt
Vertrouw niet blindelings op het ontwerp. Lees het gebruiksblok in het antwoord. Elk antwoord van de Messages API (application programming interface) rapporteert de gecachte tokens die zijn geschreven, de gecachte tokens die zijn gelezen en de nieuwe tokens die moesten worden verwerkt.
from anthropic import Anthropic
client = Anthropic()
resp = client.messages.create(
model="claude-opus-5",
max_tokens=512,
system=[
{
"type": "text",
"text": POLICY_DOCUMENT,
"cache_control": {"type": "ephemeral"},
}
],
messages=[{"role": "user", "content": question}],
)
u = resp.usage
print("write:", u.cache_creation_input_tokens)
print("read: ", u.cache_read_input_tokens)
print("fresh:", u.input_tokens)Voer het twee keer uit met hetzelfde document en een andere vraag. De eerste aanroep rapporteert een cache_creation_input_tokens die niet nul is en een cache_read_input_tokens van nul. De tweede aanroep draait dit om, omdat het voorvoegsel werd gevonden. input_tokens telt alleen de tokens na het laatste breekpunt; bij een correcte tweede aanroep is dit getal dus klein, meestal alleen het nieuwe gebruikersbericht. Beide aanroepen worden gefactureerd, omdat de Claude API geen gratis laag heeft, hoewel de kosten voor het voorvoegsel van 20.000 tokens in dit voorbeeld ongeveer veertien cent bedragen.
Dezelfde controle vanaf de shell, tegenover een request body die u heeft opgeslagen in request.json:
curl -s https://api.anthropic.com/v1/messages \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d @request.json | jq '.usage'Een correcte tweede aanroep toont een resultaat dat er ongeveer zo uitziet:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}Eén regel vertelt u de waarheid. Als cache_read_input_tokens bij opeenvolgende aanroepen op 0 blijft staan, betaalt u elke keer de 1,25x schrijf-toeslag zonder dat u hiervan profiteert.
Voor de levensduur van 1 uur bevat het breekpunt een time to live (TTL):
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}Er is ook automatische caching: een enkel cache_control-veld op het hoogste niveau van het verzoek, waarna de API de breekpunten beheert naarmate het gesprek groeit. Dit verbruikt een van uw vier beschikbare breekpunten. Begin hiermee. Stap over op expliciete breekpunten wanneer u precies wilt bepalen waar de grens ligt.
De volgorderegel die cache-hitrates tenietdoet
De cache matcht een prefix byte-voor-byte vanaf het begin van het verzoek, en het verzoek wordt in een vaste volgorde samengesteld: tools, dan system, dan messages. Een wijziging op welk niveau dan ook maakt dat niveau en alles wat daarna komt ongeldig. Bewerk één toolbeschrijving en de system prompt en de volledige berichtgeschiedenis worden daarmee ongeldig, ook al heeft u deze niet aangepast.
Dit leidt tot één regel zonder uitzonderingen. Alles wat verandert tussen aanroepen moet na alles komen wat niet verandert.
De gebruikelijke boosdoener is een tijdstempel. Een regel met Current time: 2026-08-03T14:07:11Z bovenaan een system prompt garandeert een hitrate van 0 procent, omdat de prefix-hash bij elke aanroep anders is en geen enkele eerdere invoer ooit kan matchen. Verplaats deze naar het gebruikersbericht, aan het einde. Een sessie-identifier of een nonce per verzoek verstoort de werking op dezelfde manier en vereist dezelfde oplossing. Opgehaalde documenten die per verzoek verschillen, horen ook na het gecachte blok, anders duwen ze elk stabiel token achter een grens die verschuift.
De tweede boosdoener is het plaatsen van het breekpunt op het blok dat verandert. Cache-schrijfacties vinden plaats bij het breekpunt; als dat blok dus elke keer anders is, wordt er niets stabiels opgeslagen en vindt de lookback alleen invoer die eerdere verzoeken op hun eigen verschuivende breekpunten hebben geschreven. Plaats cache_control op het laatste blok waarvan de inhoud identiek is over alle verzoeken heen.
De derde is een parameterwijziging waarvan u niet dacht dat deze als promptinhoud gold. Een ander model heeft een andere cache. Het wijzigen van de toolkeuze maakt alles vanaf het system-niveau ongeldig. Het toevoegen of verwijderen van een tool maakt alles ongeldig.
Het minimale voorvoegsel en de stille no-op
Een voorvoegsel dat korter is dan het minimum van het model wordt niet gecachet, en u krijgt hierover geen melding. Er is geen foutmelding en geen waarschuwing. Het verzoek slaagt en beide tellers staan op 0. Sinds augustus 2026 zijn de gepubliceerde minima als volgt:
- 512 tokens voor Claude Opus 5 en Claude Fable 5
- 1.024 tokens voor Claude Sonnet 5 en Claude Opus 4.8
- 4.096 tokens voor Claude Haiku 4.5
Als beide tellers op 0 staan bij een verzoek waarvan u verwacht dat het gecachet is, controleer dan als eerste de lengte van het voorvoegsel. Dit is ook de reden waarom het goedkoopste model niet automatisch het goedkoopste is voor een caching-workload. Haiku 4.5 heeft een voorvoegsel nodig dat acht keer langer is dan dat van Opus 5 voordat caching überhaupt wordt geactiveerd. Een systeem-prompt van 2.000 tokens wordt dus bij de een wel gecachet en bij de ander stilzwijgend genegeerd.
Waar Claude Code voor u cachet, en waar dit niet mogelijk is
Claude Code cachet zijn eigen prefix. De system prompt en de tooldefinities staan aan het begin van elk verzoek en veranderen niet; ze worden dus eenmaal geschreven en voor de rest van de sessie uitgelezen. Daarom liggen de kosten per beurt van een lange sessie ver onder wat de contextgrootte doet vermoeden, en dit is terug te zien in de tellers die worden beschreven in hoe Claude Code tokengebruik rapporteert.
Waar het u niet kan helpen, is bij een wijziging nabij het begin van de context. De gespreksgeschiedenis is alleen-toevoegen (append-only), dus gewone nieuwe beurten breiden een prefix uit die al gecachet is. Het bewerken van een bestand dat vroeg in de sessie is gelezen, wijzigt de inhoud in het midden van die prefix, waardoor elk token na de wijziging opnieuw moet worden geschreven. Een lange periode van inactiviteit heeft hetzelfde effect, omdat het item verloopt en de volgende beurt een volledige schrijfactie vereist. Geen van beide is een bug. In beide gevallen doet de prefix-regel precies wat deze moet doen.
Als u in plaats daarvan uw eigen client schrijft, pas dan de lay-out van het eerste verzoek toe in plaats van deze achteraf aan te passen: bouw de aanroep op zoals een eerste Claude API-app op een VPS dat doet, met de stabiele blokken eerst en de volatiele blokken als laatste.
Foutmodi en wat u zult zien
Elke aanroep is een schrijfactie. cache_creation_input_tokens is ongelijk aan nul bij elk verzoek, terwijl cache_read_input_tokens op 0 blijft staan. Er verandert iets op of vóór het breekpunt tussen de aanroepen. Print de eerste 200 tekens van uw samengestelde prefix bij twee opeenvolgende verzoeken en vergelijk deze visueel.
Beide tellers staan op 0. De prefix is kleiner dan het minimum van het model, of het veld cache_control heeft de API nooit bereikt. Tel eerst de prefix-tokens en log vervolgens de request body die u daadwerkelijk heeft verzonden.
Leesacties werken, maar stoppen dan. Een reeks treffers, gevolgd door een schrijfactie, en daarna weer treffers. De pauze tussen de verzoeken was langer dan de levensduur. Accepteer de schrijfactie of stap over op de TTL van 1 uur zodra u heeft gecontroleerd of uw hitrate boven de 53 procent uitkomt.
Hitrate daalt na een deploy. Een beschrijving van een tool is bewerkt of een model is gewijzigd. Beide acties maken de volledige prefix ongeldig. Houd rekening met één kostbare ronde aan schrijfacties na elke deploy die de prompt wijzigt.
De rekening steeg nadat u caching inschakelde. Uw hitrate ligt onder het break-evenpunt. Bij minder dan ongeveer 22 procent voor de cache van 5 minuten is het goedkoper om de prefix ongecached te verzenden; hetzelfde geldt voor de cache van 1 uur bij minder dan ongeveer 53 procent.
FAQ
Hoe vaak moet een prompt worden hergebruikt voordat caching rendabel is?
Eén keer bij de cache van 5 minuten. Een schrijfactie kost 1,25x de basisinvoer en een leesactie kost 0,1x. N ongecachte verzoeken kosten N, terwijl N gecachte verzoeken 1,25 plus 0,1 maal N min 1 kosten. Het omslagpunt ligt bij N = 1,28, dus het tweede verzoek levert al voordeel op. De cache van 1 uur schrijft tegen 2x en bereikt het omslagpunt bij N = 2,11; hiervoor zijn dus twee leesacties nodig.
Waarom is cache_read_input_tokens altijd nul?
Controleer eerst de lengte van het voorvoegsel: onder het minimum van het model, 512 tokens bij Claude Opus 5 en 4.096 bij Claude Haiku 4.5 per augustus 2026, wordt caching stilzwijgend overgeslagen en staan beide tellers op 0. Als het voorvoegsel lang genoeg is, zoek dan naar inhoud die verandert tussen aanroepen en die zich op of voor het breekpunt bevindt, zoals een tijdstempel of een sessie-identificatie in de system prompt. Als de tellers werkten en zijn gestopt, was de tijd tussen de verzoeken langer dan de levensduur van de cache.
Verandert prompt caching de antwoorden van Claude?
Nee. De cache slaat de verwerkte vorm op van tokens die u al heeft verzonden, en het model ziet in beide gevallen dezelfde prompt. Het is een functie voor facturering en latentie, geen wijziging in het gedrag. Dit betekent ook dat u het kunt inschakelen voor een werkende prompt zonder uw evaluaties opnieuw uit te voeren.
Moet ik betalen voor de cache van 1 uur?
Alleen wanneer uw verkeer gaten vertoont die langer zijn dan 5 minuten en uw hitrate nog steeds ongeveer 53 procent haalt. De 2x schrijfactie is twee keer zo nadelig als de 1,25x schrijfactie wanneer u een misser heeft. Een invoer van 5 minuten ververst bij elke hit, dus bij constant verkeer blijft deze actief tegen leesprijzen zonder ooit te hoeven betalen voor de langere levensduur.