Blog
Was Prompt Caching wirklich gespart hat, in echten Zahlen
Zwei Wochen Prompt Caching in einer laufenden Agent-Fleet. Was der Cache gebracht hat, was ich falsch verkabelt habe und warum ein Timestamp an der falschen Stelle alles teurer gemacht hat.
07. Juli 2026
Prompt Caching hatte ich lange als nice-to-have abgetan. So ein Feature das in der Doku gut aussieht, aber im echten Betrieb kaum was bringt. Dann habe ich es in eine laufende Agent-Fleet eingebaut, die jeden Tag dutzende Runs fährt, und zwei Wochen zugeschaut. Hier sind die Zahlen und die zwei Stellen an denen ich mir selbst ins Knie geschossen habe.
Der Ausgangspunkt: jeder Agent-Run schickt denselben System-Block mit. Produkt-Kontext, Voice-Regeln, Verifikations-Pflichten. Zusammen ungefähr 11.000 Tokens die sich von Run zu Run nicht ändern. Bei rund 40 Runs am Tag sind das 440.000 Tokens täglich, die immer wieder denselben Prefix durch das Modell schieben. Genau dafür ist der Cache da.
## Wie der Cache eingeschaltet wird
Der Trick ist ein einziges Feld. Du markierst den stabilen Anfang deines Prompts mit einem `cache_control` Block. Alles von oben bis zu diesem Marker wird gecacht.
```json
{
"system": [
{
"type": "text",
"text": "<11k Tokens Produkt-Kontext, Voice-Regeln, Verifikations-Pflichten>",
"cache_control": { "type": "ephemeral" }
}
]
}
```
Wichtig ist das byte-genaue Matching. Der Cache greift nur wenn der Text vor dem Marker exakt gleich ist wie beim letzten Mal. Ein einziges geändertes Zeichen und der ganze Block wird neu geschrieben statt gelesen. Die TTL liegt bei etwa fünf Minuten, das heißt der Cache muss innerhalb dieses Fensters wieder getroffen werden sonst fällt er raus.
## Die Zahlen nach zwei Wochen
Auf dem System-Prompt haben wir ungefähr 78 Prozent der Input-Kosten gespart. Nicht auf den Gesamtkosten, das ist wichtig, denn die variablen Teile eines Runs zahlst du weiter voll. Aber der 11k-Prefix macht bei kurzen Tasks einen dicken Anteil aus.
Spürbarer war die Latenz. Time-to-first-Token lag vorher im Median bei 1,9 Sekunden. Auf Cache-Hits ging das runter auf 0,7 Sekunden. Bei einem interaktiven Agent merkst du diesen Unterschied sofort.
Die Cache-Write-Rate ist am Ende bei rund 6 Prozent gelandet. Das heißt 94 von 100 Runs haben den Cache gelesen statt neu geschrieben. Am Anfang lag diese Rate bei fast 100 Prozent, was genau das Gegenteil von dem war was ich wollte.
## Der Fehler
Zwei Sachen habe ich verbockt. Die erste war peinlich. Ich hatte oben in den System-Block einen Timestamp geschrieben, damit der Agent das aktuelle Datum kennt. Der Timestamp änderte sich jeden Tag, aber weil er VOR dem Marker stand, war der gecachte Text bei jedem neuen Tag byte-verschieden. Ergebnis: fast 100 Prozent Cache-Write-Rate. Ich habe zwei Wochen lang für den Cache-Schreibvorgang extra bezahlt und nie einen Treffer gehabt. Prompt Caching hatte mich teurer gemacht, nicht billiger.
Nachdem ich den Timestamp nach unten verschoben hatte, kam der zweite Fehler. Ich hatte den Marker mitten in den stabilen Block gesetzt statt ans Ende. Dadurch wurde nur die erste Hälfte gecacht. Die restlichen 5.000 stabilen Tokens habe ich weiter voll bezahlt, obwohl sie sich nie änderten. Erst als ich den Marker ans echte Ende des unveränderlichen Teils geschoben hatte, stimmte die Rechnung.
## Was ich daraus mitnehme
1. Alles Variable gehört HINTER den Marker. Timestamp, Session-Daten, User-Input. Nur das was über viele Runs identisch bleibt darf davor stehen.
2. Der Marker gehört ans Ende des stabilen Blocks, nicht in die Mitte. Jeder Token vor dem Marker der nicht gecacht wird ist verschenktes Geld.
3. Miss die Cache-Write-Rate, nicht nur die Kosten. Eine hohe Write-Rate ist das Warnsignal dass dein Prefix instabil ist. Bei uns war der Sprung von fast 100 Prozent auf 6 Prozent der Beweis dass es endlich funktioniert.
4. Die fünf Minuten TTL sind bei seltenen Runs ein Thema. Wenn dein Agent nur alle zehn Minuten läuft, ist der Cache jedes Mal kalt. Dann bringt das Feature wenig.
Wenn du tiefer einsteigen willst wie man den Prefix sauber aufbaut, steht das im Playbook [Prompt Caching meistern](/playbooks/prompt-caching-meistern). Und wenn du Caching mit Tool-Setups kombinieren willst, passt die Lesson [MCP Tool Hooks](/levels/4/10-mcp-tool-hooks) dazu. Die offizielle Spezifikation mit allen Grenzwerten findest du in der [Anthropic Doku zu Prompt Caching](https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching).