Leitfaden zu den Kosten für Prompt Caching: Cache Hits, Präfixe und tatsächliche API-Ausgaben

Die Kosten für Prompt-Caching hängen von drei Variablen ab: wie viel von Ihrem Prompt ein wiederverwendbares Präfix ist, wie oft sich dieses Präfix innerhalb des aktiven Cache-Fensters wiederholt und wie ein Anbieter Cache-Schreibvorgänge im Vergleich zu Cache-Hits bepreist. Wenn Sie diese drei Zahlen richtig bestimmen, kann Caching Ihre Kosten für Input-Token bei repetitiven Workloads deutlich senken; wenn Sie sie falsch einschätzen, zahlen Sie möglicherweise einen Aufpreis für Schreibvorgänge in einen Cache, der nie wiederverwendet wird.

Dieser Leitfaden unterscheidet zwischen dem, was Anbieter dokumentieren, was Sie auf öffentlichen API-Oberflächen verifizieren können und was Sie testen sollten, bevor Sie Produktionsbudgets für eine Caching-Strategie festlegen.

Wichtige Erkenntnisse

• Die Kosten für Prompt-Caching bestehen aus zwei Komponenten: Schreibkosten (werden normalerweise berechnet, wenn ein neuer Cache-Eintrag erstellt wird) und Hit-Kosten (werden normalerweise berechnet, wenn eine Anfrage diesen Eintrag wiederverwendet). Die Dokumentation von Anthropic beschreibt diese Unterscheidung zwischen Schreiben und Hit explizit; Sie sollten die aktuellen Multiplikatoren auf der Dokumentationsseite überprüfen, bevor Sie die Kosten modellieren.
• Cache-Hits erfordern eine exakte oder nahezu exakte Übereinstimmung des Präfixes bis zu einem definierten Breakpoint. Das Umordnen von Systemanweisungen, Tool-Definitionen oder Few-Shot-Beispielen vor diesem Breakpoint macht den Cache ungültig und erzwingt einen erneuten Schreibvorgang.
• Cache-Einträge verfallen nach einer vom Anbieter definierten Time-to-Live (TTL). Wenn Ihr Anfragevolumen für ein bestimmtes Präfix zu gering ist, um innerhalb dieses Zeitfensters zu liegen, zahlen Sie wiederholt Schreibkosten, anstatt Einsparungen durch Hits zu erzielen.
• Die Dokumentation von OpenRouter weist darauf hin, dass das Verhalten und die Preisgestaltung beim Prompt-Caching je nach zugrunde liegendem Anbieter und Modell variieren. Eine Caching-Strategie, die auf einem Backend Geld spart, lässt sich daher nicht automatisch auf ein anderes übertragen. Prüfen Sie die Unterstützung pro Modell, bevor Sie Traffic basierend auf angenommenen Einsparungen routen.

Wofür Sie beim Prompt-Caching tatsächlich bezahlen

Prompt-Caching ermöglicht es einem API-Anbieter, die verarbeitete Darstellung eines Prompt-Präfixes zu speichern, sodass nachfolgende Anfragen, die dieses Präfix teilen, redundante Berechnungen überspringen. Das daraus resultierende Abrechnungsmodell lautet nicht „gecachte Token sind kostenlos“. Es kommt eher dem Prinzip nahe: „Gecachte Token sind bei Wiederverwendung günstiger, aber der erste Schreibvorgang kostet mehr als ein Standard-Input-Token.“

Die Dokumentation zum Prompt-Caching von Anthropic legt diese Struktur direkt dar: Eine Anfrage, die einen neuen Cache-Eintrag erstellt, wird anders abgerechnet als eine Anfrage, die einen bestehenden Eintrag trifft. Die genauen Multiplikatoren ändern sich im Laufe der Zeit und je nach Modell. Betrachten Sie daher jede Zahl, die Sie in einem Blogbeitrag sehen – einschließlich dieses hier –, als einen Wert, den Sie anhand der aktuellen Dokumentation überprüfen sollten, anstatt als feste Konstante.

