Die neue prompt-caching API von Claude Opus 5 senkt die Token-Kosten für Chat-basierte Anwendungen drastisch, indem sie es dem Modell ermöglicht, unveränderten Text nicht erneut lesen zu müssen. Die erste Anfrage erfordert einen bescheidenen Aufschlag; jeder nachfolgende Aufruf kostet etwa ein Zehntel des Basissatzes, wodurch eine wiederkehrende Ausgabe zu einer einmaligen Gebühr wird.

Warum Entwickler doppelt für dieselben Wörter bezahlen

Die meisten konversationellen Schnittstellen bauen bei jedem Durchgang den vollständigen Prompt neu auf: Ein 8.000-Token-Systemprompt, angehängte PDFs und die gesamte Dialoghistorie werden jedes Mal zusammen an das Modell gesendet, wenn ein Benutzer eine Folgefrage stellt. Das Modell verarbeitet jeden Token erneut, obwohl der Großteil dieses Textes sich nie ändert. Bei der aktuellen Preisgestaltung können diese Redundanzen die Kosten eines viel genutzten Bots dominieren.

Wie der Cache die Kalkulation verändert

Die API erstellt für jeden „Block“ von Token bis zu einem definierten Breakpoint einen Cache-Eintrag. Wenn die nächste Anfrage denselben Block am Anfang enthält, liest der Dienst ihn aus dem Cache, anstatt ihn erneut zu tokenisieren. Die Preisaufteilung spiegelt die eingesparte Arbeit wider:

  • Cache-Schreibvorgang – 5-Minuten-TTL: 1,25 × Basissatz
  • Cache-Schreibvorgang – 1-Stunden-TTL: 2 × Basissatz
  • Cache-Lesevorgang (Hit): 0,1 × Basissatz

In der Praxis kostet der erste Aufruf eines neuen Blocks etwas mehr als eine normale Anfrage. Jeder spätere Aufruf, der den Cache nutzt (Hit), ist 90 % günstiger, sodass die Nettoausgaben drastisch sinken, je tiefer das Gespräch voranschreitet.

Die „goldene Regel“ für die Strukturierung von Prompts

Die Effektivität des Caches hängt davon ab, wo Sie statische gegenüber dynamischen Inhalten platzieren. Setzen Sie alles, was gleich bleibt, an den Anfang und schieben Sie die sich ständig ändernden Teile ans Ende. Eine zuverlässige Reihenfolge sieht so aus:

  1. Tools – Definitionen aller externen Funktionen, die das Modell aufrufen kann.
  2. Systemanweisungen – das übergeordnete Verhalten, das das Modell befolgen soll.
  3. Dokumente – langer Kontext wie PDFs, Wissensdatenbanken oder Auszüge aus Richtlinien.
  4. Benutzerfragen – die aktuelle Abfrage, die sich bei jedem Durchgang ändert.

Wenn Sie einen Token vor einem Breakpoint ändern, wird der Cache-Eintrag ungültig und das Modell muss alles, was darauf folgt, erneut verarbeiten.

Versteckte Limits, die Sie beachten müssen

  • Minimale Blockgröße – Opus 5 cached nur Blöcke, die mindestens 512 Token enthalten. Alles, was kleiner ist, fällt komplett durch den Cache.
  • Zeitstempel-Bug – das Einfügen eines sich ändernden Zeitstempels innerhalb eines gecachten Blocks garantiert einen Cache-Miss, da der Text des Blocks nie exakt übereinstimmt.
  • 20-Block-Rückblick – der Dienst scannt nur die letzten 20 Blöcke nach einer Übereinstimmung. Lang laufende Sitzungen, die schnell voranschreiten, können das Cache-Fenster überholen.
  • Parallele Anfragen – das gleichzeitige Senden mehrerer identischer Anfragen wird dazu führen, dass alle den Cache verfehlen, da der Cache erst nach Abschluss der ersten Anfrage befüllt wird. „Wärmen“ Sie den Cache mit einem einzelnen Aufruf auf und senden Sie dann den Rest.

Die Ersparnis in Ihrer API-Antwort erkennen

Jede Antwort meldet drei Token-Zähler:

  • cache_read_input_tokens – Token, die aus einem Cache-Hit stammen.
  • cache_creation_input_tokens – Token, die in dieser Anfrage in den Cache geschrieben wurden.
  • input_tokens – die neuen Token, die nicht gecacht wurden.

Addieren Sie die drei Zahlen, um die Gesamtzahl der Token zu erhalten, die das Modell für diesen Durchgang berücksichtigt hat. Wenn beide Cache-Felder Null sind, hat die Anfrage den Cache verfehlt; überprüfen Sie Ihre Blockgröße und die Platzierung der Breakpoints.

Fazit: Durch das Voranstellen unveränderlicher Kontexte und das Delegieren der Schwerstarbeit an die prompt-caching API von Claude Opus 5 verwandeln Sie wiederkehrende Token-Ausgaben in eine einmalige Gebühr. Das Ergebnis ist eine dramatische Kostensenkung für jeden Chatbot, der wiederholt auf denselben Systemprompt oder denselben Dokumentensatz verweist – vorausgesetzt, Sie respektieren die Token-Untergrenze, vermeiden veränderliche Marker innerhalb gecachter Blöcke und halten Ihre cache-fähigen Inhalte innerhalb des 20-Block-Horizonts.