Wiederholte Prompt-Kosten mit einer Zeile Prompt-Caching um 90% senken

Erneut zahlen für Text, der sich nie ändert

Irgendwo in Ihrer Codebasis steht ein Textblock, für den Sie zehntausendmal bezahlt haben, obwohl er sich kein einziges Mal geändert hat. Öffnen Sie das Nutzungs-Dashboard und stellen Sie die Input-Tokens von gestern der Zahl der Anfragen gegenüber. Liegt das Verhältnis nahe an der Größe Ihres System-Prompts, betrifft Sie das. Sie haben den vollen Preis dafür bezahlt, immer wieder dieselbe Wand aus Anweisungen zu schicken, und das Modell liest sie jedes Mal von Null, als hätte es Sie nie gesehen.

Nehmen wir einen Support-Bot mit rund 9000 Tokens an Richtliniendokumenten im System-Prompt und etwa 40.000 Aufrufen im Monat. Jeder Aufruf hat diesen ganzen Block über die Leitung geschleppt. Die Lösung ist eine einzige Zeile. Es gibt allerdings auch eine Falle, die diese Zeile wertlos macht, dazu unten mehr, und genau dort verlieren die meisten die Einsparungen, die sie eingeschaltet zu haben glauben.

Auf dem Server erinnert sich nichts an Ihren Kontext

Die Messages API ist zustandslos. Nirgends wartet eine Sitzung, die Ihren Prompt zwischen den Aufrufen warmhält. Jede Anfrage baut den Prompt von Grund auf neu, tokenisiert ihn, schickt ihn durch das Modell und verwirft die Arbeit. Der nächste Aufruf wiederholt das zum gleichen Preis.

without caching

call 1   [ 9,000 tok system ][ 40 tok question ]   full price
  call 2   [ 9,000 tok system ][ 35 tok question ]   full price
  call 3   [ 9,000 tok system ][ 52 tok question ]   full price
            ^^^^^^^^^^^^^^^^^
            same bytes, billed three times

Die Änderung in einer Zeile

So schreiben die meisten den Aufruf:

resp = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    system=DOCS,
    messages=[{"role": "user", "content": q}],
)

Und das ist die gesamte Lösung, ein zusätzliches Feld oberhalb von system:

cache_control={"type": "ephemeral"},

Dieses Feld auf oberster Ebene schaltet das automatische Caching ein. Die API setzt den Breakpoint auf den letzten cachebaren Block und schiebt ihn nach vorn, wenn das Gespräch wächst.

Den usage-Block prüfen

Verlassen Sie sich nicht auf den Eindruck, dass es schneller geworden ist. Lesen Sie die Nutzungsdaten, die die API mit jeder Antwort zurückgibt:

creation    read    input
  call 1  cold          9012       0       40
  call 2  warm             0    9012       35

Auf die zweite Zeile kommt es an. Neuntausend Tokens kamen für ein Zehntel des Preises aus dem Cache, während input_tokens auf den Teil nach dem Breakpoint schrumpft.

Die Falle

Setzen Sie einen Zeitstempel an den Anfang des System-Prompts, einen Benutzernamen oder das aktuelle Datum, weil es harmlos wirkte, und das Präfix ändert sich mit jeder Anfrage. Der Hash passt nie, Sie zahlen dauerhaft den Aufschlag fürs Schreiben und bekommen null Lesetreffer. Das ist schlimmer, als gar nichts zu tun.

Der API ist eine feste Reihenfolge wichtig. Stabiler Inhalt kommt zuerst, alles Veränderliche zuletzt:

tools  ->  system  ->  messages

[ stable stuff ----------------- | volatile ]
                                    ^
                               breakpoint lives here

Wenn keine Cache-Lesetreffer kommen

Es gilt eine Mindestlänge, und wenn sie nicht erreicht wird, sagt Ihnen das niemand. Das Minimum liegt bei 512 Tokens für Opus 5, 1024 für Sonnet 5 und 4096 für Haiku 4.5. Darunter gibt es kein Caching und keine Fehlermeldung, nur die Rechnung, die Sie vermeiden wollten.

Der Cache hält 5 Minuten und wird bei jedem Treffer kostenlos verlängert, gleichmäßiger Traffic hält ihn also von selbst warm. Liegen Ihre Aufrufe weiter auseinander, fordern Sie eine TTL von einer Stunde an. Denken Sie auch daran, dass der Abgleich bytegenau ist: ein zusätzliches Leerzeichen, eine umsortierte Tool-Definition oder eine geänderte Einstellung, und Sie zahlen ohne Vorwarnung wieder den vollen Preis.

Über die eine Zeile hinaus

Später können Sie auf explizite Breakpoints umsteigen und cache_control an einzelne Blöcke hängen, von denen vier erlaubt sind. Sinnvoll ist es, sie an die Tool-Definitionen und ans Ende der Dokumente zu setzen, denn Tools ändern sich selten, Dokumente dagegen wöchentlich. Fangen Sie trotzdem mit der einen Zeile an: ausrollen, die usage-Felder beobachten und erst dann raffiniert werden.

In Agenten-Schleifen verstärkt sich der Effekt. Eine Aufgabe mit zehn Tool-Aufrufen liest dasselbe Präfix zehnmal, sodass Caching beim letzten Durchlauf nicht mehr nur ein wenig spart, sondern das Feature überhaupt erst bezahlbar macht.