Claude Prompt-Caching: Ab wann lohnt es sich?

Welche Kosten Prompt-Caching verursacht, bevor es sich lohnt

Prompt-Caching ermöglicht Claude, den Anfang Ihres Prompts wiederzuverwenden, statt ihn bei jedem Aufruf erneut zu verarbeiten. Die Entscheidung hängt im Wesentlichen von zwei Multiplikatoren des normalen Input-Preises Ihres Modells ab. Im August 2026 kostet das Schreiben in den Cache das 1.25-Fache des normalen 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 die gesamte Modellliste. Der folgende Break-even-Punkt ändert sich daher nicht, wenn sich der Preis pro Token ändert.

Sie zahlen zunächst 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, zahlt für diesen Teil nur ein Zehntel des normalen Input-Preises. Wird ein Präfix innerhalb seiner Gültigkeitsdauer nie wiederverwendet, zahlen Sie dafür 25 Prozent mehr, ohne einen Vorteil zu erhalten.

Der Break-even-Punkt in einer Zeile Algebra

Nennen Sie B die Basiseingabekosten des Präfixes, wenn Sie es uncached senden. Ohne Caching kosten N Anfragen das N-Fache von B. Mit dem 5-minute-Cache schreibt die erste Anfrage das Präfix für 1.25B, und die anderen 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 vollständige Verzicht auf Caching.

Wiederholen Sie die Berechnung mit dem 2x-Schreibvorgang des 1-hour-Cache. 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.

Die folgende Grafik berechnet dies für ein Präfix mit 20,000 Token bei Claude Opus 5, dessen Basiseingabepreis im August 2026 bei $5 pro 1 Million Token liegt. Skalieren Sie jeden Wert für ein Modell mit $3 pro 1 Million Token mit 0.6. Die Form der Kurve ändert sich nicht.

