Cache-Trefferquote von Claude Code

In der Woche ab 2026-11-03 lag die Cache-Trefferquote von Claude Code mit Claude-Modellen in laufenden Unterhaltungen im Median bei 98.1% (343 Nutzer), über alle Anfragen bei 94.6%. Die meisten Cache-Misses entstanden durch: Cache-Ablauf (37%), neue Inhalte in laufenden Turns (23%), neue Unterhaltungen (17%).

Woche 2026-11-03 – 2026-11-09 (UTC)

Das Wichtigste in Kürze

  • Normalwert: 98.1%, Median von 343 Nutzern in laufenden Unterhaltungen; mittlere Hälfte 96.9%–98.8%
  • Alle Anfragen: 94.6%, einschließlich Routing, Cache-Ablauf und neuer Chats
  • Größte Ursache für Cache-Misses: Cache-Ablauf, 37% der Cache-Misses
  • Zwischen den Varianten: 1.7 Punkte Unterschied, CLI (Terminal), Desktop-App, Lokaler Desktop-Agent

Welche Cache-Trefferquote ist für welchen Client normal?

Woche 2026-11-03 – 2026-11-09 (UTC)

  • Trefferquote in laufenden Unterhaltungen (Median der Nutzer): 98.1%
  • Mittlere Hälfte der Nutzer: 96.9%–98.8%
  • Qualifizierte Nutzer: 343 (mindestens 20 Folge-Turns in der Woche)
  • Trefferquote über alle Anfragen: 94.6%

Trefferquote von Claude Code nach Variante

CLI, IDE-Erweiterung und Desktop-App eines Clients senden nahezu identische Anfragen, ihre Trefferquoten sollten also nah beieinanderliegen.

  • CLI (Terminal): 98.2% (147)
  • Desktop-App: 98.4% (114)
  • Lokaler Desktop-Agent: 98.0% (78)
  • VS-Code-Erweiterung: 97.8% (50)
  • Agent SDK (CLI): 96.7% (43)
  • Agent SDK (TypeScript): 97.8% (16)
  • t3-code: 97.9% (5)

Trefferquote von Claude Code nach Version

Ein Release, das das Präfix der Anfrage ändert, zeigt schon in der Woche seiner Veröffentlichung eine deutlich niedrigere Trefferquote als die anderen Versionen.

  • 2.1.321: 97.6% (5)
  • 2.1.319: 98.4% (77)
  • 2.1.318: 98.3% (92)
  • 2.1.317: 97.9% (133)
  • 2.1.316: 98.4% (44)
  • 2.1.314: 98.5% (25)
  • 2.1.312: 98.0% (20)
  • 2.1.311: 98.4% (13)
  • 2.1.310: 97.4% (14)
  • 2.1.309: 98.3% (98)
  • 2.1.308: 98.0% (30)
  • 2.1.302: 96.4% (7)
  • 2.1.299: 97.6% (6)
  • 2.1.296: 98.0% (8)
  • 2.1.295: 97.6% (14)
  • 2.1.292: 99.0% (5)
  • 2.1.284: 97.0% (6)
  • 2.1.280: 98.2% (11)

Median pro Woche

  • 2026-09-29: 96.8% (120 Nutzer)
  • 2026-10-06: 97.8% (220 Nutzer)
  • 2026-10-13: 98.0% (256 Nutzer)
  • 2026-10-20: 98.0% (250 Nutzer)
  • 2026-10-27: 98.0% (259 Nutzer)
  • 2026-11-03: 98.1% (343 Nutzer)

Warum ist meine Cache-Trefferquote in Claude Code niedrig? Cache-Misses nach Ursache

5.4% der Eingabe dieser Woche wurden nicht aus dem Cache gelesen. Hier nach Ursache aufgeschlüsselt – jeweils mit dem, was du dagegen tun kannst.

Mehr als 5 Minuten Pause, Cache abgelaufen: 37% der Cache-Misses, etwa 2.0% der gesamten Eingabe
Der Cache hält standardmäßig 5 Minuten, und jeder Treffer verlängert ihn kostenlos. Wenn du oft länger pausierst, setze CLAUDE_CODE_PROMPT_CACHE_TTL=1h (ab v2.1.242); Cache-Schreiben kostet dann das 2-Fache statt das 1,25-Fache des Eingabepreises.
Neue Inhalte und Präfixänderungen in einer laufenden Unterhaltung: 23% der Cache-Misses, etwa 1.2% der gesamten Eingabe
Inhalte, die in einem Turn neu sind, können nur geschrieben, nicht gelesen werden. Das Verbinden oder Entfernen von MCP-Servern und das Aktivieren von Plugins, die MCP-Server mitbringen, ändert die Tool-Definitionen und macht den Cache ungültig.
Neue Unterhaltung oder mehr als eine Stunde Pause: 17% der Cache-Misses, etwa 0.9% der gesamten Eingabe
Die erste Anfrage einer neuen Unterhaltung oder eine Anfrage nach einer Stunde Pause muss den Cache neu schreiben.
Modell gewechselt: 12% der Cache-Misses, etwa 0.6% der gesamten Eingabe
Jedes Modell hat seinen eigenen Cache. Nach /model liest die nächste Anfrage den gesamten Verlauf ohne Cache-Treffer ein, obwohl der Inhalt identisch ist.
Parallele Anfrage (die vorherige läuft noch): 10% der Cache-Misses, etwa 0.5% der gesamten Eingabe
Subagenten und parallele Tool-Aufrufe senden die nächste Anfrage, bevor die vorherige beendet ist. Ein Fork in Claude Code liest den Cache der übergeordneten Session; ein normaler Subagent hat einen eigenen System-Prompt und eigene Tools und baut seinen eigenen Cache auf.
An ein anderes Upstream-Konto oder einen anderen Endpunkt geroutet: 2% der Cache-Misses, etwa 0.1% der gesamten Eingabe
Ein Prompt-Cache liegt bei dem Upstream-Konto, das die Anfrage verarbeitet hat. Schickt ein Relay oder ein Gateway mit mehreren Konten den nächsten Turn an ein anderes Konto, wird der gesamte Kontext neu geschrieben. Bei einer direkten Verbindung zum Anbieter tritt diese Ursache nie auf.

