Die Ökonomie des Prompt Caching
Anthropics Prompt-Caching-Beta verändert die Kostenrechnung für lange Prompts: Das Schreiben in den Cache kostet 25 Prozent mehr als reguläre Input-Tokens, das Lesen 90 Prozent weniger. Wir rechnen Preise und Break-even nach, zeigen die Grenzen der fünfminütigen TTL und leiten daraus Konsequenzen für RAG-Pipelines und Agenten-Loops ab.
Die Kosten der Wiederholung
APIs großer Sprachmodelle sind zustandslos. Deshalb trägt jeder Request den vollständigen Kontext erneut mit: Systemprompt, Tool-Definitionen, Few-Shot-Beispiele und Referenzdokumente. Der Anbieter berechnet jedes Token bei jedem Aufruf zum vollen Input-Preis — selbst wenn 95 Prozent des Prompts mit dem vorherigen Request identisch sind. Bei langen, weitgehend statischen Prompts wird diese Wiederholung schnell zum größten Kostenblock.
Die Zahlen sind konkret. Ein Kontext von 100.000 Tokens kostet auf Claude 3.5 Sonnet 0,30 US-Dollar pro Request beim Basispreis von 3 US-Dollar pro Million Input-Tokens. Bei 1.000 Requests pro Tag sind das 300 US-Dollar täglich für Tokens, die das Modell bereits hunderte Male verarbeitet hat. Bislang gab es keinen Weg, der API mitzuteilen: Dieser Teil ist bereits bekannt.
Was Anthropic ausgeliefert hat
Im August 2024 hat Anthropic Prompt Caching als Public Beta in der Anthropic API veröffentlicht, zunächst für Claude 3.5 Sonnet und Claude 3 Haiku; Unterstützung für Claude 3 Opus wurde angekündigt. Aktiviert wird das Feature pro Request über den HTTP-Header anthropic-beta: prompt-caching-2024-07-31 und cache_control-Markierungen auf einzelnen Content-Blöcken.
Die Mechanik ist strikt präfixbasiert. Das cachebare Präfix umfasst Tools, Systemprompt und Messages in genau dieser Reihenfolge bis zu einem Cache-Breakpoint; bis zu vier Breakpoints pro Request sind erlaubt. Gecachte Segmente leben fünf Minuten, jeder Cache-Treffer setzt diesen Timer zurück. Die Mindestlänge beträgt 1.024 Tokens auf Claude 3.5 Sonnet und 2.048 Tokens auf Claude 3 Haiku.
Preise für Schreiben und Lesen des Caches
Prompt Caching führt zwei neue Token-Preise ein. Das Schreiben eines Präfixes in den Cache kostet 25 Prozent mehr als der Basis-Input-Preis. Das Lesen kostet 10 Prozent des Basispreises — ein Rabatt von 90 Prozent. Output-Tokens bleiben unberührt. Anthropic nennt Kostenreduktionen von bis zu 90 Prozent und Latenzreduktionen von bis zu 85 Prozent für lange Prompts.
Diese Preisstruktur ist bewusst gewählt: Der Aufschlag von 25 Prozent deckt das Ablegen des Präfixes ab, der Rabatt von 90 Prozent belohnt dessen Wiederverwendung. Es gibt keine separate Speichergebühr und keine Kapazitätskosten — allein die Zugriffsfrequenz entscheidet, ob sich Caching rechnet. Das macht das Modell leicht nachvollziehbar, bei Endpunkten mit wenig Verkehr jedoch ebenso leicht falsch einsetzbar.
| Modell | Basis-Input ($/MTok) | Cache-Schreiben ($/MTok) | Cache-Lesen ($/MTok) |
|---|---|---|---|
| Claude 3.5 Sonnet | 3,00 | 3,75 | 0,30 |
| Claude 3 Haiku | 0,25 | 0,30 | 0,03 |
| Claude 3 Opus (angekündigt) | 15,00 | 18,75 | 1,50 |
Die Break-even-Rechnung
Die Rechnung ist einfach. Ein Präfix, das innerhalb des TTL-Fensters N-mal verwendet wird, kostet 1,25 + (N − 1) × 0,1 in Einheiten des ungecachten Preises statt N. Bei N = 2 sind das 1,35 gegenüber 2,0 — bereits der zweite Aufruf amortisiert den Schreibaufschlag und spart 32 Prozent. Bei N = 10 erreicht die Ersparnis 78 Prozent und konvergiert gegen 90 Prozent.
Umgekehrt ist Caching kein automatischer Rabatt. Verwendet eine Anwendung ein Präfix seltener als einmal in fünf Minuten erneut, zahlt sie bei jedem Aufruf den Schreibaufschlag von 25 Prozent, ohne einen günstigen Lesezugriff zu erhalten. Simon Willison fasste es am Veröffentlichungstag nüchtern zusammen: Wer seltener als alle fünf Minuten promptet, verliert Geld. Prompt Caching ist damit eine gezielte Wette auf Request-Frequenz.
Was Prompt Caching nicht leistet
Prompt Caching ist exaktes Präfix-Matching, kein semantisches Caching. Ein einziges geändertes Byte früh im Prompt — ein Zeitstempel, eine User-ID, eine umsortierte Tool-Definition — invalidiert alles danach. Volatile Inhalte gehören deshalb ans Ende des Prompts, nie an den Anfang. Am Kontextfenster ändert sich nichts; gecachte Tokens zählen weiterhin voll dagegen.
Es ist auch keine Persistenzschicht. Die TTL von fünf Minuten macht den Cache zu einer Optimierung für Aktivitätsschübe, nicht zu einer gespeicherten Wissensbasis. Bei Output-Tokens, dem teuersten Teil jeder Antwort, spart das Feature nichts. Prompts unterhalb der Mindestgrenzen werden gar nicht gecacht. Und es ist eine Beta: Preise und Semantik können sich noch ändern.
Vergleich mit Gemini Context Caching
Google hat Context Caching für Gemini 1.5 Pro und 1.5 Flash im Juni 2024 mit einem anderen Modell ausgeliefert: 75 Prozent Rabatt auf gecachte Input-Tokens plus eine Speichergebühr von 4,50 US-Dollar pro Million Tokens und Stunde für 1.5 Pro (1 US-Dollar für Flash), ein Minimum von 32.768 Tokens und explizit verwaltete Cache-Objekte mit konfigurierbarer TTL.
Die Designs zielen auf unterschiedliche Workloads. Geminis stündliche Speichergebühr begünstigt wenige sehr große, langlebige Caches mit kontinuierlichen Abfragen. Anthropics Schema kennt keine Speichergebühr, ein niedriges Minimum von 1.024 Tokens und eine kurze, sich selbst erneuernde TTL — es begünstigt hochfrequente Zugriffsmuster wie Chat-Sessions und Agenten-Loops. Keines ist pauschal günstiger; der Workload entscheidet.
Konsequenzen für RAG und Agenten
Für RAG-Systeme verschiebt das Pricing eine Grenze. 200.000 gecachte Tokens auf Claude 3.5 Sonnet zu lesen kostet 0,06 US-Dollar pro Request. Für kleine und mittlere Korpora, die ins Kontextfenster passen, konkurriert der komplette Dokumentbestand als gecachtes Präfix nun mit Chunk-Retrieval — ohne Retriever, ohne Index, ohne Chunking-Artefakte. Für große oder schnell veränderliche Korpora bleibt Retrieval notwendig; abgerufene Chunks gehören hinter den letzten Cache-Breakpoint.
Bei Agenten ist der Hebel noch größer. Ein Agenten-Loop sendet seine wachsende Konversationshistorie mit jedem Tool-Aufruf erneut; die Aufrufe liegen typischerweise nur Sekunden auseinander und damit klar innerhalb der fünfminütigen TTL. Wird das Historien-Präfix gecacht, sinken die Input-Kosten jeder Iteration um bis zu 90 Prozent. Auch lange Tool-Definitionen und Many-Shot-Beispiele werden nach dem ersten Schreiben von einer Gebühr pro Aufruf zu nahezu kostenlosen Lesezugriffen. Für uns bei Blue IT Systems ist das das stärkste Argument für dieses Feature.
Ausblick: Caching als Standardinfrastruktur
Unsere Erwartungen, geschrieben im August 2024: Caching wird Standardinfrastruktur statt Beta-Flag. Konkurrierende APIs werden in irgendeiner Form nachziehen, und TTL-Optionen werden über fünf Minuten hinauswachsen, wo Workloads es verlangen. Die Abrechnungsmodelle werden sich weiter ausdifferenzieren — Schreibaufschläge, Speichergebühren oder beides.
Damit verändert sich auch das Prompt-Design. Wir erwarten cache-first aufgebaute Prompts: ein stabiles Präfix aus Instruktionen, Tools und Beispielen, gefolgt von allen volatilen Inhalten. Diese Disziplin schwächt ein Argument für Fine-Tuning und stärkt bei mittelgroßen Korpora Long-Context-Architekturen gegenüber Retrieval. Einzelne Prognosen altern in diesem Feld schnell; die ökonomische Richtung ist robuster: statischen Kontext einmal statt bei jedem Aufruf bezahlen.