[
  {
    "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 ist daher ein reiner Verlust. Bei der zweiten Anfrage liegt der 5-minute-Cache bei $0.135, gegenüber $0.20 ohne Caching. Der 1-hour-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 uncached Variante: $0.22 gegenüber $0.30. Bei 20 Anfragen beträgt der Abstand $2.00 gegenüber $0.315.

Ein Cache-Hit aktualisiert außerdem den Eintrag. Deshalb bezeichnet die veröffentlichte Preistabelle diese Spalte als Cache-Hits und Aktualisierungen. Ein stark ausgelasteter Endpunkt hält einen 5-minute-Eintrag dadurch unbegrenzt lange zu den Lesepreisen aktiv. Die 1-hour-Gültigkeitsdauer rechtfertigt den 2x-Schreibvorgang nur, wenn Ihr Datenverkehr tatsächlich größere Lücken aufweist.

Was eine niedrige Trefferquote kostet

Realer Datenverkehr enthält Cache-Fehlschläge. Eine Anfrage, die den Cache verfehlt, aber weiterhin einen Breakpoint enthält, wird als Schreibvorgang abgerechnet. Daher lässt sich der tatsächliche Aufwand am besten als Funktion der Trefferquote modellieren. Das folgende Diagramm zeigt dies für 1,000 Anfragen, die jeweils denselben Präfix mit 20,000 Token enthalten.

[
  {
    "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-Schreibvorgang ergibt für den 1 hour Cache etwa 53 Prozent. Eine Trefferquote von 50 Prozent kostet daher weiterhin $105.00 und liegt damit über der Zeile ohne Cache. Bei 90 Prozent erreichen die beiden Varianten $21.50 beziehungsweise $29.00. Bei 99 Prozent erreicht der kurze Cache $11.15 und liegt damit nahe an der Untergrenze von einem Zehntel des Preises ohne Cache.

Die Trefferquote ist die entscheidende Messgröße. Sie ist der einzige Eingabewert, den Sie nach der Festlegung der Präfixgröße noch steuern können.

Welche Präfixe verdienen einen Cache-Breakpoint

Eine Anfrage kann bis zu vier Cache-Breakpoints enthalten. Daher stellt sich die Frage, welche Blöcke einen solchen Breakpoint verdienen. Geeignet sind Blöcke, die bei verschiedenen Aufrufen bytegenau identisch und groß genug sind, um ins Gewicht zu fallen. Die folgende Grafik berechnet die Kosten für vier typische Formen bei 1,000 Anfragen, einer Trefferquote von 90 Prozent und einem 5-Minuten-Cache.

[
  {
    "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 System-Prompt mit nur 2,000 Tokens spart gegenüber den ungecachten Kosten von $10.00 pro 1,000 Anfragen $7.85. Bei hohem Volumen ist das ein relevanter Betrag, aber darin liegt nicht der entscheidende Vorteil von Caching. Mit den Tool-Definitionen sind es 8,000 Tokens und $31.40 Einsparung. 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 an Codebasis- oder Transkriptkontext kosten ungecacht $600.00 und gecacht $129.00. Das entspricht einer Einsparung von $471.00.

Die Einsparungen steigen mit der Präfixgröße und der Trefferquote, aber mit keinem anderen Faktor. Dadurch ändert sich auch, welche Inhalte sich überhaupt für einen Prompt lohnen: was eine Million Claude-Tokens tatsächlich kostet sinkt für alles, was Sie mehr als einmal senden, auf ein Zehntel des Listenpreises.

So sieht es auf einer monatlichen Rechnung aus

Das folgende Diagramm nimmt das oben beschriebene 8,000-Token-Präfix, einen System-Prompt und Tool-Definitionen bei einer Trefferquote von 90 Prozent und rechnet es auf monatliche Anfragevolumen hoch.

[
  {
    "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. Dabei handelt es sich ausschließlich um Eingabe-Token. Die Ausgabe wird separat berechnet, und das Caching wirkt sich nicht darauf aus. Das sollten Sie berücksichtigen, bevor Sie jemandem eine Senkung der Rechnung um 90 Prozent versprechen. Caching ergänzt die weiteren Maßnahmen unter die Rechnung eines AI-Agenten auf einem VPS unter Kontrolle halten.

So prüfen Sie, ob der Cache funktioniert

Verlassen Sie sich nicht auf das Design. Lesen Sie den Nutzungsblock in der Antwort. Jede Antwort der Messages API (application programming interface) weist die zwischengespeicherten Tokens aus, die geschrieben und gelesen wurden, sowie die neuen Tokens, die verarbeitet werden mussten.

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 null für cache_creation_input_tokens und den Wert null 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 enthält normalerweise nur die neue Benutzernachricht.

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 Ihnen den tatsächlichen Zustand. Wenn cache_read_input_tokens bei allen Aufrufen den Wert 0 behält, bezahlen Sie jedes Mal den 1.25x-Aufschlag für das Schreiben, ohne dafür Daten aus dem Cache zu erhalten.

Bei einer 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 aktiviert dieses Verhalten. Danach verwaltet die API die Breakpoints, während die Konversation wächst. Das Feld belegt einen Ihrer vier Breakpoint-Slots. Beginnen Sie damit. Verwenden Sie explizite Breakpoints, wenn Sie die Position der Grenze genau festlegen müssen.

Die Reihenfolgeregel, 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 zusammengestellt: zuerst Tools, dann das System, danach die Nachrichten. Eine Änderung auf einer Ebene macht diese Ebene und alle nachfolgenden Ebenen ungültig. Wenn Sie eine Toolbeschreibung ändern, 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 darauf passen kann. Verschieben Sie diese Zeile an das Ende der User-Nachricht. Eine Sitzungskennung 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 Lookback 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 minimale Präfix und der stille No-op

Ein Präfix, das kürzer als das modellabhängige Minimum ist, wird nicht zwischengespeichert. Sie erhalten darüber keine Rückmeldung. 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öffentlichte Mindestwerte:

• 512 Tokens für Claude Opus 5 und Claude Fable 5
• 1,024 Tokens für Claude Sonnet 5 und Claude Opus 4.8
• 4,096 Tokens für 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 Länge des Präfixes. Das erklärt auch, warum das günstigste Modell für eine Arbeitslast mit Caching nicht automatisch die geringsten Kosten verursacht. Claude Haiku 4.5 benötigt ein achtmal längeres Präfix als Claude Opus 5, bevor Caching überhaupt aktiviert wird. Eine Systemaufforderung mit 2,000 Tokens wird daher beim einen Modell zwischengespeichert und beim anderen stillschweigend ignoriert.

Wo Claude Code für Sie cached und wo nicht

Claude Code cached seinen eigenen Präfix. Der System-Prompt und die Tool-Definitionen stehen am Anfang jeder Anfrage und ändern ihre Position nicht. Deshalb werden sie einmal geschrieben und für den Rest der Sitzung wieder eingelesen. Dadurch liegen die Kosten pro Durchlauf bei einer langen Sitzung deutlich unter dem, was die Context-Größe vermuten lässt. Das ist in den Zählern aus der Token-Nutzungsanzeige von Claude Code sichtbar.

Nicht helfen kann das Caching bei einer Änderung nahe dem Anfang des Contexts. Der Gesprächsverlauf kann nur erweitert werden. Normale neue Durchläufe verlängern daher einen Präfix, der bereits cached ist. Wenn Sie eine Datei ändern, die zu Beginn der Sitzung eingelesen wurde, ändert sich der Inhalt in der Mitte dieses Präfixes. Jeder Token nach dieser Änderung muss erneut geschrieben werden. Eine lange Leerlaufzeit hat denselben Effekt, weil der Eintrag abläuft und der nächste Durchlauf eine vollständige Schreiboperation verursacht. Beides ist kein Fehler. In beiden Fällen greift die Präfixregel genau wie vorgesehen.

Wenn Sie stattdessen einen eigenen Client schreiben, verwenden Sie das Layout bereits bei der ersten Anfrage, statt es nachträglich umzubauen. Erstellen Sie den Aufruf wie in einer ersten Claude-API-Anwendung auf einem VPS, mit den stabilen Blöcken zuerst und den veränderlichen Blöcken zuletzt.

Fehlerfälle und ihre sichtbaren Auswirkungen

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 jeweils die ersten 200 Zeichen des zusammengesetzten Präfixes aus und vergleichen Sie sie manuell.

Beide Zähler sind 0. Das Präfix liegt unterhalb der vom Modell geforderten Mindestlänge, oder das Feld cache_control wurde nie an die API übergeben. 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. Es gibt eine Folge von Treffern, 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 können Sie auf die TTL von 1 hour umstellen, sobald Sie geprüft haben, dass Ihre Trefferquote 53 Prozent überschreitet.

Die Trefferquote sinkt nach einem Deployment. Eine Tool-Beschreibung wurde bearbeitet oder ein Modell wurde geändert. Beides macht das gesamte Präfix ungültig. Nach jedem Deployment, das den Prompt betrifft, müssen Sie mit einer teuren Folge von Schreibvorgängen rechnen.

Die Rechnung ist nach der Aktivierung des Cachings gestiegen. 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. Beim 1 hour cache gilt dasselbe bei weniger als etwa 53 Prozent.

FAQ

Wie oft muss ein Prompt wiederverwendet werden, bevor sich das 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 Kostenkurven schneiden sich bei N = 1,28. Bereits die zweite Anfrage ist daher günstiger. Beim 1-Stunden-Cache wird ein Schreibvorgang mit dem 2-Fachen berechnet. Der Schnittpunkt liegt bei N = 2,11, daher sind zwei Lesevorgänge erforderlich.

Warum ist cache_read_input_tokens immer null?

Prüfen Sie zuerst die Präfixlänge. Unterhalb des Mindestwerts des Modells — 512 Tokens bei Claude Opus 5 und 4.096 bei Claude Haiku 4.5 (Stand August 2026) — wird das Caching stillschweigend übersprungen, und beide Zähler bleiben bei 0. Ist das Präfix lang genug, suchen Sie nach Inhalten, die sich zwischen den Aufrufen ändern und am oder vor dem Breakpoint stehen, beispielsweise einem Zeitstempel oder einer Sitzungskennung im System-Prompt. Wenn die Zähler zunächst funktioniert haben und dann aufhörten, war der Abstand zwischen den Anfragen länger als die Cache-Gültigkeitsdauer.

Ändert Prompt-Caching die Antworten von Claude?

Nein. Der Cache speichert die verarbeitete Form der 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 Änderung des Verhaltens. Sie können sie 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 mit dem 2-Fachen verursacht bei einem Fehltreffer den doppelten Nachteil gegenüber dem Schreibvorgang mit dem 1,25-Fachen. Ein 5-Minuten-Eintrag wird bei jedem Treffer aktualisiert. Bei konstantem Datenverkehr bleibt er daher zu den Preisen für Lesevorgänge aktiv, ohne dass Sie für die längere Gültigkeitsdauer bezahlen müssen.