Cache-Trefferquote von Codex

Das Wichtigste in Kürze

• Normalwert: 94.8%, Median von 71 Nutzern in laufenden Unterhaltungen; mittlere Hälfte 91.2%–96.9%
• Alle Anfragen: 91.8%, einschließlich Routing, Cache-Ablauf und neuer Chats
• Größte Ursache für Cache-Misses: neue Inhalte in laufenden Turns, 57% der Cache-Misses
• Zwischen den Varianten: 4.6 Punkte Unterschied, Desktop-App, Terminal-Oberfläche, codex exec (nicht interaktiv)

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

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

• Trefferquote in laufenden Unterhaltungen (Median der Nutzer): 94.8%
• Mittlere Hälfte der Nutzer: 91.2%–96.9%
• Qualifizierte Nutzer: 71 (mindestens 20 Folge-Turns in der Woche)
• Trefferquote über alle Anfragen: 91.8%

Trefferquote von Codex nach Variante

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

• Desktop-App: 95.3% (55)
• Terminal-Oberfläche: 95.8% (11)
• codex exec (nicht interaktiv): 91.2% (9)

Trefferquote von Codex 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.

• 0.167.0-alpha.3.2: 95.0% (27)
• 0.167.0: 93.3% (6)
• 0.166.0-alpha.6: 95.6% (29)
• 0.166.0-alpha.5.1: 96.4% (28)
• 0.166.0: 96.6% (5)

Median pro Woche

• 2026-09-29: 96.0% (38 Nutzer)
• 2026-10-06: 95.3% (54 Nutzer)
• 2026-10-13: 95.4% (62 Nutzer)
• 2026-10-20: 95.8% (49 Nutzer)
• 2026-10-27: 95.1% (72 Nutzer)
• 2026-11-03: 94.8% (71 Nutzer)

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

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

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

Der Cache von OpenAI verlangt, dass das gesamte Präfix übereinstimmt. Wenn du mitten in der Session Reasoning Effort, Tools oder Ausgabeformat änderst oder Codex den Verlauf komprimiert (Compaction), ändert sich das Präfix. Das ist die größte Quelle für Cache-Misses bei Codex.

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

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

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

Modell gewechselt: 3% der Cache-Misses, etwa 0.3% der gesamten Eingabe

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

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

Bei GPT-5.6 und neuer hält der Cache standardmäßig 30 Minuten, gerechnet ab dem letzten Schreiben oder Wiederverwenden; ältere Modelle verwerfen ihn meist nach 5–10 Minuten ohne Aktivität.

Parallele Anfrage (die vorherige läuft noch): 2% der Cache-Misses, etwa 0.2% 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.

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

• OpenAI cacht Prompt-Präfixe automatisch, ohne Breakpoints im Client; GPT-5.6 und neuer cachen Prompts ab 1.024 Token.
• GPT-5.6 und neuer behalten den Cache standardmäßig 30 Minuten, gerechnet ab dem letzten Schreiben oder Wiederverwenden. Ältere Modelle halten Einträge im Arbeitsspeicher etwa 5–10 Minuten ohne Aktivität, höchstens eine Stunde; einige unterstützen eine Aufbewahrung von 24 Stunden.
• Gecachte Eingabe wird meist zum 0,1-Fachen des Eingabepreises abgerechnet, bei GPT-6.1 Sol zum 0,05-Fachen; GPT-5.6 und neuer berechnen für Cache-Schreiben das 1,25-Fache.
• Codex sendet die Session-ID als prompt_cache_key (laut Quellcode), die Anfragen einer Session landen also beim selben Cache.

Prompt-Caching bei OpenAI · OpenAI: Diagnose von Cache-Misses · Codex-Quellcode (prompt_cache_key) · Codex-Issue #35416: Cache-Misses beim Wechsel des Reasoning Effort

So prüfst du deine Cache-Trefferquote in Codex

• Beim Beenden gibt die Codex CLI die Token-Nutzung der Session aus; der Teil „+ N cached“ ist Eingabe, die aus dem Cache gelesen wurde (aktuelles Verhalten, nicht dokumentiert).
• Aus der API: usage.input_tokens_details.cached_tokens ÷ usage.input_tokens; GPT-5.6 und neuer melden zusätzlich Cache-Schreiben.
• Die OpenTelemetry-Metrik turn.token_usage enthält den Typ cached_input.
• Auf Wokey zeigt das Anfrageprotokoll der Konsole für jede Anfrage Cache-Lesen und Cache-Schreiben an.

OpenAI: Diagnose von Cache-Misses

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