Zehn Turns, ein Agent, ein 50.000-Token-Kontext. Ohne Caching summieren sich die Input-Tokens auf rund 522.500. Bei Claude Sonnet 4.6 (3 Dollar pro Million Tokens) sind das 1,57 Dollar. Mit Caching: ein Cache-Write für 0,19 Dollar plus neun Cache-Reads zu je 0,015 Dollar. Macht 0,34 Dollar. Selbe Konversation, 78 Prozent weniger Kosten.
Diese Zahl stammt aus einer Studie von Lumer et al. (PwC, arXiv 2601.06007v2, Januar 2026), die 500 Agent-Sessions ausgewertet hat. Bei Claude Sonnet 4.5 lag die durchschnittliche Ersparnis bei 78,5 Prozent, bei GPT-5.2 bei 79,6 Prozent. Bei 50.000-Token-Kontexten kletterte sie auf 88 bis 89 Prozent.
Du liest das vermutlich als Bestätigung dessen, was Anthropic auf der Pricing-Seite verspricht: bis zu 90 Prozent Ersparnis. Das ist die falsche Lesart.
Die 90-Prozent-Zahl ist eine Single-Call-Metrik
Anthropic vermarktet Prompt Caching als Cost-Optimization-Feature. Cache-Reads kosten 10 Prozent eines normalen Input-Tokens, Cache-Writes 25 Prozent extra. Wer das auf einen einzelnen API-Call anwendet, rechnet das prozentuale Delta zwischen Cache-Hit und Cache-Miss aus und landet bei 90 Prozent. Mathematisch korrekt. Praktisch irreführend.
Der Grund: Single-Call-Workloads sind nicht der Normalfall, an dem heute Geld verbrannt wird. Der Normalfall ist die Agent-Loop. Ein Tool-Use-Cycle, in dem das Modell bei jedem Turn den vollständigen bisherigen Konversationsverlauf wieder als Input bekommt, eine neue Tool-Antwort verarbeitet und einen weiteren Schritt plant.
Die Kostenkurve dieses Setups wächst nicht linear mit der Zahl der Turns. Sie wächst quadratisch. Bei Turn n werden alle Tokens aus den Turns 1 bis n-1 nochmal mitgesendet. Das ist die O(n²)-Falle, und sie ist der eigentliche ökonomische Kontext, in dem Caching gehört.
Die wahre Wirkung: aus quadratisch wird linear
Rechne es konkret nach. Ein Agent mit 50.000 Token Systemprompt und Tool-Definitionen, der zehn Schritte braucht, um eine Aufgabe abzuschließen. Bei jedem Turn kommen vielleicht 500 neue Tokens dazu (Tool-Result, Reasoning). Der akkumulierte Input über zehn Turns:
- Turn 1: 50.000 Tokens
- Turn 2: 50.500 Tokens
- Turn 3: 51.000 Tokens
- …
- Turn 10: 54.500 Tokens
Summe: rund 522.500 Tokens. Ohne Caching zahlst du dreimal: für die initiale Aufgabe, für den wiederholten Kontext und für den Wiedereintritt in jeden Folge-Turn. Mit Caching schreibst du den 50.000-Token-Prefix einmal in den Cache (Faktor 1,25 auf den Input-Preis) und liest ihn neunmal zurück (Faktor 0,1). Die Kostenkurve wird linear mit der Zahl der Turns, nicht quadratisch.
Bei zwanzig Turns wird der Effekt brutaler. Bei fünfzig Turns trägt nur noch die Linearisierung deine Marge. Wer einen Coding-Agent oder Research-Agent ohne Caching betreibt, baut keine Software, die in Produktion ökonomisch tragfähig ist.
Der TTL-Bug, der einem Anwender 2.530 Dollar gekostet hat
Am 6. März 2026 hat Anthropic den Default-Cache-TTL still von 60 Minuten auf 5 Minuten reduziert. Ohne Announcement, ohne Changelog-Eintrag in der API-Dokumentation. Ein dokumentierter Anwender hat die Konsequenz auf byteiota.com (April 2026) und in GitHub Issue #46829 von anthropics/claude-code öffentlich gemacht: 2.530,88 Dollar zusätzliche Kosten über 119.866 API-Calls in einem Monat. Der Cache-Overhead-Anteil sprang von 1,1 Prozent (Februar, 1-Stunden-TTL) auf 25,9 Prozent (März, 5-Minuten-TTL). Das ist eine effektive Cache-Effizienz-Verschlechterung um 92 Prozent.
Claude-Code-Max-User berichteten gleichzeitig, dass ihr Token-Budget nach 19 Minuten erschöpft war statt nach 5 Stunden. Der Mechanismus dahinter ist trivial: Bei 5 Minuten TTL läuft der Cache zwischen Tool-Aufruf und LLM-Antwort regelmäßig ab. Jeder Cache-Miss erzwingt einen erneuten Cache-Write zum 1,25-fachen Preis. Eine Session, die unter 60 Minuten TTL ein einziges Mal cacht und neun Mal liest, schreibt unter 5 Minuten TTL drei oder vier Mal komplett neu.
Caching ist kein Set-and-Forget-Feature. Provider-Defaults verändern sich still, und die Kosten reagieren nichtlinear. Wer auf Caching baut, muss die Cache-Hit-Rate als Production-Metrik tracken, nicht das API-Bill am Monatsende.
Anthropic hat den 1-Stunden-Cache buchbar gemacht (gegen Aufpreis)
Die Reaktion auf das TTL-Problem kam mit dem Beta-Header extended-cache-ttl-2025-04-11 am 11. April 2025: explizit buchbare 1-Stunden-Caches. Cache-Write kostet dort das Doppelte des Input-Preises (statt 1,25-fach), Cache-Read bleibt bei 0,1-fach. Amazon Bedrock hat die 1-Stunden-TTL im Januar 2026 nachgezogen.
Die Logik dieser Preisstruktur lohnt einen zweiten Blick. Anthropic verlangt für längeren Cache mehr beim Schreiben, nicht beim Lesen. Das ist konsistent mit der Annahme, dass die teure Operation das Vorhalten des Cache-Eintrags ist, nicht der Zugriff. Für lange Agent-Loops mit hoher Read-Frequenz ist der erweiterte TTL trotz höherem Write-Preis ökonomisch dominiert: einmal teurer schreiben, neunmal günstig lesen schlägt fünfmal billiger schreiben, fünfmal günstig lesen.
Diskutiert wird inzwischen Semantic Caching jenseits von Prefix-Match. Also Cache-Hits auf semantisch äquivalente Prompts, nicht nur auf Byte-für-Byte-Identität. Ob das jemals in der Anthropic-API landet, ist offen. Aktuell gilt: Wenn der Prefix sich um ein Byte ändert, hast du keinen Cache.
Das Gegenargument: für RAG ist 90 Prozent real und genug
Ein Workload existiert, bei dem die “nur ein Rabatt”-Lesart stimmt: RAG mit statischem Korpus, der in den Kontext passt. Single-Shot-Queries. Keine Multi-Turn-Konversation.
Die Cache-Augmented-Generation-Bewegung von 2025 hat gezeigt: Bei Korpora unter etwa 200.000 Tokens, die sich nicht stündlich ändern, schlägt vollständiges Context-Stuffing mit gecachtem Kontext klassisches RAG um 15 bis 20 Prozent in der Accuracy. Ohne Embedding-Latenz, ohne Vector-Store-Maintenance. Hier funktioniert die 90-Prozent-Logik direkt: Du cachst dein gesamtes Wissensdokument einmal pro Stunde, jede Query liest es zum 0,1-Faktor.
Aber dieses Argument trägt nur unter drei gleichzeitig erfüllten Bedingungen: erstens ein statischer Korpus, zweitens ein Korpus, der ins Kontextfenster passt, drittens kein Multi-Turn-Agent-Loop. Sobald eine Bedingung kippt (und in Produktionssystemen kippt fast immer eine), flippt die Logik. Aus dem Single-Call-Rabatt wird das O(n²)-Problem, und die 90-Prozent-Zahl wird zur Falle.
Die Production-Trap, die niemand im Code sieht
Anthropic erlaubt maximal vier explizite Cache-Breakpoints pro Request. Das Lookback-Window beträgt 20 Positionen: Findet die API innerhalb der letzten 20 Cache-Einträge keinen Match, ist es ein Cache-Miss. Selbst wenn der Inhalt identisch ist. Jeder Cache-Read refresht den TTL-Timer kostenlos. So weit die Spezifikation.
Der Bug, der Geld kostet, sitzt eine Ebene tiefer. Ein einziges dynamisches Element im Prefix bricht den Cache komplett. Ein Timestamp im Systemprompt. Eine User-ID. Eine Tool-Liste, die bei jedem Request anders sortiert wird. Die API merkt nichts davon, sie sieht nur einen veränderten Prefix und schreibt neu.
Ein dokumentierter Fall: Ein JSON-Serializer hat seine Keys bei jedem Request in unterschiedlicher Reihenfolge ausgegeben. Im Code stand json.dumps(tools). Im API-Wire-Format stand mal {"name": ..., "description": ...}, mal {"description": ..., "name": ...}. Ein 20.000-Token-Cache wurde bei jedem Aufruf invalidiert. Im Code war das nicht zu sehen. In der monatlichen Rechnung war es das Einzige, was zu sehen war.
Das ist die Lehre, die nicht in der Pricing-Doku steht. Caching ist kein Switch. Es ist eine Architektur-Disziplin, die Determinismus im Prefix erzwingt und Nicht-Determinismus ans Ende des Prompts schiebt. Wer die Disziplin nicht hat, zahlt nicht 90 Prozent weniger. Wer sie hat, betreibt Agent-Loops, die in Produktion ökonomisch funktionieren. Der Unterschied ist nicht ein Rabatt, sondern die Frage, ob das System überhaupt baubar ist.
Wer regelmäßig Analysen zur ökonomischen Mechanik von LLM-APIs lesen will (TTL-Verhalten, Cache-Strategien, Provider-Vergleiche im Production-Kontext), findet im KI-Syndikat Newsletter jede Woche eine Einordnung, die unter die Marketing-Zahlen schaut.