Das Claude Code Team ruft den Notfall aus, wenn diese eine Kennzahl sinkt

Das Team hinter Claude Code hat gerade öffentlich erklärt — beiläufig, in einem Tweet — dass Prompt Caching die einzige Infrastruktur ist, die ihr gesamtes Produkt überhaupt funktionsfähig macht. Nicht eine nette Optimierung. Nicht ein kostensparender Trick. Das tragende Fundament.

Ihr Motto? "Cache Rules Everything Around Me."

Wer mit Wu-Tang aufgewachsen ist, erkennt die Referenz. Wer nicht — CREAM handelte davon, dass Cash alles regiert. Die Claude Code Version handelt davon, dass KV-Tensoren alles regieren. Gleiche Energie, andere Währung. Und genau wie beim Original: ignorierst du die Botschaft, wirst du dafür bezahlen.

Die meisten Entwickler, mit denen ich spreche, wissen nicht, was Prompt Caching ist. Sie wissen definitiv nicht, dass sie jedes Mal davon profitiert haben, wenn sie eine Claude Code Session öffnen. Und sie wissen absolut nicht, dass die Art, wie sie ihre Prompts strukturieren, entweder den Cache treffen oder verfehlen kann — was sie Geschwindigkeit, Geld oder beides kostet.

Das ist die vereinfachte Version.

Und ja, du machst es wahrscheinlich falsch.

$0.045 vs $0.005 — gleiche Anfrage, gleiches Modell, gleiches Ergebnis

Ich fange mit der Zahl an, die mich überhaupt erst für dieses Thema interessiert hat.

Eines meiner Convex-Projekte hat einen AI-Assistenten — ~6.000 Token System-Prompt, 12 Tool-Definitionen (Clerk Auth, Supabase Queries, ein paar Custom Actions), typische Gespräche mit 15–20 Runden. Standard-Zeug. Nichts Exotisches.

Ich habe meine API-Nutzung nach einer Woche gezogen und die Rechnung für ein 20-Runden-Gespräch gemacht:

• Ohne Caching: jede späte Anfrage verarbeitet ~15.000 Token Kontext zum vollen Preis. ~$0.045 pro Anfrage.
• Mit Caching: nur die letzten ~500 Token (neue Nachricht + vorherige Antwort) brauchen frische Berechnung. Alles andere trifft den Cache. ~$0.005 pro Anfrage.

Neun. Mal. Günstiger.

Hochgerechnet auf 1.000 Gespräche pro Tag redest du von $1.350/Monat vs $150/Monat. Ich habe Prompt Caching nicht durch einen Blog-Post oder Conference-Talk entdeckt. Ich habe es entdeckt, indem ich auf ein Stripe-Dashboard gestarrt und mich gefragt habe, warum meine Test-Umgebung Credits verbrennt wie ein Kind mit Geburtstagsgeld bei GameStop. Jedenfalls — der Punkt ist: ich hätte mir zwei Wochen Verwirrung gespart, wenn mir das jemand so erklärt hätte, wie ich es dir gleich erklären werde.

Was Prompt Caching wirklich ist (die Wu-Tang Version)

Jedes Mal, wenn du die Claude API aufrufst — oder jedes Mal, wenn Claude Code unter der Haube eine Action ausführt — wird ein Prompt zusammengebaut. Dieser Prompt hat vier Schichten:

• Der System-Prompt (deine Anweisungen, Persönlichkeit, Beschränkungen)
• Tool-Definitionen (alle Funktionen, die Claude aufrufen kann)
• Gesprächsverlauf (vorherige Nachrichten in der Session)
• Die neue User-Nachricht (was du gerade getippt hast)

Ohne Caching verarbeitet Claude jeden einzelnen dieser Token von Grund auf neu. Jedes Mal. Dein 8.000-Token System-Prompt? Neu verarbeitet. Deine 15 Tool-Definitionen? Neu verarbeitet. Die 40 vorherigen Nachrichten im Gespräch? Alles davon, von null — wie ein Goldfisch, der für immer zum ersten Mal dasselbe Buch liest.

Prompt Caching speichert die berechneten Key-Value-Tensoren (die schwere Mathematik, die das Modell während der "Prefill"-Phase macht) für ein exaktes Präfix deines Prompts. Nächste Anfrage mit demselben Präfix? Überspringe die Mathematik, verwende das gespeicherte Ergebnis wieder.