Ein paar Punkte Trefferquote, ein Mehrfaches auf der Rechnung

Zu den offiziellen Preisen von Claude Opus 5.5, wenn Cache-Misses in den 5-Minuten-Cache geschrieben werden – die effektiven Kosten pro 1 Mio. Eingabe-Token:

  • Median dieser Woche: 98.1%: $0.29 (×1.0)
  • 90%: $0.68 (×2.3)
  • 80%: $1.16 (×4.0)
  • 50%: $2.60 (×9.0)

Rechne deinen eigenen Fall im Kostenrechner für die Claude API durch

Cache-TTL von Claude Code: wie lange der Cache hält und was er kostet

  • Er hält standardmäßig 5 Minuten, und jeder Treffer verlängert ihn kostenlos.
  • Auf 1 Stunde umstellen: CLAUDE_CODE_PROMPT_CACHE_TTL=1h (ab v2.1.242; für Subagenten CLAUDE_CODE_SUBAGENT_PROMPT_CACHE_TTL), in älteren Versionen ENABLE_PROMPT_CACHING_1H=1.
  • Cache-Schreiben kostet das 1,25-Fache des Eingabepreises (5 Minuten) oder das 2-Fache (1 Stunde); Cache-Lesen meist das 0,1-Fache, bei Opus 5.5 und Sonnet 5.5 das 0,05-Fache.
  • Prompts unterhalb der Mindestlänge werden ohne Fehlermeldung nicht gecacht: je nach Modell 512 bis 4.096 Token.

Prompt-Caching bei Anthropic · Prompt-Caching in Claude Code · Umgebungsvariablen von Claude Code

So prüfst du deine Cache-Trefferquote in Claude Code

  • Führe in Claude Code /usage aus: Die Zeile Prompt cache (main) im Block Session zeigt die Zahl der Anfragen, den Anteil der Eingabe aus dem Cache, die Cache-Misses und ob der Cache noch warm ist.
  • Statuszeilen-Skripte können die Felder prompt_cache lesen; der OpenTelemetry-Exporter meldet Token für Cache-Lesen und Cache-Erstellung pro Nutzer und Session.
  • Aus der API: cache_read_input_tokens ÷ (input_tokens + cache_read_input_tokens + cache_creation_input_tokens).
  • Auf Wokey zeigt das Anfrageprotokoll der Konsole für jede Anfrage Cache-Lesen und Cache-Schreiben an.

Kosten und Nutzung von Claude Code

Warum die Trefferquote hinter Relays sinkt

  • Kontowechsel: Der Cache gehört zum Upstream-Konto, ein Turn, der an ein anderes Konto geht, schreibt also alles neu. Die häufigste Ursache bei Relays; bei direkter Verbindung gibt es sie nicht.
  • Formatumwandlung: Beim Übersetzen zwischen Anthropic- und OpenAI-Format kann sich das Präfix ändern, oder cache_control-Breakpoints gehen verloren.
  • Claude Code vor v2.1.181 setzte bei eigener Base URL ein pro Anfrage wechselndes Token in den Attributionsblock am Anfang des System-Prompts. Das hebelt Gateways aus, die anhand des Anfrageinhalts cachen; aktualisiere, oder setze CLAUDE_CODE_ATTRIBUTION_HEADER=0.
  • Selbsttest: Sende zwei Anfragen mit demselben Präfix oberhalb der minimalen Cache-Länge; bei der zweiten sollte das Cache-Lesen nah an der Länge des Präfixes liegen.

Wokey routet die späteren Anfragen einer Unterhaltung wann immer möglich an dasselbe Upstream-Konto. Vom 2026-10-04 bis 2026-10-10 erreichten normale Wokey-Nutzer mit Claude Opus 5.5 über alle Anfragen 92.8% Trefferquote, OpenRouter insgesamt 87.8%.

