Claude API Prompt Caching bezeichnet eine Funktion der Anthropic-API, bei der wiederkehrende Prompt-Bestandteile wie System-Prompts oder Tool-Definitionen intern als KV-Matrizen zwischengespeichert werden. Cache-Reads kosten nur 10 % des normalen Input-Token-Preises — wer seinen System-Prompt konsequent cached, spart in der Praxis bis zu 90 % der monatlichen API-Kosten.
Wer mit der Claude API arbeitet, schickt bei jedem API-Call denselben langen System-Prompt erneut mit. Bei 10.000 Anfragen im Monat summiert sich das schnell auf dreistellige Dollar-Beträge — für Tokens, die Claude eigentlich schon kennt. Genau hier setzt Claude API Prompt Caching an. Ein Entwickler hat seine monatlichen API-Kosten damit von 720 USD auf 72 USD gesenkt. In diesem Leitfaden zeigen wir, wie das technisch funktioniert, was es kostet und wie du es Schritt für Schritt einrichtest.
Was ist Claude API Prompt Caching?
Funktion der Anthropic-API, bei der wiederkehrende Prompt-Bestandteile wie System-Prompts oder Tool-Definitionen intern als KV-Matrizen (Attention Key-Value-Paare) zwischengespeichert werden. Cache-Reads kosten nur 10 % des normalen Input-Token-Preises.
Claude API Prompt Caching: Eine Funktion der Anthropic Claude API, die wiederkehrende Prompt-Präfixe — also System-Prompts, Tool-Definitionen oder feste Instruktionsblöcke — intern als vorberechnete KV-Matrizen speichert, sodass Claude sie bei Folge-Anfragen nicht erneut verarbeiten muss.
Ohne Caching verarbeitet Claude bei jedem API-Call den vollständigen Prompt von Anfang an. Das kostet Zeit und Geld — besonders wenn dein System-Prompt 10.000 oder 50.000 Tokens lang ist. Mit Anthropic Prompt Caching API entfällt diese Wiederholung für gecachte Abschnitte.
KV-Matrizen: Was Claude intern zwischenspeichert
Claude speichert intern sogenannte KV-Matrizen — das sind Attention Key-Value-Paare aus dem Transformer-Modell. Vereinfacht gesagt: Claude berechnet beim ersten Durchlauf, wie jeder Token im Kontext zu allen anderen Tokens steht. Dieses Ergebnis landet im Cache. Bei der nächsten Anfrage mit identischem Präfix liest Claude die Matrizen direkt aus — die teure Prefill-Phase entfällt. Dadurch sinkt die Latenz laut Anthropic um bis zu 85 %.
Cache-Write vs. Cache-Read: Der Unterschied
Beim ersten API-Call mit einem Cache-Breakpoint schreibt Claude den Abschnitt in den Cache — das ist ein Cache-Write. Alle nachfolgenden Calls mit identischem Präfix lösen einen Cache-Read aus. Der Unterschied ist entscheidend für die Kostenrechnung: Cache-Writes kosten mehr als normale Tokens, Cache-Reads dagegen nur einen Bruchteil. Deshalb lohnt sich Claude Token Caching erst ab einer gewissen Wiederholungsrate.
Kostenstruktur: So funktioniert die Preisberechnung
| Token-Typ | Preis-Faktor | Ersparnis vs. Normal |
|---|---|---|
| Normale Input-Tokens | 1,0 × | — |
| Cache-Write (5-Min-Cache) | 1,25 × | +25 % |
| Cache-Write (1-Std-Cache) | 2,0 × | +100 % |
| Cache-Read | 0,1 × | −90 % |
Die Preise für Claude API Prompt Caching hängen davon ab, ob du einen Cache-Write oder einen Cache-Read auslöst. Die folgende Tabelle zeigt die Faktorenstruktur im Überblick.
Die detaillierten Preise je Modell findest du in der Claude API Preisgestaltung für gecachte Tokens direkt bei Anthropic.
Cache-Write-Preise: 5-Minuten- vs. 1-Stunden-Cache
Claude bietet zwei Cache-Lebensdauern. Der 5-Minuten-Cache kostet beim Schreiben 1,25 × den normalen Input-Token-Preis — also 25 % Aufpreis. Der 1-Stunden-Cache kostet 2,0 × den Basispreis. Daher gilt: Wähle den 1-Stunden-Cache nur, wenn deine Anfragen sich über einen längeren Zeitraum verteilen. Bei dichten Burst-Anfragen innerhalb weniger Minuten reicht der günstigere 5-Minuten-Cache.
Cache-Read-Preise: 90 % günstiger als normale Input-Tokens
Cache-Lese-Token kosten 0,1 × den Basis-Input-Token-Preis — also 90 % günstiger als normale Input-Tokens. Das ist der Hebel: Wer einen 50.000-Token-System-Prompt bei jeder von 1.000 täglichen Anfragen mitschickt, zahlt ohne Caching für 50 Millionen Input-Tokens. Mit konsequentem Caching und hoher Hit-Rate zahlt er dagegen nur noch für 5 Millionen Cache-Read-Tokens plus einmaligen Cache-Write-Aufpreis. Anthropics eigenes Beispiel zeigt: Ein 100.000-Token-Prompt wurde durch Caching 79 % günstiger.
Claude API Prompt Caching einrichten: Schritt für Schritt
Schritt 1 · System-Block
cache_control im System-Prompt setzen
System-Prompt wird gecacht
Setze {“type”: “ephemeral”} im system-Block.
Schritt 2 · User-Blöcke
Explizite Cache-Breakpoints für User-Content
Wiederkehrende Tool-Definitionen gecacht
Platziere cache_control am Ende stabiler Blöcke.
Schritt 3 · Monitoring
usage-Felder auslesen und Cache-Hits prüfen
Cache-Hit-Rate validiert
Tracke mit Langfuse oder Phoenix für Langzeit-Monitoring.
Für Prompt-Cache Claude einrichten brauchst du lediglich das cache_control-Feld in deinem API-Request. Voraussetzung ist ein Zugang zur Anthropic Claude API sowie ein Prompt-Abschnitt mit mindestens 1.024 Tokens (bei Sonnet-Modellen) bzw. 2.048 Tokens (bei Haiku 3.5).
- Identifiziere den stabilen, wiederkehrenden Teil deines Prompts — typischerweise den System-Block mit Instruktionen, Tool-Definitionen oder Kontext-Dokumenten.
- Füge am Ende dieses Blocks das Feld
"cache_control": {"type": "ephemeral"}ein — das setzt einen Cache-Breakpoint direkt an dieser Stelle. - Sende den ersten API-Call. Claude schreibt den Abschnitt bis zum Breakpoint in den Cache. Die Response enthält im
usage-Objekt das Feldcache_creation_input_tokensmit der Anzahl gecachter Tokens. - Sende einen zweiten API-Call mit identischem Präfix. Das
usage-Objekt enthält jetztcache_read_input_tokensstattcache_creation_input_tokens— der Cache-Hit ist bestätigt. - Setze bei Bedarf mehrere Cache-Breakpoints für verschiedene Abschnitte. Die offizielle Anthropic Prompt-Caching-Dokumentation beschreibt, wie du bis zu 4 Breakpoints pro Request kombinierst.
- Prüfe die
cache_read_input_tokens– undcache_creation_input_tokens-Felder in jeder Response. Sie sind die Grundlage für deine Kostenüberwachung. - Passe die Cache-Lebensdauer an: Nutze
"type": "ephemeral"für den 5-Minuten-Cache oder den 1-Stunden-Cache — je nach Anfrage-Muster.
Ein konkretes Beispiel für den System-Block: Du schickst einen 50.000-Token-Kontext mit Produktdaten. Ohne Caching kostet jeder der 500 täglichen Calls diesen vollen Betrag. Mit einem einzigen cache_control-Breakpoint am Ende des Kontextblocks zahlst du ab dem zweiten Call nur noch 10 % — ein Einspareffekt, der sich bereits am ersten Tag bemerkbar macht. Wer tiefer in die Prompt-Strategie einsteigen will, findet im Beitrag zu Prompt Engineering für Claude Code weiterführende Techniken für strukturierte Instruktionsblöcke.
cache_control im System-Block setzen
Der System-Block ist der häufigste Cache-Kandidat, weil er sich zwischen Anfragen selten ändert. Füge cache_control als letztes Feld im letzten Content-Objekt des System-Arrays ein. Wichtig: Der Breakpoint gilt für alles, was vor ihm steht — nicht für das, was danach kommt. Dynamische Inhalte wie die eigentliche User-Frage kommen deshalb immer nach dem Breakpoint.
Explizite Cache-Breakpoints für User-Blöcke
Auch im User-Block kannst du Cache-Breakpoints setzen. Das ist sinnvoll, wenn du große Dokumente oder Tool-Outputs als Kontext mitschickst, die sich über mehrere Turns nicht ändern. Setze den Breakpoint nach dem stabilen Dokumentenblock und vor der eigentlichen Frage des Nutzers. So cached Claude den Dokumentenkontext, verarbeitet aber die dynamische Frage normal.
usage-Felder auslesen und Cache-Hits prüfen
Jede API-Response enthält ein usage-Objekt mit den Feldern cache_creation_input_tokens und cache_read_input_tokens. Ersteres zeigt, wie viele Tokens in den Cache geschrieben wurden — diese kosten den Aufpreis. Letzteres zeigt, wie viele Tokens aus dem Cache gelesen wurden — diese kosten nur 10 %. Wenn cache_read_input_tokens bei Folge-Calls auf 0 bleibt, greift der Cache nicht. Mögliche Ursache: Der Prompt-Präfix hat sich minimal verändert, oder der Cache ist abgelaufen. Robustes Error Handling in Claude Code hilft dabei, solche Fälle automatisch zu erkennen und zu loggen.
Unterstützte Claude-Modelle und ihre Cache-Limits
| Modell | Cache-Limit (Tokens) | Cache-Lebensdauer |
|---|---|---|
| Claude Opus 4.7 | 4.096 | 5 Min / 1 Std |
| Claude Opus 4.6 | 4.096 | 5 Min / 1 Std |
| Claude Opus 4.5 | 4.096 | 5 Min / 1 Std |
| Claude Sonnet 4.6 | 1.024 | 5 Min / 1 Std |
| Claude Sonnet 4.5 | 1.024 | 5 Min / 1 Std |
| Claude Haiku 4.5 | 4.096 | 5 Min / 1 Std |
| Claude Haiku 3.5 | 2.048 | 5 Min (retired außer Vertex) |
| Claude Mythos Preview | 4.096 | 5 Min / 1 Std |
Nicht alle Claude-Modelle haben identische Cache-Limits. Die folgende Tabelle zeigt die aktuellen Werte laut Anthropic-Dokumentation.
Das Cache-Limit bezeichnet die Mindestgröße eines Prompt-Abschnitts, damit Claude ihn überhaupt cached. Kürzere Abschnitte werden ignoriert — selbst wenn du cache_control setzt.
Opus, Sonnet und Haiku im Vergleich
Der Unterschied zwischen Sonnet und Opus ist beim Caching besonders relevant: Claude Sonnet 4.5 hat ein Cache-Limit von nur 1.024 Tokens, während Opus-Modelle 4.096 Tokens als Minimum benötigen. Für kurze System-Prompts unter 4.096 Tokens ist Sonnet daher der bessere Kandidat für Claude API Cache-Optimierung. Haiku 4.5 bietet ebenfalls 4.096 Tokens Limit, ist aber günstiger in der Basisabrechnung — damit ist es die erste Wahl für kostenoptimierte Batch-Prozesse. Wer die Modelle grundsätzlich vergleichen will, findet im Artikel zum Unterschied zwischen Sonnet und Opus eine detaillierte Gegenüberstellung der Fähigkeiten.
Claude Mythos Preview: Was sich ändert
Claude Mythos Preview unterstützt ebenfalls Claude API Prompt Caching mit einem Cache-Limit von 4.096 Tokens pro Präfix. Da es sich um ein Preview-Modell handelt, können sich Preise und Limits noch ändern. Prüfe daher vor dem Produktiveinsatz die aktuellen Werte in der Anthropic-Dokumentation.
Prompt Caching optimieren: Wann sparst du wirklich 90 %?
Die 90-%-Ersparnis gilt nicht automatisch für jeden Use Case. Folgende Voraussetzungen müssen erfüllt sein, damit Claude API Prompt Caching seinen vollen Hebel entfaltet:
- Hohe Wiederholungsrate: Derselbe Prompt-Präfix wird viele Male pro Stunde gesendet — sonst überwiegt der Cache-Write-Aufpreis.
- Stabiler Präfix: Der gecachte Abschnitt darf sich zwischen Anfragen nicht verändern — auch ein einzelnes Zeichen Unterschied bricht den Cache-Hit.
- Großer Präfix: Je mehr Tokens gecacht werden, desto größer die absolute Ersparnis. Bei 1.000-Token-System-Prompts ist der Effekt gering; bei 50.000 Tokens ist er erheblich.
- Passende Cache-Lebensdauer: Anfragen müssen innerhalb des Cache-Fensters (5 Minuten oder 1 Stunde) eintreffen — sonst verfällt der Cache und ein neuer Write-Aufpreis entsteht.
- Modell-Kompatibilität: Das genutzte Modell muss Prompt Caching unterstützen und das Minimum-Token-Limit des Präfixes muss erreicht sein.
Laut einer Analyse von Obvious Works aus 2026 ist eine Gesamtkosteneinsparung von 70–80 % realistisch, wenn Prompt Caching mit weiterer Context-Optimierung kombiniert wird.
Voraussetzungen für hohe Cache-Hit-Rates
Eine hohe Cache-Hit-Rate erreichst du vor allem durch Disziplin in der Prompt-Struktur. Platziere alle stabilen Inhalte — Instruktionen, Persona-Definitionen, Dokumente — am Anfang des Prompts, vor allen dynamischen Elementen. Dynamische Inhalte wie Nutzerfragen oder Echtzeit-Daten kommen immer nach dem Cache-Breakpoint. Außerdem solltest du sicherstellen, dass dein Deployment-Setup den Präfix nicht unbeabsichtigt variiert — etwa durch unterschiedliche Whitespace-Behandlung oder variablen Zeitstempel-Injektionen im System-Prompt.
Wann Caching nicht sinnvoll ist
Anthropic Prompt Caching API lohnt sich nicht in jedem Szenario. Wenn dein System-Prompt kürzer als das Modell-spezifische Cache-Limit ist, cached Claude gar nicht. Ebenso ist Caching ineffizient bei sehr niedrigen Anfragevolumen — wenn du nur 10 Calls pro Tag sendest, überwiegt der Cache-Write-Aufpreis die Ersparnis aus Cache-Reads. Vollständig dynamische Prompts, die sich bei jeder Anfrage komplett ändern, profitieren ebenfalls nicht. Und schließlich: Wenn deine Anfragen zeitlich sehr weit auseinanderliegen und der Cache regelmäßig abläuft, zahlst du wiederholt den Write-Aufpreis ohne nennenswerte Read-Ersparnis.
Token Costs überwachen: Monitoring-Tools für Prompt Caching
Claude API Prompt Caching entfaltet seinen vollen Nutzen nur, wenn du weißt, ob der Cache tatsächlich trifft. Deshalb ist Monitoring kein optionales Extra, sondern Teil der Implementierung.
Langfuse und Phoenix für Cache-Tracking
Langfuse ist das empfohlene Tool, um Cache-Creation- und Cache-Read-Tokens, Hit-Rates und Gesamtkosten über Zeit zu tracken. Du siehst auf einen Blick, wie viele deiner Calls einen Cache-Hit erzeugen — und erkennst sofort, wenn sich etwas am Prompt-Präfix geändert hat und die Hit-Rate einbricht. Zusätzlich eignet sich Phoenix für detailliertes Monitoring von Cache-Hits und Token-Einsparungen auf Request-Ebene. Beide Tools lesen die usage-Felder cache_creation_input_tokens und cache_read_input_tokens direkt aus der API-Response — daher ist kein zusätzliches Instrumentieren nötig.
MCP-Plugin für automatisiertes Caching in Claude Code
Wer Claude Code in Entwicklungs-Workflows einsetzt, kann das MCP-Plugin von Ercan Ermiş nutzen. Es automatisiert Prompt Caching für Claude Code vollständig und spart laut Dokumentation bis zu 90 % der Token-Kosten — ohne manuelle cache_control-Einträge im Code. MindStudio bietet ebenfalls native Unterstützung für Prompt Caching in Claude Code Workflows inklusive integriertem Monitoring. Frameworks wie LangChain reichen das cache_control-Feld direkt an die Anthropic Claude API durch — du kannst Prompt-Cache Claude einrichten also auch innerhalb bestehender LangChain-Pipelines, ohne die Architektur zu ändern. Spring AI unterstützt Prompt Caching mit Claude ebenfalls über Anthropic Chat Options, was Java-basierte Backends direkt einbezieht.
Häufige Fragen
Wie viel kostet ein Cache-Write im Vergleich zu normalen Input-Tokens bei Claude?
Ein Cache-Write für den 5-Minuten-Cache kostet 1,25 × den normalen Input-Token-Preis — also 25 % Aufpreis. Der 1-Stunden-Cache kostet 2,0 × den Basispreis. Dieser Aufpreis fällt nur beim ersten Schreiben an. Alle nachfolgenden Cache-Reads kosten dagegen nur 0,1 × den Basispreis, also 90 % weniger als normale Input-Tokens.
Welche Claude-Modelle unterstützen Prompt Caching und welche Cache-Limits gelten?
Claude Opus 4.5, 4.7, Haiku 4.5 und Mythos Preview haben ein Cache-Limit von 4.096 Tokens. Claude Sonnet 4.5 hat ein Limit von 1.024 Tokens — damit ist es das einsteigerfreundlichste Modell für kürzere System-Prompts. Haiku 3.5 liegt bei 2.048 Tokens. Alle genannten Modelle unterstützen sowohl den 5-Minuten- als auch den 1-Stunden-Cache.
Wie setze ich cache_control korrekt in meinem API-Request ein?
Füge "cache_control": {"type": "ephemeral"} als Feld im letzten Content-Objekt des stabilen Prompt-Abschnitts ein — typischerweise am Ende des System-Blocks. Der Breakpoint gilt für alles, was vor ihm steht. Du kannst bis zu 4 Breakpoints pro Request setzen, um verschiedene Abschnitte getrennt zu cachen.
Wie lange bleibt ein Prompt-Cache bei Claude aktiv (Cache-Lebensdauer)?
Claude bietet zwei Cache-Lebensdauern: 5 Minuten und 1 Stunde. Den Typ wählst du über das cache_control-Feld. Der 5-Minuten-Cache kostet beim Schreiben 25 % Aufpreis, der 1-Stunden-Cache 100 % Aufpreis. Nach Ablauf der Lebensdauer verfällt der Cache — der nächste Call löst erneut einen Cache-Write aus.
Wie kann ich überprüfen, ob mein Cache tatsächlich getroffen wird (Cache-Hit)?
Jede API-Response enthält im usage-Objekt die Felder cache_creation_input_tokens und cache_read_input_tokens. Wenn cache_read_input_tokens bei Folge-Calls einen Wert größer 0 zeigt, greift der Cache. Bleibt das Feld leer oder 0, hat sich der Präfix verändert oder der Cache ist abgelaufen. Tools wie Langfuse visualisieren diese Werte über Zeit.
Wann lohnt sich Claude API Prompt Caching nicht?
Claude API Prompt Caching lohnt sich nicht bei sehr niedrigem Anfragevolumen, vollständig dynamischen Prompts oder wenn der Prompt-Präfix kürzer als das Modell-spezifische Cache-Limit ist. Auch bei sehr langen Pausen zwischen Anfragen — sodass der Cache regelmäßig abläuft — überwiegt der Write-Aufpreis die Ersparnis durch Cache-Reads.
Fazit: Claude API Prompt Caching lohnt sich — wenn du es richtig einsetzt
Claude API Prompt Caching ist kein Selbstläufer, aber ein echter Hebel: Wer einen großen, stabilen System-Prompt bei vielen täglichen Anfragen einsetzt, kann seine Token Costs um bis zu 90 % senken. Die Implementierung ist überschaubar — ein cache_control-Feld im richtigen Block, die usage-Felder im Blick, und ein Monitoring-Tool wie Langfuse für die Hit-Rate. Entscheidend ist, dass der gecachte Präfix wirklich stabil bleibt. Daher gilt: Erst die Prompt-Struktur sauber aufteilen, dann cachen — und nicht umgekehrt.
Willst du Claude API Prompt Caching in deinem Projekt einrichten oder weißt nicht, wo du anfangen sollst? Meld dich einfach — ich schnack gerne darüber.