Die praktische Konsequenz ist, dass Prompt-Caching eine Wette auf Wiederverwendung ist. Wenn Ihr System-Prompt, Ihr Tool-Schema oder Ihr abgerufener Kontextblock einmal gesendet und nie wiederholt wird, fügt Caching einen Schreibaufschlag hinzu, ohne dass dem Einsparungen durch Hits gegenüberstehen. Wenn derselbe Block hunderte Male innerhalb des aktiven Cache-Fensters gesendet wird, können die Einsparungen durch Hits die Schreibkosten bei weitem überwiegen.

Wie Cache-Hits funktionieren: Präfixe, Präfixe und Breakpoints

Cache-Hits basieren auf Präfixen, nicht auf Inhalten im unscharfen Sinne. Der gecachte Teil eines Prompts muss mit der eingehenden Anfrage Token für Token bis zu dem Punkt übereinstimmen, an dem die Cache-Grenze, manchmal auch Breakpoint genannt, festgelegt ist. Die Dokumentation von Anthropic beschreibt dies als einen expliziten Mechanismus, bei dem Entwickler markieren, welcher Teil des Prompts für das Caching in Frage kommt – typischerweise die stabilen Systemanweisungen, Tool-Definitionen und langen Referenzdokumente, die sich zwischen den Aufrufen nicht ändern.

Dies hat eine direkte technische Konsequenz: Alles, was Sie vor dem Cache-Breakpoint platzieren, muss über Anfragen hinweg Byte-identisch sein, einschließlich Leerzeichen und Reihenfolge. Ein häufiger Fehler ist das Einfügen von anfragespezifischen Variablen (wie einem Zeitstempel oder einer Benutzer-ID) in den System-Prompt vor der Cache-Grenze. Diese einzelne Variable macht den Cache für das gesamte Präfix zunichte, und Sie zahlen bei jedem Aufruf Schreibkosten, anstatt Hits zu sammeln.

Die Lösung ist einfach: Behalten Sie wirklich statische Inhalte (Tool-Definitionen, interne Stilanweisungen, große Referenzdokumente) im gecachten Präfix und verschieben Sie alles, was anfragespezifisch ist, in das nicht gecachte Suffix, typischerweise die Benutzernachricht.

Die Cache-Lebensdauer ist genauso wichtig wie das Präfix-Design. Die Dokumentation von Anthropic beschreibt eine standardmäßige Cache-Dauer in Minuten, wobei für Workloads, die dies benötigen, eine Option mit längerer Dauer verfügbar ist. Wenn Ihr Traffic-Muster ein geteiltes Präfix alle paar Minuten sendet, kann ein kurzlebiger Cache ablaufen, bevor die nächste Anfrage eintrifft, und Sie zahlen am Ende wiederholt Schreibkosten. Hochfrequente Workloads (Chat-Sitzungen, Agenten-Schleifen, Batch-Pipelines, die direkt hintereinander laufen) sind weitaus bessere Kandidaten als niederfrequente, sporadische Aufrufe.

Modellierung der tatsächlichen API-Ausgaben: Ein praktischer Ansatz

Anstatt einen Einsparungsprozentsatz zu behaupten, modellieren Sie Ihren eigenen Workload mit dem folgenden Schema. Dieses Beispiel veranschaulicht die Anfragestruktur konzeptionell; überprüfen Sie die genauen Feldnamen und die aktuelle Preisgestaltung in der Dokumentation des Anbieters, bevor Sie sie implementieren.

