Door Wanneer is Claude prompt caching rendabel?
Cache-schrijven kost 1,25x en lezen 0,1x de basisprijs. Een prefix is vanaf het tweede gebruik goedkoper. Bereken hier uw break-evenpunt en verifieer dit via de Claude API.
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 beslissing hangt af van twee vermenigvuldigers op de basis-inputprijs van uw model. Sinds augustus 2026 kost een cache-schrijfactie 1,25x de basis-inputprijs 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 modelaanbod, waardoor het break-evenpunt niet verschuift wanneer de prijs per token wijzigt.
De afweging is een huidige toeslag tegenover een toekomstige korting. U betaalt eenmalig extra om een prefix op te slaan. Elk volgend verzoek dat begint met exact dezelfde bytes, betaalt vervolgens een tiende van de normale inputprijs voor dat gedeelte. Een prefix die 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 keer 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 langere cache heeft twee leesacties nodig voordat het break-evenpunt is 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 zit 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; daarom noemt de gepubliceerde prijstabel die kolom cache-hits en verversingen. Een druk eindpunt houdt een item van 5 minuten daarom voor onbepaalde tijd in leven tegen leesprijzen, en de levensduur van 1 uur verdient zijn 2x schrijfkosten alleen terug wanneer uw verkeer daadwerkelijke gaten vertoont.
Wat een lage hit rate kost
Echt verkeer mist de cache. Een verzoek dat de cache mist maar wel een breakpoint bevat, wordt in rekening gebracht als een write. De eerlijke manier om dit te modelleren is daarom de kosten uit te drukken 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 minus 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 write 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 kunt beïnvloeden nadat de prefix-grootte 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 elk verzoek identiek zijn en groot genoeg zijn om relevant te zijn. De onderstaande tabel toont de kosten van vier veelvoorkomende vormen over 1.000 verzoeken met een hitrate van 90 procent op de cache van 5 minuten.
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 bij grote volumes echt geld, maar dat is niet wat caching interessant maakt. Voeg de tool-definities toe en u komt uit op 8,000 tokens en een besparing van $31.40. 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 transcript-context kost $600.00 zonder caching en $129.00 met caching, een besparing van $471.00.
Besparingen schalen met de prefix-grootte 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 naar een tiende van de catalogusprijs voor alles wat u vaker dan één keer verstuurt.
Hoe dit eruitziet op een maandelijkse factuur
De onderstaande grafiek neemt 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 proces 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 is 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.
Dezelfde controle vanuit 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 geeft een resultaat zoals dit:
{
"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-overhead 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 breekpunten beheert naarmate het gesprek groeit. Dit verbruikt een van uw vier breekpunt-slots. Begin hiermee. Stap over op expliciete breekpunten wanneer u exact wilt bepalen waar de grens ligt.
De volgorderegel die de hitrate verlaagt
De cache vergelijkt een prefix byte voor byte vanaf het begin van het verzoek, en het verzoek wordt in een vaste volgorde samengesteld: tools, vervolgens system, en daarna messages. Een wijziging op elk niveau maakt dat niveau en alles wat daarna komt ongeldig. Bewerk één toolbeschrijving en zowel de system prompt als de volledige berichtgeschiedenis worden daarmee ongeldig, ook al hebt 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 per-verzoek nonce veroorzaakt hetzelfde probleem en kent 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 vermeldingen 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 waar u niet aan hebt gedacht als zijnde prompt-inhoud. 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 bericht. Er verschijnt 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 denkt 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 vereist een voorvoegsel dat acht keer langer is dan dat van Opus 5 voordat caching überhaupt wordt geactiveerd. Een systeem-prompt van 2.000 tokens wordt dus op het ene model wel gecachet en op het andere model stilzwijgend genegeerd.
Waar Claude Code voor u cachet, en waar dit niet mogelijk is
Claude Code cachet zijn eigen prefix. De systeemprompt 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 suggereert, 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 bewerking aan 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. Beide zijn het gevolg van de prefix-regel die precies doet wat er staat.
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 veranderlijke blokken als laatste.
Foutmodi en wat u zult zien
Elke aanroep is een schrijfactie. cache_creation_input_tokens is bij elk verzoek ongelijk aan nul, 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 body van het verzoek dat 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 trefferpercentage boven de 53 procent uitkomt.
Trefferpercentage daalt na een implementatie. 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 implementatie die de prompt wijzigt.
De rekening steeg nadat u caching inschakelde. Uw trefferpercentage ligt onder het break-evenpunt. Bij een cache van 5 minuten is het goedkoper om de prefix ongecached te verzenden als het percentage onder de 22 procent ligt; bij een cache van 1 uur geldt hetzelfde onder de 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 basisinput en een leesactie kost 0,1x. N niet-gecachte 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 is al voordeliger. De cache van 1 uur schrijft tegen 2x en bereikt het omslagpunt bij N = 2,11, waardoor er twee leesacties nodig zijn.
Waarom is cache_read_input_tokens altijd nul?
Controleer eerst de prefixlengte: 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 de prefix lang genoeg is, zoek dan naar inhoud die tussen aanroepen door verandert op of vóór het breekpunt, zoals een tijdstempel of een sessie-ID in de system prompt. Als de tellers voorheen werkten en nu niet meer, was de pauze 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 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 pauzes heeft 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 item in de cache van 5 minuten wordt bij elke hit ververst, dus constant verkeer houdt het in leven tegen lees-tarieven zonder dat u ooit voor de langere levensduur hoeft te betalen.