Der Cache lebt standardmäßig 5 Minuten. Die neueren Claude 4.5 Modelle unterstützen eine 1-Stunden-TTL bei 2x Schreibkosten. Und das Matching ist exakt — ein anderes Zeichen in deinem Präfix und der gesamte Cache wird ungültig. Es ist wie ein Fingerabdruckscanner, der auch deine Stimmung prüft.

CREAM. Cache Rules Everything Around Me. Jede Anfrage, die du sendest, trifft entweder den Cache und zahlt 0,1x den Input-Preis, oder verfehlt ihn und zahlt den vollen Preis. Es gibt kein Dazwischen.

Die 3 Fehler, die dein Geld verbrennen

Das ist der Teil, wo ich aufhöre, nett zu sein. Ein Research Paper namens "Don't Break the Cache" testete Caching-Strategien bei OpenAI, Anthropic und Google mit 500+ Agent-Sessions. Kombiniert mit dem, was das Claude Code Team geteilt hat, ist das Muster klar: die meisten Entwickler zerstören ihren Cache auf dieselben drei Arten.

Fehler #1: Dynamischen Mist in deinen System-Prompt einbauen.

Zeitstempel. Request-IDs. Benutzerspezifische Daten. Session-Token. Jedes Mal, wenn du etwas Dynamisches in deine System-Anweisungen stopfst, wird das gesamte Präfix einzigartig. Cache Miss. Voller Preis. Jedes einzelne Mal.

Das habe ich gemacht. Ich hatte ein "Current time: ${new Date().toISOString()}" in meinem System-Prompt für "Kontext." Hat mich wahrscheinlich $40 an unnötigen API-Calls gekostet, bevor ich es gemerkt habe. Der Fix dauerte 8 Sekunden — den Zeitstempel stattdessen in die User-Nachricht verschieben.

{
"system": [
{
"type": "text",
"text": "Du bist ein Code-Review-Assistent für eine Next.js + Convex App...",
"cache_control": {"type": "ephemeral"}
}
],
"messages": [
{"role": "user", "content": "Aktuelle Zeit: 2026-02-19T14:30:00Z\n\nReviewe diese Funktion..."}
]
}

Der cache_control-Tag sagt Anthropic: "cache alles bis hierher." Statischer System-Prompt = gecacht. Dynamischer Zeitstempel in der User-Nachricht = zerstört das Präfix nicht. Eine Umstrukturierung. 90% Ersparnis bei diesem Chunk.

Falls du das komplette Framework für System-Prompts willst, die nicht nur gut cachen, sondern tatsächlich zuverlässige Ausgaben produzieren, habe ich über Prompt Contracts geschrieben — gleiche Philosophie, anderer Winkel.

Fehler #2: Tools zwischen Anfragen neu ordnen.

Anthropic verarbeitet das cacheable Präfix in einer bestimmten Reihenfolge: Tools → System → Messages. Wenn dein Code Tool-Definitionen aus einer Map oder einem ungeordneten Set zusammenbaut, kann sich die Reihenfolge zwischen Anfragen ändern. Andere Reihenfolge = anderes Präfix = Cache Miss. Du hast kein einziges Tool geändert. Du hast nichts hinzugefügt oder entfernt. Du hast nur JavaScripts Objekt-Ordnungs-Eigenarten dich Geld kosten lassen.

Fix: sortiere deine Tools alphabetisch oder nach einem festen Index vor dem Senden. Sterbend langweilig. Extrem profitabel. Und falls du dich fragst, ob du überhaupt all diese Tool-Definitionen brauchst — CLIs könnten besser sein als MCPs. Weniger Tools = kleineres Präfix = einfacherer Cache Hit.

Fehler #3: Überhaupt keine Breakpoints verwenden (Anthropic-spezifisch).

Anders als OpenAI (das automatisch für Prompts über 1.024 Token cached), verlangt Anthropic, dass du explizit markierst, was mit cache_control-Breakpoints gecacht werden soll. Wenn du sie nicht hinzufügst, wird nichts gecacht. Du zahlst vollen Preis und wunderst dich, warum Claude sich langsam anfühlt.

Für Multi-Turn-Gespräche bekommst du insgesamt bis zu 4 Breakpoints. Die Forschung fand die optimale Aufteilung: 1 auf dem System-Prompt, 3 auf aktuellen User-Nachrichten. Das cached sowohl deine statischen Anweisungen als auch deinen aktuellen Gesprächsverlauf. Ohne die User-Message-Breakpoints entstehen durch intensive Tool-Nutzung zwischen Turns uncached Lücken, die immer größer werden — wie ein Memory Leak, aber für dein Portemonnaie.

