Cache-Trefferquote von OpenCode mit Claude-Modellen

Das Wichtigste in Kürze

• Normalwert: 97.6%, Median von 20 Nutzern in laufenden Unterhaltungen; mittlere Hälfte 97.1%–98.9%
• Alle Anfragen: 95.1%, einschließlich Routing, Cache-Ablauf und neuer Chats
• Größte Ursache für Cache-Misses: neue Unterhaltungen, 34% der Cache-Misses
• Zwischen den Varianten: 0.6 Punkte Unterschied, Desktop-App, CLI (Terminal)

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

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

• Trefferquote in laufenden Unterhaltungen (Median der Nutzer): 97.6%
• Mittlere Hälfte der Nutzer: 97.1%–98.9%
• Qualifizierte Nutzer: 20 (mindestens 20 Folge-Turns in der Woche)
• Trefferquote über alle Anfragen: 95.1%

Trefferquote von OpenCode nach Variante

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

• Desktop-App: 98.0% (7)
• CLI (Terminal): 97.4% (6)

Trefferquote von OpenCode 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.2.5: 97.5% (10)

Median pro Woche

• 2026-09-29: 96.5% (7 Nutzer)
• 2026-10-06: 97.6% (8 Nutzer)
• 2026-10-13: 98.8% (11 Nutzer)
• 2026-10-20: 97.4% (10 Nutzer)
• 2026-10-27: 96.4% (13 Nutzer)
• 2026-11-03: 97.6% (20 Nutzer)

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

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

Neue Unterhaltung oder mehr als eine Stunde Pause: 34% der Cache-Misses, etwa 1.7% der gesamten Eingabe

Die erste Anfrage einer neuen Unterhaltung oder eine Anfrage nach einer Stunde Pause muss den Cache neu schreiben.

Neue Inhalte und Präfixänderungen in einer laufenden Unterhaltung: 31% der Cache-Misses, etwa 1.5% der gesamten Eingabe

Inhalte, die in einem Turn neu sind, können nur geschrieben, nicht gelesen werden – das lässt sich nicht vermeiden; auch ein geänderter System-Prompt, eine geänderte Tool-Liste oder ein umgeschriebener Verlauf machen das Präfix ungültig.

Mehr als 5 Minuten Pause, Cache abgelaufen: 31% der Cache-Misses, etwa 1.5% der gesamten Eingabe

Zwischen den Anfragen lagen mehr als 5 Minuten, der vorherige Cache-Eintrag ist also möglicherweise abgelaufen.

An ein anderes Upstream-Konto oder einen anderen Endpunkt geroutet: 3% der Cache-Misses, etwa 0.2% 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.

Parallele Anfrage (die vorherige läuft noch): 0% der Cache-Misses, etwa 0.0% der gesamten Eingabe

Eine Anfrage, die gesendet wird, bevor die vorherige fertig ist (Subagenten, parallele Tool-Aufrufe), kann den Cache nicht lesen, den die vorherige noch schreibt.

Modell gewechselt: 0% der Cache-Misses, etwa 0.0% der gesamten Eingabe

Jedes Modell hat seinen eigenen Cache, deshalb liest die erste Anfrage nach einem Modellwechsel den gesamten Verlauf neu ein.

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: 97.6%: $0.32 (×1.0)
• 90%: $0.68 (×2.1)
• 80%: $1.16 (×3.7)
• 50%: $2.60 (×8.2)

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

So prüfst du deine Cache-Trefferquote in OpenCode

• Anthropic-Format: cache_read_input_tokens ÷ (input_tokens + cache_read_input_tokens + cache_creation_input_tokens).
• OpenAI-Format: cached_tokens (in prompt_tokens_details oder input_tokens_details) ÷ prompt_tokens / input_tokens.
• Auf Wokey zeigt das Anfrageprotokoll der Konsole für jede Anfrage Cache-Lesen und Cache-Schreiben an.

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