Von Claude Prompt-Caching: Ab wann es sich lohnt
Cache-Schreiben kostet 1,25x, Lesen 0,1x oder weniger. Berechnen Sie den Break-even für Ihr Claude-Präfix und prüfen Sie ihn direkt anhand der 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 verarbeiten. Die gesamte Entscheidung hängt von zwei Multiplikatoren für den regulären Input-Preis Ihres Modells ab. Im Oktober 2026 kostet das Schreiben in den Cache bei jedem Modell das 1,25-Fache des regulären Input-Preises für eine Gültigkeitsdauer von 5 Minuten oder das 2-Fache für eine Gültigkeitsdauer von 1 Stunde. Das Lesen aus dem Cache kostet bei den meisten Modellen das 0,1-Fache. Dieser Multiplikator ist jedoch nicht mehr bei allen Modellen gleich. Bei Claude Fable 5.1 und Claude Mythos 5.1 beträgt er 0,025. Diese Modelle wurden am 1. September 2026 mit diesem Preis eingeführt. Bei Claude Opus 5.5 und Claude Sonnet 5.5 beträgt er 0,05. Für Sonnet 5.5 wurde der Wert am 7. Oktober 2026 von 0,1 auf 0,05 gesenkt. Die folgenden Beispielrechnungen verwenden den standardmäßigen Lesefaktor von 0,1. Die günstigeren Lesevorgänge verschieben den Break-even-Punkt etwas zu Ihren Gunsten. Der nächste Abschnitt zeigt, um wie viel.
Sie zahlen jetzt einen Aufpreis und erhalten später einen Rabatt. Ein Präfix wird einmalig gegen einen Aufpreis gespeichert. Jede spätere Anfrage, die mit exakt denselben Bytes beginnt, wird für diesen Teil nur mit einem Zehntel des regulären Input-Preises berechnet. Bei den oben genannten Modellen ist der Preis noch niedriger. Wird ein Präfix innerhalb seiner Gültigkeitsdauer nie wiederverwendet, zahlen Sie dafür 25 Prozent zusätzlich, ohne einen Vorteil zu erhalten.
Der Break-even-Punkt in einer Zeile Algebra
Bezeichnen Sie die Basiskosten der Präfixeingabe mit B, wenn Sie sie ohne Cache 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. Setzt man beide Kosten gleich, ergibt sich 0.9N = 1.15 und damit N = 1.28. Bereits die zweite Anfrage ist günstiger als der Verzicht auf Caching.
Wiederholen Sie die Rechnung mit dem 2x teuren Schreibvorgang des 1-Stunden-Caches. Dann ergibt sich 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.
Bei günstigeren Lesevorgängen verschiebt sich die Grenze, aber nicht stark. Bei einem Lesevorgang zum Faktor 0.05 ergibt der 5-Minuten-Cache 0.95N = 1.2 und damit N = 1.26. Bei 0.025 ergibt sich 0.975N = 1.225, ebenfalls N = 1.26. Beim 1-Stunden-Cache sinkt N auf 2.05 beziehungsweise 2.03. In der Praxis lautet die Antwort bei jedem Modell gleich: Der 5-Minuten-Cache rechnet sich ab der zweiten Anfrage, der 1-Stunden-Cache ab der dritten.
Die folgende Grafik berechnet diese Kosten für ein Präfix mit 20,000 Token bei Claude Opus 5. Der Basistarif für Eingaben beträgt seit Oktober 2026 $5 pro 1 Million Token und ist seit August unverändert. Opus 5 ist inzwischen ein Legacy-Modell, aber weiterhin verfügbar. Sein Nachfolger Claude Opus 5.5 wird mit $4 pro 1 Million Token und einem Lesefaktor von 0.05 angegeben. Dort kostet dasselbe Präfix also $0.10 beim Schreiben und $0.004 beim Lesen. Für ein Modell mit $3 pro 1 Million Token und dem standardmäßigen Lesefaktor 0.1x skalieren Sie alle Werte mit 0.6. Die Form der Kurve ändert sich nicht.
Die Daten hinter diesem Diagramm
[
{
"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 Cache $0.10 und mit Cache $0.125. Das Caching einer einmaligen Anfrage verursacht daher einen reinen Verlust. Bei der zweiten Anfrage liegt der 5-Minuten-Cache bei $0.135, gegenüber $0.20 ohne Cache. Der 1-Stunden-Cache liegt zu diesem Zeitpunkt noch darüber: $0.21 gegenüber denselben $0.20. Erst bei der dritten Anfrage ist er günstiger als die nicht gecachte Variante: $0.22 gegenüber $0.30. Bei 20 Anfragen beträgt der Abstand $2.00 gegenüber $0.315.
Ein Cache-Treffer aktualisiert außerdem den Eintrag. Deshalb bezeichnet die veröffentlichte Preistabelle diese Spalte als Cache-Treffer und Aktualisierungen. Ein stark ausgelasteter Endpunkt hält einen 5-Minuten-Eintrag dadurch bei den Lesepreisen unbegrenzt aktiv. Die Lebensdauer von 1 Stunde rechtfertigt den 2x teuren Schreibvorgang nur, wenn zwischen Ihren Anfragen tatsächlich größere Lücken liegen.
Was eine niedrige Trefferquote kostet
Realer Netzwerkverkehr enthält Cache-Fehlzugriffe. Eine Anfrage, die den Cache verfehlt, aber weiterhin einen Breakpoint enthält, wird als Schreibvorgang abgerechnet. Daher lässt sich der Preis korrekt als Funktion der Trefferquote modellieren. Das folgende Diagramm zeigt dies für 1,000 Anfragen mit jeweils demselben Präfix aus 20,000 Tokens.
Die Daten hinter diesem Diagramm
[
{
"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. Aus 1.25 minus 1.15h = 1 ergibt sich, dass der 5 minute cache ab einer Trefferquote von etwa 22 Prozent Kosten spart. Deshalb werden bei 25 Prozent bereits $96.25 angezeigt. Dieselbe Berechnung mit dem 2x-Schreibpreis 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 Zeile ohne Cache. Bei 90 Prozent liegen die beiden Werte bei $21.50 und $29.00. Bei 99 Prozent erreicht der kurze Cache $11.15. Das liegt nahe an der Untergrenze von einem Zehntel des Preises ohne Cache.
Bei einem Modell mit einem Lesevorgang zum Faktor 0.05x sinken die Schwellenwerte auf etwa 21 Prozent für den 5 minute cache und 51 Prozent für den 1 hour cache. Bei einem Lesevorgang zum Faktor 0.025x sinken sie auf etwa 20 beziehungsweise 51 Prozent. Die Untergrenze sinkt mit dem Lesepreis auf ein Zwanzigstel beziehungsweise ein Vierzigstel der Kosten ohne Cache.
Die Trefferquote ist die entscheidende Messgröße. Nachdem die Präfixgröße festgelegt wurde, ist sie der einzige Eingabewert, den Sie steuern können.
Welche Präfixe eignen sich für einen Breakpoint
Eine Anfrage kann bis zu vier Cache-Breakpoints enthalten. Daher stellt sich die Frage, für welche Blöcke sich einer lohnt. Geeignet sind Blöcke, die bei mehreren Aufrufen byte-identisch und groß genug sind, um relevant zu sein. Das folgende Diagramm stellt vier gängige Formen für 1,000 Anfragen bei einer Trefferquote von 90 Prozent im 5-Minuten-Cache gegenüber.
Die Daten hinter diesem Diagramm
[
{
"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 2,000-Token-System-Prompt spart bei 1,000 Anfragen $7.85 gegenüber $10.00 ohne Cache. Bei hohem Volumen ist das ein realer Betrag, aber dadurch wird Caching noch nicht interessant. Mit den Tool-Definitionen umfasst der Präfix 8,000 Tokens und spart $31.40. Ein 25,000 Token umfassendes Richtliniendokument, zu dem jede Anfrage Fragen stellt, spart $98.12. Die letzte Zeile verändert die Architektur: 120,000 Tokens an 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 nichts anderem. Das verändert auch die Frage, was überhaupt in einen Prompt gehört: was eine Million Claude-Tokens tatsächlich kostet sinkt für alles, was Sie mehr als einmal senden, auf ein Zehntel des Listenpreises oder weniger, wenn das Modell günstigere Lesezugriffe bietet.
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.
Die Daten hinter diesem Diagramm
[
{
"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 Reihenfolgeregel, die die Trefferquote zerstört
Der Cache vergleicht ein Präfix ab dem Anfang der Anfrage Byte für Byte. Die Anfrage wird in einer festen Reihenfolge zusammengestellt: zuerst Tools, dann System, dann Nachrichten. Eine Änderung auf einer Ebene macht diese Ebene und alle nachfolgenden Ebenen ungültig. Wenn Sie die Beschreibung eines Tools 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 den 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 damit übereinstimmen kann. Verschieben Sie die Zeile in die User-Nachricht, und zwar ans Ende. 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 nach 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 nie 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 betrachtet haben. Ein anderes Modell verwendet einen anderen Cache. Eine Änderung an tool_choice macht den Nachrichtenverlauf ungültig, während Tools und System-Prompt weiterhin aus dem Cache verwendet werden. 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 Mindestpräfix des Modells ist, wird nicht zwischengespeichert. Es gibt keinen Hinweis darauf. Es wird weder ein Fehler noch eine Warnung ausgegeben. Die Anfrage ist erfolgreich, und beide Zähler zeigen 0 an. Im Oktober 2026 gelten folgende veröffentlichten Mindestwerte:
- 512 Token für Claude Opus 5 und Claude Fable 5 sowie für die neueren Modelle Opus 5.5, Sonnet 5.5, Fable 5.1 und Haiku 5.5
- 1,024 Token für Claude Sonnet 5 und Claude Opus 4.8
- 4,096 Token für Claude Haiku 4.5
Wenn beide Zähler bei einer Anfrage 0 anzeigen, von der Sie annehmen, dass sie aus dem Cache bedient wird, prüfen Sie zuerst die Präfixlänge. Das ist auch der Grund, 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. Daher wird ein System-Prompt mit 2,000 Token bei einem Modell zwischengespeichert und beim anderen stillschweigend ignoriert.
Wo Claude Code für Sie den Präfix cached und wo das nicht möglich ist
Claude Code cached seinen eigenen 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 Turn bei einer langen Sitzung weit unter dem, was die Kontextgröße vermuten lässt. Das wird in den Zählern sichtbar, die unter so meldet Claude Code den Tokenverbrauch beschrieben sind.
Bei einer Änderung nahe am Anfang des Kontexts hilft das Caching nicht. Der Konversationsverlauf kann nur erweitert werden. Normale neue Turns verlängern daher einen bereits gecachten Präfix. Wenn Sie eine Datei bearbeiten, die zu Beginn der Sitzung gelesen wurde, wird dieser Präfix nicht ungültig. Claude Code fügt stattdessen einen Hinweis hinzu, dass sich die Datei geändert hat, und schreibt den früheren Lesevorgang nicht neu. Ungültig wird der Präfix beim Wechsel des Modells, weil jedes Modell einen eigenen Cache verwendet. Auch das Verbinden eines MCP-Servers, dessen Tools in den Präfix geladen werden, macht ihn ungültig. Dasselbe gilt für das Komprimieren der Konversation. In jedem dieser Fälle wird der Präfix im nächsten Turn erneut geschrieben. Eine lange Leerlaufzeit hat denselben Effekt, weil der Eintrag abläuft und der nächste Turn einen vollständigen Schreibvorgang verursacht. Das sind keine Fehler. Die Präfix-Regel funktioniert genau wie beschrieben.
Wenn Sie stattdessen einen eigenen Client schreiben, sollten Sie das Layout bereits bei der ersten Anfrage anwenden, statt es nachträglich anzupassen: Bauen Sie den Aufruf so auf, wie in einer ersten Claude-API-Anwendung auf einem VPS, mit den stabilen Blöcken zuerst und den variablen Blöcken zuletzt.
Fehlerbilder und ihre Symptome
Jeder Aufruf ist ein Schreibvorgang. cache_creation_input_tokens ist bei jeder Anfrage ungleich 0, während cache_read_input_tokens weiterhin 0 bleibt. Zwischen den Aufrufen ändert sich etwas an oder vor dem Breakpoint. Geben Sie bei zwei aufeinanderfolgenden Anfragen die ersten 200 Zeichen Ihres zusammengesetzten Präfixes aus und vergleichen Sie sie visuell.
Beide Zähler sind 0. Das Präfix liegt unter dem vom Modell geforderten Mindestumfang, 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 und hören dann auf. Zuerst gibt es mehrere Treffer, dann einen Schreibvorgang und anschließend wieder Treffer. Der Abstand zwischen den Anfragen war länger als die Gültigkeitsdauer. Akzeptieren Sie den Schreibvorgang. Alternativ wechseln Sie zum TTL von 1 hour, sobald Sie geprüft haben, dass Ihre Trefferquote 53 Prozent beziehungsweise bei einem Modell mit einem Lesevorgang zu 0.05x oder 0.025x etwa 51 Prozent übersteigt.
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, der den Prompt betrifft, mit einer teuren Runde von Schreibvorgängen.
Die Rechnung ist nach der Aktivierung des Cachings gestiegen. Ihre Trefferquote liegt unter dem Break-even-Punkt. Bei weniger als etwa 22 Prozent ist das ungecachte Senden des Präfixes beim 5 minute cache günstiger. Beim 1 hour cache gilt das Gleiche bei weniger als etwa 53 Prozent. Bei den Modellen mit günstigeren Lesevorgängen liegen diese Schwellenwerte bei etwa 20 bis 21 Prozent beziehungsweise 51 Prozent.
FAQ
Wie oft muss ein Prompt wiederverwendet werden, damit sich Caching lohnt?
Einmal beim 5-Minuten-Cache. Ein Schreibvorgang kostet bei den meisten Modellen das 1,25-Fache des Basistarifs für Eingaben, ein Lesevorgang das 0,1-Fache. Daher kosten N nicht gecachte Anfragen N, während N gecachte Anfragen 1,25 plus 0,1 mal N minus 1 kosten. Die Kosten sind bei N = 1,28 gleich. Die zweite Anfrage ist damit bereits günstiger. Bei Modellen mit einem Lesevorgang zum 0,05-Fachen oder 0,025-Fachen liegt der Schnittpunkt bei N = 1,26. Das führt zum gleichen Ergebnis. Beim 1-Stunden-Cache kostet das Schreiben das 2-Fache. Der Schnittpunkt liegt bei N = 2,11 beziehungsweise bei etwa 2,05 bei den günstigeren Lesevorgängen. Daher sind zwei Lesevorgänge erforderlich.
Warum ist cache_read_input_tokens immer 0?
Prüfen Sie zuerst die Präfixlänge: Unterhalb des Mindestwerts des Modells wird das Caching stillschweigend übersprungen. Dieser Wert beträgt seit Oktober 2026 512 Tokens bei Claude Opus 5 und 4.096 bei Claude Haiku 4.5. Beide Zähler zeigen dann 0. Ist das Präfix lang genug, 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 funktioniert haben und dann nicht mehr, war der Abstand zwischen den Anfragen länger als die Cache-Lebensdauer.
Ändert Prompt-Caching die Antworten von Claude?
Nein. Der Cache speichert die verarbeitete Form der bereits gesendeten Tokens. Das Modell sieht in beiden Fällen denselben Prompt. Caching beeinflusst Abrechnung und Latenz, nicht das Verhalten. Sie können es 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 erreicht. Bei einem Modell mit günstigeren Lesevorgängen reichen etwa 51 Prozent. Bei einem Cache-Miss kostet das Schreiben zum 2-Fachen viermal so viel wie das Schreiben zum 1,25-Fachen. Ein fehlgeschlagener Schreibvorgang beim 1-Stunden-Cache verursacht für das Präfix die vollständigen Basiskosten für Eingaben. Bei einem fehlgeschlagenen Schreibvorgang beim 5-Minuten-Cache fällt dagegen nur ein Viertel dieser Kosten an. Ein 5-Minuten-Eintrag wird bei jedem Treffer erneuert. Gleichmäßiger Datenverkehr hält ihn daher zu den Preisen für Lesevorgänge aktiv, ohne dass jemals die längere Cache-Lebensdauer bezahlt werden muss.