Mit den Cache-Trefferquoten von OpenRouter vergleichen · Live: öffentliche API der Cache-Trefferquote von Wokey (letzte 7 Tage)

So messen wir

  • Echte Nutzeranfragen über das Wokey-Gateway; jeden Montag um 05:00 UTC berechnen wir die Vorwoche (Montag bis Sonntag).
  • Clients werden am User-Agent der Anfrage erkannt. Anfragen von SDKs, HTTP-Bibliotheken und nachgelagerten Relays, bei denen der echte Client unbekannt ist, bleiben außen vor, ebenso Enterprise-Konten.
  • Ein Folge-Turn hat dasselbe Modell und dasselbe Upstream-Konto wie die vorherige Anfrage seiner Unterhaltung und beginnt innerhalb von 5 Minuten nach deren Ende. Die Quote eines Nutzers ist Cache-Lesen ÷ Eingabe über diese Turns (die Eingabe enthält Cache-Lesen und Cache-Schreiben); wir veröffentlichen den Median über Nutzer mit mindestens 20 solchen Turns in der Woche.
  • Eine Zelle wird ab 5 qualifizierten Nutzern veröffentlicht; eine Änderung von mehr als 3 Punkten gegenüber der Vorwoche wird zuerst von Hand geprüft.
  • Bekannte Verzerrungen: nur Wokey-Nutzer; die Nutzungsgewohnheiten unterscheiden sich stark; die Quote über alle Anfragen enthält den Routing-Verlust des Gateways selbst (die Ursache „an ein anderes Upstream-Konto geroutet“).

Häufige Fragen

Was ist eine normale Cache-Trefferquote in Claude Code?

Diese Woche lag der Median von 343 Nutzern in laufenden Unterhaltungen bei 98.1%, die mittlere Hälfte zwischen 96.9% und 98.8%; über alle Anfragen waren es 94.6%.

Warum ist meine Cache-Trefferquote in Claude Code niedrig?

Diese Woche entstanden die meisten Cache-Misses durch: Cache-Ablauf (37%), neue Inhalte in laufenden Turns (23%), neue Unterhaltungen (17%). Die Seite nennt für jede Ursache, was du tun kannst.

Verbraucht eine niedrige Cache-Trefferquote mein Claude-Limit schneller?

Ja. In unseren Messungen der Claude-Nutzungslimits verbraucht Cache-Lesen fast nichts vom Limit, während Cache-Schreiben etwa wie nicht gecachte Eingabe zählt. Ein gecachter Kontext kostet so gut wie nichts; bei einem Cache-Miss zählt er wieder voll. Die Limits pro Tarif stehen auf der Seite zu den Claude-Nutzungslimits (/claude-usage-limits).

Was sind Cache Read Tokens in Claude Code?

Der Teil der Eingabe, der aus dem Cache kommt; die API meldet ihn als cache_read_input_tokens. In langen Sessions sind das meist über 90 % der Eingabe, abgerechnet zum 0,1-Fachen des Eingabepreises (0,05-Fach bei Opus 5.5 und Sonnet 5.5); cache_creation_input_tokens ist das, was diese Anfrage neu in den Cache geschrieben hat.

Lohnt sich der 1-Stunden-Cache?

Meist nicht. Spielt man einen Tag echten Claude-Traffic auf Wokey nach, erhöht die Umstellung auf den 1-Stunden-Cache die Gesamtausgaben netto um etwa 15–25 %: Cache-Schreiben steigt vom 1,25-Fachen auf das 2-Fache des Eingabepreises, und das kostet mehr, als die selteneren Abläufe einsparen. Lohnen kann es sich nur bei langem Kontext und häufigen Pausen von 5–60 Minuten.

Wie lange hält der Cache von Claude Code?

Standardmäßig fünf Minuten, bei jedem Treffer kostenlos verlängert. Mit CLAUDE_CODE_PROMPT_CACHE_TTL=1h (ab v2.1.242) wird daraus eine Stunde; Cache-Schreiben kostet dann das 2-Fache statt das 1,25-Fache des Eingabepreises.

Machen Modellwechsel oder Subagenten den Cache ungültig?

Ja. Jedes Modell hat seinen eigenen Cache, die Anfrage nach /model liest also alles neu ein; ein normaler Subagent hat einen eigenen System-Prompt und eigene Tools und baut seinen eigenen Cache auf, während ein Fork den der übergeordneten Session wiederverwendet.

Warum ist Cache Creation so teuer?

Cache-Schreiben kostet das 1,25-Fache (5 Minuten) oder das 2-Fache (1 Stunde) des Eingabepreises. Die erste Anfrage einer langen Unterhaltung und jede Anfrage nach einem Kontowechsel oder Cache-Ablauf schreibt den gesamten Kontext einmal und kostet deutlich mehr als ein normaler Turn.

Funktioniert Caching, wenn Claude Code über ein Relay läuft?

Ja, sofern das Relay cache_control durchreicht und eine Unterhaltung auf einem Upstream-Konto hält. Versionen vor v2.1.181 brauchen bei eigener Base URL ein Update oder CLAUDE_CODE_ATTRIBUTION_HEADER=0.