{
  "model": "claude-sonnet-5",
  "system": [
    {
      "type": "text",
      "text": "You are a support agent. Full policy document follows...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "What is the refund window for order 48213?" }
  ]
}

Die cache_control-Markierung im Systemblock signalisiert, dass dieser Inhalt ein Kandidat für das Caching ist. Der erste Aufruf in einer Sitzung zahlt die Schreibkosten für diesen Block. Jeder nachfolgende Aufruf innerhalb des aktiven Cache-Fensters, der dasselbe Präfix wiederverwendet, zahlt die Hit-Rate anstelle der vollen Input-Rate für diese Token.

Um abzuschätzen, ob sich die Implementierung für Ihren Dienst lohnt, sammeln Sie vier Zahlen aus Ihren eigenen Protokollen:

1. Präfix-Größe: die Token-Anzahl des stabilen Inhalts, den Sie cachen möchten (System-Prompt, Tool-Schema, Referenzdokument).
2. Aufrufhäufigkeit innerhalb des TTL-Fensters: wie viele Anfragen dasselbe Präfix innerhalb der aktiven Cache-Dauer wiederverwenden.
3. Schreib- und Hit-Raten: aus der aktuellen Dokumentation des Anbieters entnommen, nicht aus dem Gedächtnis angenommen.
4. Suffix-Variabilität: ob der nicht gecachte Teil Ihres Prompts im Verhältnis zum gecachten Teil klein ist, da Einsparungen damit skalieren, wie viel des gesamten Prompts hinter dem Cache-Breakpoint liegt.

Wenn Ihr Präfix groß ist, Ihre Aufrufhäufigkeit innerhalb des TTL-Fensters hoch ist und Ihr Suffix klein ist, wird Caching die Ausgaben wahrscheinlich reduzieren. Wenn eine dieser drei Bedingungen schwach ist, führen Sie einen Kostenvergleich durch, bevor Sie Caching flächendeckend einführen. Der Leitfaden von TokenLab zur Senkung von KI-API-Kosten erläutert eine breitere Palette von Hebeln jenseits des Cachings, einschließlich Modellauswahl und Batching, unter /blog/cut-ai-api-costs-30-percent.

Entscheidungstabelle: Wann sich Prompt-Caching auszahlt

Workload-Muster	Caching wahrscheinlich hilfreich	Hinweise
Langer System-Prompt oder Tool-Schema, das über viele Aufrufe in einer Sitzung wiederverwendet wird	Ja	Klassischer Fall; Schreibkosten amortisieren sich über Hits
Großes abgerufenen Dokument, das über eine kurze Folge von Folgefragen wiederverwendet wird	Ja, wenn Aufrufe innerhalb der TTL liegen	TTL mit aktuellen Dokumenten abgleichen, bevor das Wiederverwendungsfenster angenommen wird
Einmalige Prompts ohne wiederkehrenden Traffic	Nein	Schreibaufschlag ohne Hit zum Ausgleich
Prompts mit hoher Variabilität, bei denen sich der „stabile“ Abschnitt ständig ändert	Nein	Jede Änderung vor dem Breakpoint macht den Cache ungültig
Agenten-Schleifen mit wiederholten Tool-Definitionen über viele Runden	Ja	Tool-Schemata sind erstklassige Caching-Kandidaten
Niederfrequente Batch-Jobs, die über die Cache-TTL hinausgehen	Nein	Cache läuft vor Wiederverwendung ab; Schreibkosten fallen jedes Mal an
Multi-Provider-Routing, bei dem nur einige Backends Caching unterstützen	Pro Modell prüfen	Gehen Sie nicht davon aus, dass Caching-Unterstützung über Anbieter hinweg übertragbar ist

Verwenden Sie diese Tabelle als erste Checkliste, nicht als endgültige Antwort. Bestätigen Sie TTL, Schreib-/Hit-Preise und Breakpoint-Mechaniken anhand der Anbieterdokumentation für das spezifische Modell, das Sie verwenden möchten, da sich diese Details ändern und je nach Modellfamilie variieren.

Unterschiede zwischen Anbietern, die Sie vor der Festlegung prüfen sollten

Prompt-Caching ist nicht überall identisch implementiert, und das ist wichtig, wenn Sie Traffic über mehrere Anbieter oder Modelle routen. Die Dokumentation von OpenRouter zu Best Practices für Prompt-Caching weist darauf hin, dass sich Caching-Unterstützung und -Verhalten je nach zugrunde liegendem Anbieter unterscheiden. Das bedeutet, dass eine Strategie, die auf die Cache-Mechanik eines Modells abgestimmt ist, nicht automatisch gilt, wenn Sie das Modell wechseln oder über ein anderes Backend routen.

Wenn Ihre Architektur Modell-Routing zur Kostenkontrolle verwendet (z. B. das Senden von Routine-Klassifizierungsaufgaben an ein kostengünstigeres Modell wie DeepSeek V4 Flash, GLM-5.2 oder Gemini 3.5 Flash, während Claude Sonnet 5 oder GPT-5.5 für schwierigere Schlussfolgerungsaufgaben reserviert werden), müssen Sie die Caching-Unterstützung für jedes Modell in dieser Routing-Tabelle unabhängig prüfen. Eine Caching-Strategie, die anhand der Dokumentation eines Modells validiert wurde, ist keine sichere Annahme für ein anderes. Die Ranking-Seite von TokenLab verfolgt Unterschiede auf Modellebene, die Sie als erste Referenz unter /models/rankings verwenden können, und die Analyse der Routing-Benchmarks unter /blog/ai-model-routing-benchmark-cost-per-task behandelt, wie Routing-Entscheidungen mit den Kosten pro Aufgabe interagieren, was sich mit Caching-Entscheidungen summiert, anstatt sie zu ersetzen.

Einschränkungen dieser Analyse

Dieser Leitfaden beschreibt die allgemeinen Mechanismen des Prompt-Cachings, wie sie von Anthropic dokumentiert und von OpenRouter zu den oben genannten Beobachtungsdaten referenziert werden. Er enthält keine exakten Schreib-/Hit-Multiplikatoren, exakten TTL-Dauern oder Preise pro Modell, da sich diese Zahlen ändern und je nach Modell unterscheiden. Bevor Sie ein Kostenmodell für Produktions-Traffic erstellen, ziehen Sie die aktuellen Zahlen direkt aus der oben verlinkten Anbieterdokumentation, anstatt sich auf feste Zahlen zu verlassen, die in Inhalten Dritter, einschließlich dieses Artikels, zitiert werden. Das Caching-Verhalten für auf Schlussfolgerungen ausgerichtete Modelle, multimodale Prompts und sehr lange Kontextfenster kann ebenfalls vom hier beschriebenen allgemeinen Präfix-Caching-Muster abweichen; überprüfen Sie dies anhand der Dokumentation für das spezifische Modell, das Sie verwenden möchten.

FAQ

Reduziert Prompt-Caching immer die API-Ausgaben? Nein. Es reduziert die Ausgaben nur, wenn ein stabiles Präfix innerhalb des aktiven Cache-Fensters häufig genug wiederverwendet wird, um die Schreibkosten auszugleichen. Sporadische oder hochvariable Prompts kosten mit aktiviertem Caching oft mehr als ohne.

Was macht einen Cache-Hit zunichte? Jede Änderung am Prompt-Inhalt vor dem Cache-Breakpoint, einschließlich Leerzeichen, Token-Reihenfolge oder einer einzelnen Variablen, die in einen ansonsten statischen System-Prompt eingefügt wird. Die Übereinstimmung muss bis zum Breakpoint exakt sein.

Ist Prompt-Caching bei allen Anbietern gleich implementiert? Nein. Anthropic dokumentiert einen expliziten Cache-Control-Mechanismus mit definierter Schreib- und Hit-Preisgestaltung. Die Dokumentation von OpenRouter weist darauf hin, dass Caching-Unterstützung und -Preisgestaltung je nach zugrunde liegendem Anbieter und Modell variieren. Sie sollten daher die Unterstützung pro Modell überprüfen, anstatt anzunehmen, dass sie übertragbar ist.

Wenn Sie bewerten, ob Prompt-Caching, Modell-Routing oder eine Kombination aus beidem zu Ihrem Traffic-Muster passt, beginnen Sie mit TokenLab, um Modelloptionen und Kostenstrukturen zu vergleichen, bevor Sie Produktionsbudgets festlegen.