Warum sich deine Claude Code Sessions schnell anfühlen (bis sie es nicht mehr tun)

Kurzer Abstecher für die Abo-Crowd. Falls du Claude Code (nicht die API) nutzt, konfigurierst du nichts davon manuell. Das Harness kümmert sich um Cache-Optimierung — es ist buchstäblich das, wofür das Team seine Engineering-Zeit aufwendet und worüber es anscheinend Notfälle ausruft.

Aber zu verstehen, wie es funktioniert, erklärt ein paar Dinge, die dir wahrscheinlich aufgefallen sind:

Die erste Nachricht in einer neuen Session ist immer langsamer. Das ist der Cache Write. Der System-Prompt, deine CLAUDE.md, alle Tool-Definitionen — werden zum ersten Mal berechnet und gespeichert. Jede Nachricht danach profitiert vom Cache. Der Cold Start ist das Warm-up.

Projekte mitten in der Session zu wechseln fühlt sich träge an. Anderer Projekt-Kontext = anderer System-Prompt = Cache Miss. Das System muss einen neuen Cache von Grund auf bauen. Kein Bug. Nur Physik.

Lange Sessions fühlen sich generell schnell an. Der Gesprächsverlauf wächst weiter, trifft aber meist den Cache. Turn 30 verwendet das gecachte Präfix von Turns 1–29 wieder und verarbeitet nur das neue Zeug. Deshalb hat das Claude Code Team ihre gesamte Architektur darum gebaut — ohne Caching würde deine 50. Nachricht 50x mehr Token verarbeiten als deine erste. Das Produkt wäre bei Nachricht 15 tot. Wie ein Slack-Thread, der jede vorherige Nachricht von Grund auf lädt, jedes Mal wenn jemand "klingt gut" tippt — aber ich schweife ab.

Und manchmal wird es zufällig langsam. Wenn das Team eine Änderung shipped, die versehentlich die Prompt-Assembly-Reihenfolge modifiziert, oder wenn ein internes Update eine Tool-Definition verschiebt, bricht jeder Users Cache gleichzeitig. Das ist der SEV. Das ist der Pager, der losgeht. "Cache Rules Everything Around Me" ist kein süßes Motto. Es ist ein Operations-Manual.

Was das tatsächlich für dich bedeutet

Falls du auf der Claude API baust: geh jetzt sofort deine System-Prompts checken. Falls da etwas Dynamisches drin ist — ein Datum, eine User-ID, ein Random Seed, irgendetwas, das sich zwischen Anfragen ändert — verschiebe es in die User-Nachricht. Füge cache_control-Breakpoints hinzu. Sortiere deine Tools. Mach es heute. Der ROI ist sofort und peinlich. Ich habe das auf die harte Tour gelernt, als Anthropic mein $200/Monat OpenClaw Setup getötet hat — sobald du auf API statt Abo rebuilds, zählt jeder Dollar Optimierung.

Falls du Claude Code mit einem Abo nutzt: du musst nichts tun. Aber jetzt verstehst du, warum das Team Prompt Caching wie die Sauerstoffversorgung auf einer Raumstation behandelt. Und das nächste Mal, wenn deine erste Nachricht 6 Sekunden dauert und deine zehnte Nachricht 1,5 Sekunden, weißt du genau, was passiert ist.

So oder so, CREAM. Cache regiert alles um dich herum, ob du es weißt oder nicht. Die einzige Frage ist, ob du auf der günstigen oder der teuren Seite stehst.

Die Entwickler, die ihre Infra verstehen, shippen günstiger. Die, die es nicht tun, subventionieren die Rate Limits aller anderen.

---

Als Nächstes: Anthropic hat gerade Third-Party-Harnesses getötet, die Claude-Abos verwenden. Mein $200/Monat OpenClaw Setup starb über Nacht. Ich habe das Ganze für $15 rebuilt — und Prompt Caching ist die Hälfte des Grundes, warum es funktioniert.

---

Wie das Claude Code Team Prompt Caching als kritische Infrastruktur behandelt und welche Kosten-Fallen du vermeiden kannst.

→ Sichere dir das Produktions-Toolkit