Cache-Mechanik, Preisstufen, TTL-Dauern und Mindest-Token-Schwellen ändern sich, während Anthropic die Plattform aktualisiert. Verlasse dich nicht auf bestimmte Zahlen aus Drittanbieter-Leitfäden. Prüfe für aktuelle Werte immer die offizielle Prompt-Caching-Doku und die Seite Modelle & Preise.
Ökonomie des Prompt-Cachings
Jedes Mal, wenn du die Claude API aufrufst, bezahlst du für jeden Eingabe-Token, den du sendest — einschließlich deines System-Prompts, deiner Werkzeugdefinitionen und jeglichen Kontexts, den du einfügst. Wenn du viele Aufrufe mit demselben großen Präfix machst, bezahlst du jedes einzelne Mal dafür, diesen Präfix von Grund auf neu zu verarbeiten.
Prompt-Caching ändert das. Du markierst einen stabilen Teil deines Prompts als cachebar. Der erste Aufruf verarbeitet ihn und speichert ihn. Nachfolgende Aufrufe, die den Cache treffen, überspringen diese Verarbeitung — und zahlen für diese Tokens einen Bruchteil des normalen Tarifs.
Die Einsparungen sind nicht kosmetisch. Für Anwendungen mit großen, stabilen System-Prompts oder schwerem Kontext kann Caching die Ökonomie einer Funktion von „zu teuer zum Ausliefern" zu „im Grunde gratis im Betrieb" verändern.
Das mentale Modell: stabiler Präfix, flüchtiges Suffix
Stell dir jeden API-Aufruf als zwei Teile vor:
Der stabile Präfix — Inhalt, der sich über Aufrufe hinweg nicht ändert. Hier greift das Caching. Beispiele:
- Dein System-Prompt
- Werkzeugdefinitionen
- Ein großes Referenzdokument oder eine Codebasis, die du bei jedem Aufruf einfügst
- Ein langer Few-Shot-Beispielblock
Das flüchtige Suffix — Inhalt, der sich pro Aufruf ändert. Hier greift das Caching nicht. Beispiele:
- Die aktuelle Nutzernachricht
- Echtzeitdaten, die du pro Anfrage einfügst
- Gesprächsverlauf, der mit jedem Turn wächst
Die Regel ist einfach: Strukturiere deine Prompts so, dass der stabile Inhalt zuerst kommt und der sich ändernde Inhalt zuletzt. Cache-Breakpoints sind positionsabhängig — alles vor dem markierten Breakpoint ist für das Caching geeignet; alles danach nicht.
Wenn du dynamischen Inhalt vor statischen Inhalt setzt, zerstörst du den Cache, weil sich der Präfix bei jeder Anfrage ändert.
Wie das Kostenmodell funktioniert
Prompt-Caching führt eine dreifache Aufteilung dabei ein, wie Eingabe-Tokens bepreist werden:
| Token-Typ | Wann er auftritt | Kosten relativ zur normalen Eingabe |
|---|---|---|
| Cache-Schreiben | Erster Aufruf oder nach Ablauf des Caches | Höher als normale Eingabe |
| Cache-Lesen | Nachfolgende Aufrufe, die den Cache treffen | Viel niedriger als normale Eingabe |
| Reguläre Eingabe | Tokens nach dem letzten Cache-Breakpoint | Normaler Tarif |
Die exakten Multiplikatoren stehen auf der offiziellen Preisseite und schwanken — prüfe sie direkt. Was sich nicht ändert, ist die Struktur: Schreibvorgänge kosten mehr als normal, Lesevorgänge kosten viel weniger. Der Umschlagpunkt — wann du genug gecachte Aufrufe gemacht hast, um den Schreib-Overhead wieder hereinzuholen — kommt bei jedem Prompt mit substanziellem stabilem Inhalt schnell.
Die Latenz folgt demselben Muster. Cache-Lesevorgänge überspringen die vollständige Verarbeitung des gecachten Teils, was die Zeit bis zum ersten Token bei Aufrufen mit großen Präfixen spürbar reduziert.
Wann Prompt-Caching hilft
Caching zahlt sich aus, wenn zwei Bedingungen beide erfüllt sind:
- Du hast einen substanziellen stabilen Präfix (es gibt eine Mindest-Token-Schwelle, unterhalb derer Caching nicht verfügbar ist — prüfe die aktuelle Doku für die genaue Zahl pro Modell).
- Dieser Präfix wird häufig genug wiederverwendet, um den Cache mehr als gelegentlich zu treffen.
Szenarien, in die Caching natürlich passt:
- Dokument-Q&A — dasselbe große Dokument wird für viele Nutzerfragen eingefügt.
- Coding-Assistenten — eine große Codebasis oder ein Dateibaum ist in jeder Anfrage enthalten.
- Agentische Loops — derselbe System-Prompt und dieselben Werkzeugdefinitionen werden bei jedem Schritt eines mehrstufigen Workflows gesendet.
- Konversationsagenten mit langen Anweisungen — eine detaillierte Persona, ein Regelwerk oder eine Wissensbasis, die sich von Aufruf zu Aufruf nie ändert.
- Stapelverarbeitung — viele Eingaben laufen gegen dieselbe Vorlage.
Wann Prompt-Caching nicht hilft
Caching ist nicht nützlich, wenn:
- Deine Prompts kurz sind (unterhalb der minimalen cachebaren Token-Schwelle).
- Dein Präfix sich bei jedem Aufruf ändert — einen Zeitstempel, einen nutzerspezifischen Kontext oder irgendeine Personalisierung in den „stabilen" Teil einzufügen, macht den Cache ungültig.
- Du seltene Aufrufe mit langen Pausen dazwischen machst. Gecachte Inhalte laufen nach einer TTL ab (eine Dauer, die du innerhalb der von der API unterstützten Grenzen konfigurieren kannst). Wenn dein Traffic spärlich ist, zahlst du meist Schreibkosten bei wenigen Lesevorgängen.
- Dein Präfix relativ zum dynamischen Inhalt pro Aufruf klein ist. Die Einsparungen skalieren mit der Größe dessen, was gecacht wird.
Prompts cache-freundlich strukturieren
Die einzige strukturelle Anforderung ist die Reihenfolge: Stabiler Inhalt muss vor flüchtigem Inhalt kommen.
In der Praxis:
[System-Prompt — Anweisungen, Persona, Regeln]
[Werkzeugdefinitionen — falls statisch]
[Große eingefügte Dokumente oder Kontext — falls über Aufrufe hinweg gleich]
--------- Cache-Breakpoint hier ---------
[Dynamischer Inhalt pro Aufruf — Nutzernachricht, für diese Anfrage spezifische abgerufene Chunks]
Du markierst den Breakpoint mit einem cache_control-Feld am letzten Block, den du in den Cache aufnehmen willst. Alles vor diesem Marker ist für das Caching geeignet; alles danach ist reguläre Eingabe.
Du kannst bis zu vier explizite Breakpoints in einer einzigen Anfrage platzieren. Das ist nützlich, wenn sich verschiedene Teile deines Prompts unterschiedlich häufig ändern — zum Beispiel ändern sich Werkzeugdefinitionen selten, der Gesprächsverlauf bei jedem Turn. Jeder Abschnitt kann seinen eigenen Breakpoint haben.
Regeln zur Cache-Invalidierung
Der Cache ist empfindlich gegenüber der Reihenfolge. Jede Änderung an einem gecachten Block oder an einem Block, der ihm im Prompt vorausgeht, macht den Cache an diesem Breakpoint und allen nachfolgenden ungültig.
Änderungen an Werkzeugdefinitionen machen alle Caches ungültig. Änderungen am System-Prompt machen den System- und den Nachrichten-Cache ungültig. Änderungen mitten im Gespräch betreffen nur den Nachrichten-Cache.
Die praktische Folge: Wenn du irgendetwas einfügst, das sich pro Anfrage ändert, stelle absolut sicher, dass es nach dem letzten Cache-Breakpoint lebt, nicht davor oder darin.
Vorwärmen und Überwachen
Du kannst den Cache vorwärmen, bevor Nutzer-Traffic eintrifft, indem du eine Anfrage mit max_tokens: 0 sendest — das schreibt den Cache, ohne eine Ausgabe zu erzeugen. Nützlich für Batch-Jobs oder um die Schreibkosten in Nebenzeiten vorzuziehen.
Das usage-Feld der API-Antwort sagt dir, wie viele Tokens aus dem Cache gelesen (cache_read_input_tokens), in den Cache geschrieben (cache_creation_input_tokens) und als reguläre Eingabe abgerechnet wurden. Überwache diese, um zu verifizieren, dass dein Caching tatsächlich greift, und um die Einsparungen zu messen, die du erzielst.
Nutze den Kostenrechner, um erwartete Einsparungen zu modellieren, bevor du dich auf eine Caching-Architektur festlegst.
Das Fazit
Prompt-Caching ist keine Mikro-Optimierung. Für jede Anwendung, die denselben großen Präfix wiederholt sendet, ist es eine strukturelle ökonomische Entscheidung. Das Modell, um darüber nachzudenken, ist unkompliziert: Stabiler Inhalt kommt zuerst, flüchtiger Inhalt zuletzt, setze den Breakpoint an die Grenze.
Wenn du gegen die API baust und dir Caching noch nicht angeschaut hast, prüfe deine aktuellen Prompts auf große stabile Abschnitte. Wenn es sie gibt, ist das Aktivieren von Caching meist mit wenig Aufwand verbunden — und die Einsparungen sind real.