Eine Fallstudie darüber, wie Claude eine Cache-Trefferquote von 92 % erreicht
Jedes Mal, wenn ein KI-Agent einen Schritt macht, zahlt er eine Steuer.
Er liest alles von Grund auf neu.
Die Systemanweisungen. Die Tool-Definitionen. Der Projektkontext, den er bereits vor drei Schritten geladen hat. Alles. Bei jedem einzelnen Schritt.
Das ist die Kontextsteuer. Und für langlebige agentische Workflows ist sie oft der teuerste Posten in Ihrer gesamten KI-Infrastruktur.
Hier ist die Rechnung: Ein System-Prompt mit 20.000 Token, der über 50 Schritte läuft, bedeutet 1 Million Token redundanter Berechnung, die zum vollen Preis abgerechnet werden und keinen neuen Wert schaffen.
Die Lösung ist Prompt-Caching. Aber um es gut zu nutzen, müssen Sie verstehen, was tatsächlich unter der Haube passiert.
Beginnen Sie mit dem, was sich ändert und was nicht
Bevor Sie etwas optimieren können, müssen Sie klar über die Struktur des Prompts (Kontext) eines Agenten nachdenken.
Jede Anfrage, die Ihr Agent sendet, hat zwei grundlegend verschiedene Teile:
Das statische Präfix: Es enthält Systemanweisungen, Tool-Definitionen, Projektkontext, Verhaltensrichtlinien. Dieser Inhalt ist bei jedem einzelnen Schritt einer Sitzung identisch.
Der dynamische Tail: Benutzernachrichten, Tool-Ausgaben, Terminalbeobachtungen. Dieser ist für jede Anfrage einzigartig und wächst, während das Gespräch fortschreitet.
Diese Unterscheidung ist alles. Das statische Präfix ist der teure Teil, den Sie ständig ohne Grund neu berechnen. Der dynamische Tail ist der einzige Teil, der tatsächlich eine frische Berechnung benötigt.
Prompt-Caching funktioniert, indem es den mathematischen Zustand des statischen Präfix speichert, sodass zukünftige Anfragen dessen Neuberechnung vollständig überspringen können. Sie bezahlen dafür, dieses Präfix einmal zu verarbeiten. Jeder nachfolgende Schritt liest stattdessen aus dem Speicher.
Warum das funktioniert: Was ein Transformer tatsächlich tut
Um wirklich zu verstehen, warum Caching so effektiv ist, müssen Sie verstehen, was im Modell passiert, wenn es Ihren Prompt liest.
Jede LLM-Inferenzanfrage hat zwei Phasen:
Phase 1: Prefill
Hier verarbeitet das Modell Ihren vollständigen Eingabe-Prompt. Es ist rechengebunden, was bedeutet, dass es dichte Matrixmultiplikationen über jedes Token in Ihrem Kontext ausführt. Das Modell liest alles und baut eine Repräsentation davon auf. Dies ist die langsame, teure Phase.
Phase 2: Decode
Hier generiert das Modell Ausgabe-Token, eines nach dem anderen. Es ist speichergebunden und nicht rechengebunden, da das Modell die meiste Zeit damit verbringt, zuvor berechnete Zustände zu lesen, anstatt schwere Berechnungen durchzuführen.
Während der Prefill-Phase baut der Transformer drei Vektoren für jedes Token auf: einen Query-, einen Key- und einen Value-Vektor. Der Aufmerksamkeitsmechanismus verwendet diese, um herauszufinden, wie jedes Token mit jedem anderen Token in der Sequenz zusammenhängt.
Hier ist die entscheidende Erkenntnis: Die Key- und Value-Vektoren hängen nur von den Token ab, die vor ihnen kamen. Sobald sie für ein bestimmtes Präfix berechnet wurden, müssen sie nie wieder geändert werden.
Die folgende Abbildung veranschaulicht visuell, was wir gerade besprochen haben:
Ohne Caching werden diese Key-Value-Tensoren verworfen, sobald eine Anfrage abgeschlossen ist. Die nächste Anfrage beginnt von vorne und berechnet sie für alle 20.000 Token erneut.
KV-Caching löst dies, indem es diese Tensoren speichert. Die Infrastruktur behält sie auf den Inferenzservern, indiziert durch einen kryptografischen Hash des Eingabetextes. Wenn eine neue Anfrage mit demselben Präfix eingeht, stimmt der Hash überein, die Tensoren werden sofort abgerufen, und das Modell überspringt die gesamte Berechnung.
Dies reduziert die Rechenkomplexität von O(n²) pro generiertem Token auf O(n). Für ein 20.000-Token-Präfix, das über 50 Schritte wiederholt wird, ist das eine enorme Reduktion.
Die Ökonomie
Das Verständnis der Preisstruktur macht diese architektonische Entscheidung so folgenreich.
So bepreist Anthropic das Caching über seine Modellfamilien hinweg:
Drei Zahlen, die Sie verinnerlichen sollten:
- Cache-Lesevorgänge kosten 10 % des Basis-Eingabepreises, ein Rabatt von 90 % auf jedes aus dem Cache gelesene Token
- Cache-Schreibvorgänge kosten 25 % mehr als der Basis-Eingabepreis, eine kleine Prämie für die Speicherung der KV-Tensoren
- Erweitertes 1-Stunden-Caching kostet das Zweifache des Basispreises
Die Rechnung geht nur auf, wenn Ihre Cache-Trefferquote hoch bleibt. Was uns zum besten realen Beispiel dafür führt, wie das in der Praxis aussieht.
Claude Code: Ein 30-minütiger Sitzungsdurchlauf
Claude Code ist vollständig auf ein Ziel ausgerichtet: den Cache heiß halten.
Um konkret zu verstehen, was das bedeutet, gehen wir durch, wie eine typische 30-minütige Codierungs-Sitzung aussieht, und verfolgen genau, was abgerechnet wird und was nicht.
Minute 0: Sitzungsbeginn
Claude Code lädt seinen System-Prompt und die Tool-Definitionen. Es liest auch die CLAUDE.md-Datei in Ihrem Projektstammverzeichnis, welche die Codebasis und Konventionen beschreibt. Diese Nutzlast übersteigt regelmäßig 20.000 Token.
Dies ist der teuerste Moment der gesamten Sitzung. Jedes einzelne Token ist neu. Aber Sie bezahlen diese Kosten nur einmal.
Minuten 1 bis 5: Erste Befehle
Sie geben Ihre erste Anweisung ein, so etwas wie "Sieh dir das Auth-Modul an und schlage Verbesserungen vor."
Claude Code entsendet einen Explore-Subagenten. Er navigiert durch die Codebasis, öffnet Dateien, führt grep-Befehle aus und baut sich ein Bild des relevanten Codes auf. All dies wird an den dynamischen Tail angehängt.
Die 20.000-Token-statische Grundlage? Bereits im Cache. Wird zu $0,30/MTok statt $3,00/MTok zurückgelesen. Sie bezahlen nur für die neuen Tool-Ausgaben und Ihre Nachricht.
Minuten 6 bis 15: Tiefe Arbeit
Der Plan-Subagent erhält die Ergebnisse des Explore-Subagenten. Anstatt die rohen Ergebnisse wörtlich weiterzugeben (was den dynamischen Tail unnötig aufblähen würde), übergibt Claude Code eine prägnante Zusammenfassung. Dies hält den Suffix handhabbar und den Cache effizient.
Der Planer erstellt einen strukturierten Implementierungsplan. Sie prüfen ihn, genehmigen ihn, und Claude Code beginnt mit Änderungen. Jeder Schritt in dieser Schleife liest das 20.000-Token-Präfix aus dem Cache. Jeder Cache-Treffer setzt die TTL zurück und hält den Cache für zukünftige Schritte warm.
Minuten 16 bis 25: Iteration
Sie bitten um Anpassungen. Claude Code überarbeitet seinen Ansatz. Weitere Tool-Aufrufe, mehr Terminal-Ausgabe. Der dynamische Tail wächst, repräsentiert aber nur die neuen, einzigartigen Inhalte dieser Sitzung.
An diesem Punkt hat die Sitzung insgesamt Hunderttausende von Token verarbeitet. Aber die 20.000-Token-Grundlage wurde bei jedem einzelnen Schritt aus dem Cache gelesen.
Minute 28: Ausführen von /cost
Ohne Caching würde eine solche Sitzung leicht 2 Millionen Token überschreiten. Zu Sonnet 4.5-Preisen sind das rund $6,00.
Mit effizientem Caching:
- Die überwältigende Mehrheit der Token wird zu $0,30/MTok aus dem Cache gelesen
- Nur die neuen dynamischen Tail-Token werden frisch berechnet
In der Praxis würden Sie eine Kostenreduzierung von 80 % oder mehr für eine einzelne Aufgabe erwarten. Multiplizieren Sie das mit jedem Benutzer, jeden Tag.
Zusammenfassend sieht das Layout des System-Prompts im Verlauf der Sitzung so aus:
Die Regel, die alles zerbricht
Hier ist die kontraintuitivste Sache über Prompt-Caching.
1 + 2 = 3. Aber 2 + 1 ist ein Cache-Fehlschlag.
Die Infrastruktur hasht den Prompt. Der Hash ist ein Identifikator für die Kryptographie. Der Hash ändert sich, wenn sich irgendetwas in dieser Reihenfolge ändert, selbst wenn zwei Elemente in einer anderen Reihenfolge sind. Der Cache ist leer. Das gesamte Präfix wird zum vollen Preis neu berechnet.
Drei Regeln, die daraus folgen:
- Fügen Sie während einer Sitzung keine Tools hinzu oder entfernen Sie sie. Das zwischengespeicherte Präfix enthält Tools. Das Ändern der Tools macht alles, was danach kommt, unbrauchbar.
- Wechseln Sie niemals mitten in einer Sitzung das Modell. Caches sind modellspezifisch. Der Wechsel zu einem günstigeren Modell mitten im Gespräch erfordert den Neuaufbau des gesamten Caches.
- Ändern Sie niemals das Präfix, um den Zustand zu ändern. Stattdessen fügt Claude Code der nächsten Benutzernachricht ein Tag hinzu, das das System erinnert. Das Präfix ändert sich nie.
Was es für Sie bedeutet
Alles oben Genannte erklärt, wie Claude Code mit Caching umgeht. Dieselben Regeln gelten, wenn Sie Ihren eigenen Agenten erstellen.
So sollten Sie Ihre Prompts strukturieren:
- Ganz oben stehen Systemanweisungen und Regeln. Ändern Sie sie nicht in der Mitte.
- Laden Sie alle Tools, die Sie benötigen, im Voraus. Fügen Sie keine hinzu oder entfernen Sie sie.
- Abgerufener Kontext und Dokumente danach. Statisch für die Dauer.
- Ganz unten, die Geschichte des Gesprächs und die Ausgaben der Tools.
Bei eingeschaltetem Auto-Caching verschiebt sich der Haltepunkt automatisch nach vorne, während das Gespräch weitergeht.
Claude Code ist für seinen eigenen Cache verantwortlich. Anthropic hat gerade Auto-Caching zu seiner API hinzugefügt, sodass Sie dasselbe für Ihren eigenen Agenten tun können.
Ohne Auto-Caching mussten Sie sich merken, wo die Token-Grenzen waren. Eine falsche Grenze bedeutete, dass der Cache nicht erreicht wurde.
Verwenden Sie cache-sicheres Forking, um für das Kontextlimit zu komprimieren. Verwenden Sie denselben System-Prompt, dieselben Tools und dasselbe Gespräch und fügen Sie dann die Komprimierung als neue Nachricht hinzu.
Der Komprimierungsaufruf sieht fast genauso aus wie der letzte. Das zwischengespeicherte Präfix wird erneut verwendet. Das Einzige, was als neu abgerechnet wird, ist die Komprimierungsanweisung.
Um zu überprüfen, ob eine API funktioniert, behalten Sie diese drei Felder in jeder Antwort im Auge:
- cache_creation_input_tokens: Token, die in den Speicher eingefügt wurden
- cache_read_input_tokens: Token, die aus dem Speicher gelesen wurden
- input_tokens: Token, die wie gewohnt verarbeitet wurden
Ihr Cache-Effizienzwert ist die Anzahl der gelesenen Token im Vergleich zur Anzahl der erstellten Token. Behalten Sie ihn im Auge, so wie Sie die Betriebszeit im Auge behalten.
Wichtige Erkenntnisse
Prompt-Caching ist keine Funktion, die Sie einschalten. Es ist eine architektonische Disziplin, die Sie aufbauen.
Claude Code ist das beste Beispiel dafür, wie das im großen Maßstab aussieht.
Eine Cache-Trefferquote von 92 %. Eine Kostensenkung von 81 %.
Dies ist die Blaupause, wenn Sie Agenten erstellen. Sie können die Steuer nicht ignorieren; sie existiert. Das Einzige, was zählt, ist, ob Sie dafür bezahlen oder sie loswerden.
