Von Claude Prompt-Caching: Ab wann lohnt es sich?
Cache-Schreiben kostet 1,25x, Lesen 0,1x: Ein Claude-Präfix amortisiert sich bei der zweiten Nutzung. Rechnen Sie den Break-even selbst nach und prüfen Sie ihn per API.
Welche Kosten Prompt-Caching verursacht, bevor es sich lohnt
Mit Prompt-Caching kann Claude den Anfang Ihres Prompts wiederverwenden, statt ihn bei jedem Aufruf erneut zu lesen. Die Entscheidung hängt vollständig von zwei Multiplikatoren des regulären Input-Preises Ihres Modells ab. Im August 2026 kostet das Schreiben in den Cache das 1,25-Fache des regulären Input-Preises bei einer Gültigkeitsdauer von 5 Minuten oder das 2-Fache bei einer Gültigkeitsdauer von 1 Stunde. Das Lesen aus dem Cache kostet das 0,1-Fache. Diese Multiplikatoren gelten für alle Modelle. Der folgende Break-even-Punkt ändert sich daher nicht, wenn sich der Preis pro Token ändert.
Der Vorteil später wird durch einen Aufpreis zu Beginn erkauft. Sie zahlen einmalig mehr, um ein Präfix zu speichern. Jede spätere Anfrage, die mit exakt denselben Bytes beginnt, zahlt für diesen Teil nur ein Zehntel des regulären Input-Preises. Wenn ein Präfix innerhalb seiner Gültigkeitsdauer nie wiederverwendet wird, zahlen Sie dafür 25 Prozent zusätzlich, ohne einen Vorteil zu erhalten.
Der Break-even-Punkt in einer Zeile Algebra
Nennen wir B die Basiskosten für den Input des Präfixes, wenn Sie ihn ohne Caching senden. Ohne Caching kosten N Anfragen N mal B. Mit dem 5-Minuten-Cache schreibt die erste Anfrage das Präfix für 1.25B, und die übrigen N minus 1 Anfragen lesen es für jeweils 0.1B. Wenn Sie beide Kosten gleichsetzen, erhalten Sie 0.9N = 1.15 und damit N = 1.28. Bereits die zweite Anfrage ist günstiger als der vollständige Verzicht auf Caching.
Wenn Sie das mit dem 2x-Schreibvorgang des 1-Stunden-Caches wiederholen, erhalten Sie 0.9N = 1.9 und damit N = 2.11. Der lange Cache benötigt zwei Lesevorgänge, bevor er den Break-even-Punkt erreicht. Deshalb ist er nicht die Standardauswahl.
Das folgende Diagramm berechnet diese Kosten für ein Präfix mit 20,000 Token bei Claude Opus 5. Der Basistarif für Input beträgt im August 2026 $5 pro 1 Million Token. Multiplizieren Sie jeden Wert für ein Modell mit $3 pro 1 Million Token mit 0.6. Die Form der Kurve ändert sich dadurch nicht.
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"
}
]Eine einzelne Anfrage kostet ohne Caching $0.10 und mit Caching $0.125. Das Caching einer einmaligen Anfrage verursacht daher einen reinen Verlust. Bei der zweiten Anfrage liegt der 5-Minuten-Cache bei $0.135, verglichen mit $0.20. Der 1-Stunden-Cache liegt zu diesem Zeitpunkt noch darüber: $0.21 gegenüber denselben $0.20. Erst bei der dritten Anfrage liegt er unter den Kosten ohne Caching: $0.22 gegenüber $0.30. Bei 20 Anfragen beträgt der Abstand $2.00 gegenüber $0.315.
Ein Cache-Treffer aktualisiert den Eintrag ebenfalls. Deshalb bezeichnet die veröffentlichte Preistabelle diese Spalte als Cache-Treffer und Aktualisierungen. Ein stark ausgelasteter Endpunkt hält einen 5-Minuten-Eintrag dadurch zu den Lesepreisen unbegrenzt aktiv. Die Gültigkeit von 1 Stunde rechtfertigt den 2x-Schreibvorgang nur dann, wenn Ihr Datenverkehr echte Unterbrechungen aufweist.
Was eine niedrige Trefferquote kostet
Im realen Datenverkehr treten Cache-Fehlzugriffe auf. Eine Anfrage, die den Cache verfehlt, aber weiterhin einen Breakpoint enthält, wird als Schreibvorgang berechnet. Daher sollte man die Kosten als Funktion der Trefferquote modellieren. Das folgende Diagramm zeigt dies für 1,000 Anfragen mit demselben Präfix aus jeweils 20,000 Token.
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"
}
]Bei einer Trefferquote von 0 Prozent zahlen Sie $125.00 statt $100.00. Der 1 hour Cache verdoppelt die Rechnung auf $200.00. Löst man 1.25 minus 1.15h = 1, beginnt der 5 minute Cache ab einer Trefferquote von etwa 22 Prozent Geld zu sparen. Deshalb werden bei 25 Prozent bereits $96.25 angezeigt. Dieselbe Berechnung mit dem 2x-Schreibvorgang ergibt für den 1 hour Cache etwa 53 Prozent. Bei einer Trefferquote von 50 Prozent kostet er daher weiterhin $105.00 und liegt damit über der ungecacheten Linie. Bei 90 Prozent ergeben sich $21.50 und $29.00. Bei 99 Prozent erreicht der kurze Cache $11.15 und liegt damit nahe bei einem Zehntel des ungecacheten Preises.
Die Trefferquote ist der entscheidende Messwert. Sie ist der einzige Eingabewert, den Sie nach der Festlegung der Präfixgröße noch steuern können.
Welche Präfixe sind einen Breakpoint wert
Eine Anfrage kann bis zu vier Cache-Breakpoints enthalten. Daher stellt sich die Frage, welche Blöcke einen solchen Breakpoint erhalten sollten. Geeignet sind Blöcke, die bei verschiedenen Aufrufen byte-identisch sind und groß genug sind, um relevant zu sein. Das folgende Diagramm vergleicht vier gängige Strukturen über 1,000 Anfragen bei einer Trefferquote von 90 Prozent im 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"
}
]Ein einfaches System-Prompt mit 2,000 Tokens spart gegenüber den nicht gecachten Kosten von $10.00 $7.85 pro 1,000 Anfragen. Bei entsprechendem Volumen ist das ein realer Betrag. Das allein macht Caching jedoch noch nicht besonders interessant. Mit den Tool-Definitionen umfasst der Präfix 8,000 Tokens, und die Ersparnis beträgt $31.40. Ein Richtliniendokument mit 25,000 Tokens, zu dem jede Anfrage Fragen stellt, spart $98.12. Die letzte Zeile verändert die Architektur: 120,000 Tokens mit Codebasis- oder Transkriptkontext kosten ohne Cache $600.00 und mit Cache $129.00. Das entspricht einer Ersparnis von $471.00.
Die Ersparnis steigt mit der Präfixgröße und der Trefferquote, aber mit keinem anderen Faktor. Dadurch ändert sich auch, welche Inhalte sich überhaupt für ein Prompt lohnen: was eine Million Claude-Tokens tatsächlich kostet sinkt für alle Inhalte, die Sie mehr als einmal senden, auf ein Zehntel des Listenpreises.
So sieht es auf einer Monatsrechnung aus
Das folgende Diagramm verwendet das oben beschriebene Präfix mit 8,000 Token, einen System-Prompt sowie Tool-Definitionen bei einer Trefferquote von 90 Prozent und skaliert diese Werte auf monatliche Anfragevolumen.
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"
}
]Bei 10.000 Anfragen pro Monat beträgt die Ersparnis $314.00. Sie entspricht der Differenz zwischen $400.00 und $86.00. Bei 100.000 Anfragen beträgt sie $3,140.00. Bei einer Million Anfragen belaufen sich die Kosten für nicht zwischengespeicherte Eingaben auf $40,000.00. Durch das Caching entfallen davon $31,400.00. Diese Angaben beziehen sich nur auf Eingabe-Token. Ausgaben werden separat berechnet, und Caching ändert daran nichts. Das sollten Sie berücksichtigen, bevor Sie jemandem eine Senkung der Rechnung um 90 Prozent versprechen. Caching ergänzt die allgemeinen Maßnahmen unter die Rechnung eines AI-Agenten auf einem VPS unter Kontrolle halten.
So weisen Sie nach, dass der Cache funktioniert
Verlassen Sie sich nicht auf das Konzept. Lesen Sie den Nutzungsblock der Antwort. Jede Antwort der Messages API (application programming interface) weist die geschriebenen, gelesenen und neu verarbeiteten Cache-Tokens aus.
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)Führen Sie die Anfrage zweimal mit demselben Dokument und einer anderen Frage aus. Der erste Aufruf weist einen Wert ungleich 0 für cache_creation_input_tokens und 0 für cache_read_input_tokens aus. Beim zweiten Aufruf ist es umgekehrt, weil das Präfix gefunden wurde. input_tokens zählt nur die Tokens nach dem letzten Breakpoint. Bei einem erfolgreichen zweiten Aufruf ist dieser Wert daher klein und umfasst normalerweise nur die neue Benutzernachricht. Beide Aufrufe werden berechnet, weil die Claude API keine kostenlose Stufe anbietet. Für das oben bepreiste Präfix mit 20,000 Tokens kostet das Paar jedoch etwa vierzehn Cent.
Dieselbe Prüfung aus der Shell gegen einen Request-Body, den Sie unter request.json gespeichert haben:
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'Ein erfolgreicher zweiter Aufruf gibt ungefähr Folgendes aus:
{
"input_tokens": 42,
"cache_creation_input_tokens": 0,
"cache_read_input_tokens": 20143,
"output_tokens": 187
}Eine Zeile zeigt den tatsächlichen Zustand. Wenn cache_read_input_tokens bei mehreren Aufrufen den Wert 0 behält, zahlen Sie jedes Mal den 1.25x-Aufschlag für das Schreiben und erhalten nichts aus dem Cache zurück.
Für die Gültigkeitsdauer von 1 hour enthält der Breakpoint eine time to live (TTL):
{
"type": "text",
"text": "your stable prefix",
"cache_control": {"type": "ephemeral", "ttl": "1h"}
}Es gibt außerdem automatisches Caching: ein einzelnes Feld cache_control auf der obersten Ebene des Requests. Danach verwaltet die API die Breakpoints, während die Konversation wächst. Dadurch wird einer Ihrer vier Breakpoint-Slots belegt. Beginnen Sie damit. Verwenden Sie explizite Breakpoints, wenn Sie genau festlegen müssen, wo die Grenze liegt.
Die Reihenfolgenregel, die Trefferquoten zerstört
Der Cache vergleicht ein Präfix ab dem Anfang der Anfrage Byte für Byte. Die Anfrage wird in einer festen Reihenfolge zusammengesetzt: Tools, dann System, dann Nachrichten. Eine Änderung auf einer Ebene macht diese Ebene und alle nachfolgenden Ebenen ungültig. Wenn Sie eine Toolbeschreibung bearbeiten, werden auch der System-Prompt und der gesamte Nachrichtenverlauf ungültig, obwohl Sie diese nicht geändert haben.
Daraus ergibt sich eine Regel ohne Ausnahmen. Alles, was sich zwischen Aufrufen ändert, muss nach allem stehen, was unverändert bleibt.
Der häufigste Verursacher ist ein Zeitstempel. Eine Zeile mit Current time: 2026-08-03T14:07:11Z am Anfang eines System-Prompts garantiert eine Trefferquote von 0 Prozent, weil sich der Präfix-Hash bei jedem Aufruf ändert und kein früherer Eintrag jemals dazu passen kann. Verschieben Sie die Zeile an das Ende der User-Nachricht. Eine Sitzungs-ID oder ein Nonce pro Anfrage verursacht dasselbe Problem und wird auf dieselbe Weise behoben. Abgerufene Dokumente, die sich je nach Anfrage unterscheiden, müssen ebenfalls hinter dem gecachten Block stehen. Andernfalls verschieben sie jedes stabile Token hinter eine sich ändernde Grenze.
Der zweite Verursacher ist ein Breakpoint auf dem Block, der sich ändert. Cache-Schreibvorgänge erfolgen am Breakpoint. Wenn sich dieser Block bei jedem Aufruf unterscheidet, wird niemals etwas Stabiles gespeichert. Beim Rückblick werden dann nur Einträge gefunden, die frühere Anfragen an ihren jeweils wechselnden Breakpoints geschrieben haben. Setzen Sie cache_control auf den letzten Block, dessen Inhalt bei allen Anfragen identisch ist.
Der dritte Verursacher ist eine Parameteränderung, die Sie nicht als Prompt-Inhalt betrachten. Ein anderes Modell verwendet einen anderen Cache. Eine Änderung der Toolauswahl macht den Cache ab der Systemebene ungültig. Das Hinzufügen oder Entfernen eines Tools macht alles ungültig.
Das Mindestpräfix und der stille No-op
Ein Präfix, das kürzer als das modellabhängige Minimum ist, wird nicht zwischengespeichert, ohne dass Sie darüber informiert werden. Es gibt weder einen Fehler noch eine Warnung. Die Anfrage ist erfolgreich, und beide Zähler zeigen 0 an. Im August 2026 gelten folgende veröffentlichten Mindestwerte:
- 512 Tokens bei Claude Opus 5 und Claude Fable 5
- 1,024 Tokens bei Claude Sonnet 5 und Claude Opus 4.8
- 4,096 Tokens bei Claude Haiku 4.5
Wenn beide Zähler bei einer Anfrage, die Ihrer Einschätzung nach aus dem Cache bedient werden sollte, 0 anzeigen, prüfen Sie zuerst die Präfixlänge. Das erklärt auch, warum das günstigste Modell für einen Workload mit Caching nicht automatisch am günstigsten ist. Haiku 4.5 benötigt ein achtmal längeres Präfix als Opus 5, bevor Caching überhaupt aktiviert wird. Ein System-Prompt mit 2,000 Tokens wird daher bei einem Modell zwischengespeichert und beim anderen stillschweigend ignoriert.
Wo Claude Code für Sie cached und wo nicht
Claude Code cached sein eigenes Präfix. Der System-Prompt und die Tool-Definitionen stehen am Anfang jeder Anfrage und ändern sich nicht. Deshalb werden sie einmal geschrieben und für den Rest der Sitzung wieder eingelesen. Daher liegen die Kosten pro Durchlauf in einer langen Sitzung deutlich unter dem, was die Kontextgröße vermuten lässt. Das wird in den Zählern sichtbar, die unter so meldet Claude Code die Token-Nutzung beschrieben sind.
Nicht helfen kann Ihnen das bei einer Änderung nahe am Anfang des Kontexts. Der Konversationsverlauf wird nur angehängt. Normale neue Durchläufe erweitern daher ein Präfix, das bereits gecached ist. Wenn Sie eine Datei bearbeiten, die früh in der Sitzung eingelesen wurde, ändert sich der Inhalt in der Mitte dieses Präfixes. Jedes Token nach der Änderung muss dann erneut geschrieben werden. Eine lange Leerlaufzeit führt zum gleichen Ergebnis, weil der Eintrag abläuft und der nächste Durchlauf vollständig geschrieben werden muss. Beides ist kein Fehler. In beiden Fällen greift die Präfixregel genau wie beschrieben.
Wenn Sie stattdessen einen eigenen Client schreiben, verwenden Sie das Layout bereits bei der ersten Anfrage, statt es nachträglich einzubauen. Erstellen Sie den Aufruf so, wie eine erste Claude-API-Anwendung auf einem VPS aufgebaut ist: zuerst die stabilen Blöcke und zuletzt die veränderlichen.
Fehlerbilder und ihre sichtbaren Anzeichen
Jeder Aufruf ist ein Schreibvorgang. cache_creation_input_tokens ist bei jeder Anfrage ungleich 0, während cache_read_input_tokens weiterhin 0 bleibt. Etwas am oder vor dem Breakpoint ändert sich zwischen den Aufrufen. Geben Sie bei zwei aufeinanderfolgenden Anfragen die ersten 200 Zeichen Ihres zusammengesetzten Präfixes aus und vergleichen Sie sie direkt.
Beide Zähler sind 0. Das Präfix liegt unter dem vom Modell vorgegebenen Minimum, oder das Feld cache_control hat die API nie erreicht. Zählen Sie zuerst die Tokens des Präfixes. Protokollieren Sie anschließend den Request-Body, den Sie tatsächlich gesendet haben.
Lesevorgänge funktionieren zunächst und stoppen dann. Auf eine Reihe von Treffern folgen ein Schreibvorgang und danach wieder Treffer. Der Abstand zwischen den Anfragen war länger als die Gültigkeitsdauer. Akzeptieren Sie den Schreibvorgang, oder wechseln Sie zur TTL von 1 hour, sobald Sie geprüft haben, dass Ihre Trefferquote 53 Prozent überschreitet.
Die Trefferquote sinkt nach einem Deploy. Eine Tool-Beschreibung wurde bearbeitet, oder ein Modell wurde geändert. Beides macht das gesamte Präfix ungültig. Rechnen Sie nach jedem Deploy, das den Prompt betrifft, mit einer kostenintensiven Runde von Schreibvorgängen.
Die Rechnung ist gestiegen, nachdem Sie Caching aktiviert haben. Ihre Trefferquote liegt unter dem Break-even-Punkt. Bei weniger als etwa 22 Prozent im 5 minute cache ist das Senden des Präfixes ohne Cache günstiger. Bei weniger als etwa 53 Prozent gilt dasselbe für den 1 hour cache.
FAQ
Wie oft muss ein Prompt wiederverwendet werden, damit sich Caching lohnt?
Einmal beim 5-Minuten-Cache. Ein Schreibvorgang kostet das 1,25-Fache der Basiseingabe, ein Lesevorgang das 0,1-Fache. Daher kosten N nicht zwischengespeicherte Anfragen N, während N zwischengespeicherte Anfragen 1,25 plus 0,1 mal N minus 1 kosten. Die beiden Kosten schneiden sich bei N = 1,28. Bereits die zweite Anfrage ist daher günstiger. Der 1-Stunden-Cache schreibt mit dem 2-Fachen und erreicht den Schnittpunkt bei N = 2,11. Dafür sind zwei Lesevorgänge erforderlich.
Warum ist cache_read_input_tokens immer 0?
Prüfen Sie zuerst die Präfixlänge: Unterhalb der Mindestlänge des Modells wird das Caching stillschweigend übersprungen. Im August 2026 sind das 512 Tokens bei Claude Opus 5 und 4.096 bei Claude Haiku 4.5. Beide Zähler bleiben dann bei 0. Wenn das Präfix lang genug ist, suchen Sie nach Inhalten, die sich zwischen den Aufrufen ändern und am oder vor dem Breakpoint stehen. Beispiele sind ein Zeitstempel oder eine Sitzungskennung im System-Prompt. Wenn die Zähler zunächst funktionierten und dann nicht mehr, lag der Abstand zwischen den Anfragen über der Cache-Lebensdauer.
Ändert Prompt-Caching die Antworten von Claude?
Nein. Der Cache speichert die verarbeitete Form von Tokens, die Sie bereits gesendet haben. Das Modell sieht in beiden Fällen denselben Prompt. Es handelt sich um eine Funktion für Abrechnung und Latenz, nicht um eine Verhaltensänderung. Sie können Caching daher für einen funktionierenden Prompt aktivieren, ohne Ihre Evaluierungen erneut auszuführen.
Sollte ich für den 1-Stunden-Cache bezahlen?
Nur wenn Ihr Datenverkehr Lücken von mehr als 5 Minuten aufweist und Ihre Trefferquote weiterhin ungefähr 53 Prozent überschreitet. Der Schreibvorgang zum 2-Fachen ist bei einem Fehlschlag doppelt so teuer wie der Schreibvorgang zum 1,25-Fachen. Ein 5-Minuten-Eintrag wird bei jedem Treffer aktualisiert. Gleichmäßiger Datenverkehr hält ihn daher zu den Preisen für Lesevorgänge aktiv, ohne dass Sie für die längere Lebensdauer bezahlen müssen.