Fehler beim Prompt-Caching können Ihrer Organisation fast 6x mehr pro AI-Runde kosten

Ich habe seitdem verstanden, warum das so ist. Eine Person kann am nächsten Tag zu einer Konversation zurückkehren, und die Zeit, die der Konversation zu Beginn gegeben wurde, ist veraltet. Etwas muss sie erneut liefern. Ein Harnisch, das Programm um ein Modell herum, das jede Anfrage zusammenstellt und die Schleife ausführt, kann das tun, indem es die aktuelle Zeit in die Anweisungen des Modells vor jeder Anfrage schreibt. Der Agent-Runner, den wir in der Produktion verwenden, tat genau das.

Ich kenne Prompt-Caching schon lange. Anbieter speichern den Beginn einer Anfrage und berechnen sie zu einem Bruchteil des Preises, wenn die nächste Anfrage auf die gleiche Weise beginnt. Ich wusste nicht genug über seine Mechanik, um zu sehen, was eine Zeile wie die Zeit damit bewirkt. Wir stießen auf die Antwort in unseren eigenen Produktionskosten, und ich leitete eine Reihe von Experimenten ein, um sie richtig zu messen, über ein aktuelles Modell von jedem der 4 Labs und im Vergleich zu den öffentlichen Zahlen von OpenRouter für das, was alle anderen zahlen.

Die Antwort ist teuer. Bei GPT-6 Luna machte die falsche Platzierung der Zeit jede Runde einer Konversation 5.7× so teuer, wie sie sein musste, und es gab keinen Fehler. Durch die Verkehrsorganisationen werden diese Modelle gesendet, die Eingabe ist 96–99% der Tokens und 66–87% der tatsächlich gezahlten Dollar, sodass der Cache den größten Teil der Rechnung entscheidet. Für eine Organisation, die ihr eigenes Harness baut, eine interne AI-Plattform betreibt oder AI-Produkte versendet, multipliziert ein Fehler wie dieser die Kosten jedes Turns, stillschweigend, solange er läuft.

Jede pro Turn-Nummer hier wurde am 23. September 2026 gemessen, durch OpenRouter. Die Marktwerte sind OpenRouter's eigene, am selben Tag gelesen.

Jeder Aufruf eines Modells sendet die gesamte Konversation erneut: die Tool-Definitionen, den System-Prompt (die feststehenden Anweisungen, die der Harness schreibt), jede frühere Runde und die neue Nachricht.

Anbieter behalten den verarbeiteten Anfang kürzlicher Anfragen bei. Wenn die nächste Anfrage mit demselben Text beginnt, liest der Anbieter diesen gespeicherten Präfix statt ihn erneut zu verarbeiten. Auf GPT-6 Luna wurde OpenRouter ein Lesevorgang mit 0.10× des aufgeführten Eingabepreises und die erste Schreiboperation mit 1.25× berechnet. Ein Prompt, der bei jeder Runde erneut geschrieben wird, kostet daher mehr als ein Prompt ohne Cache.

Nur der Anfang einer Anfrage kann wiederverwendet werden. Eine Änderung an irgendeinem Punkt löscht alles danach:

graph LR
    A[Tool-Definitionen] --> B[Systemaufforderung]
    B --> C[Frühere Runden]
    C --> D[Neue Benutzernachricht]
    B -. a changed line here voids B, C and D .-> D

Alles, was ein Harness nahe dem Anfang schreibt und bei jeder Runde ändert, setzt die gesamte Konversation hinter sich zurück. Die aktuelle Zeit ist das einfachste Beispiel.

Die Entdeckung begann in einem Agenten, den wir in der Produktion betreiben. Sein Kostenbuch hat jeden Aufruf zum Listenpreis bewertet und zeigte überhaupt keine Caching. Ich habe die Alarmglocke ausgelöst und begonnen, einen Wechsel zu einem anderen Modell abzuwägen.

Der Agent, mit dem ich arbeitete, stellte zuerst fest, dass das Buch selbst falsch war. Über 33 Aufrufe schätzte er $0.064; der Anbieter hatte $0.023 berechnet, 2.7× weniger. Die Preisgestaltung jedes Aufrufs anhand der Tokenanzahl hat jeden Rabatt des Anbieters entfernt. Das Lesen der vom Anbieter gemeldeten Kosten zeigte stattdessen, dass das Caching innerhalb jeder Runde funktionierte und am Anfang jeder neuen Runde scheiterte.

Seine erste Erklärung war ein fehlender Sitzungskey, der Anfragen auf demselben Server halten würde. Seine eigene Untersuchung widerlegte das: identische Aufforderungen wurden bereits aus dem Cache über Runden auf GPT-6 Luna gelesen, und das Hinzufügen eines Sitzungskeys, eines Cache-Keys oder eines expliziten Cache-Markers änderte nichts. Die Ursache lag im Systemprompt selbst. Etwa 95% des Weges hinein schrieb der Runner zwei Zeilen, die sich jede Runde änderten: ein pro Runde Arbeitsverzeichnis und eine Uhr bis zur Minute. Jeder erste Aufruf einer Runde schrieb die ganze Aufforderung erneut bei 1.25×.

Das Verschieben beider Zeilen ans Ende der Benutzernachricht hat es in der Produktion behoben. Runden 2 und 3 öffnen jetzt bei 0.47–0.51× statt bei 1.25×. Der Rest ist ein Block pro Runde Kontext, den der Runner immer noch in der Benutzernachricht sendet.

Meine Vermutung, bevor all dies gemessen wurde, war, dass ein deterministischer Check die Zeit nur dann liefern könnte, wenn sie veraltet war, als separate Nachricht, und den Rest des Prompts im Cache lassen. Es gilt, mit einer Bedingung, und diese Bedingung ist die Regel, auf die der Rest des Artikels zurückgreift.

Um es direkt zu testen, bauten wir einen Probe, der das gleiche Gespräch mit der Uhr an verschiedenen Stellen ausführt, 65 Sekunden auseinander, sodass die Minute zwischen jedem Paar wechselt. GPT-6 Luna, ein 8.5K-Token-Systemprompt, 3 repliziert:

Meine separate Nachricht behielt den Cache in beiden Formen, jeden Zug und nur wenn veraltet. Die Bedingung ist, wo sich die Nachricht befindet. Nach den stabilen Anweisungen liest der Anbieter alles davor. Als zweite Systemnachricht befindet sie sich unter den Anweisungen, und GPT-6 Luna schrieb die ganze Eingabe erneut auf 12 von 12 Zügen.

Die folgende Regel ist kurz. Alles, was sich zwischen den Zügen ändert, kommt nach allem, was nicht ändert.

Der Cache vergleicht Text, daher ist eine Uhr harmlos, solange ihr Text gleich bleibt. In derselben Probe mit Wechseln 4 Sekunden auseinander, liest eine Minutenuhr im Systemprompt bei jedem Aufruf aus dem Cache. Mit Wechseln 65 Sekunden auseinander zwang sie bei jedem Wechsel eine vollständige Neuschreibung.

Die Auflösung bestimmt, wie oft das geschieht. Eine Stundenuhr und eine Datumszeile im Systemprompt lesen bei allen 12 Öffnungen der 65-sekündlichen Läufe aus dem Cache, weil keine von beiden überlaufen ist. Sie brechen ebenfalls, einmal pro Stunde und einmal pro Tag. Eine Minutenuhr bricht bei jedem Wechsel, der in einer späteren Minute beginnt als der vorherige.

Der Cache selbst läuft ebenfalls ab. In einzelnen zeitlich begrenzten Läufen las GPT-6 Luna immer noch ihr gespeichertes Präfix nach 30 Minuten Inaktivität und schrieb die gesamte Eingabe erneut bei 1.25× nach 60. DeepSeek V4.1 Flash las nach 10 Minuten und verpasste nach 60. Claude Opus 5.5 hatte bereits nach 10 verpasst, da der Standardcache von Anthropic 5 Minuten hält und sein 1-Stunden-Cache 2× kostet zu schreiben. Die Person, die am nächsten Tag zu einem Gespräch zurückkehrt, der Fall, mit dem dieser Artikel begann, findet sowohl eine veraltete Zeit als auch einen kalten Cache bei allen drei. Dieser erste Rückwechsel zahlt für die gesamte Eingabe, egal was der Rahmen tut. Platzierung entscheidet, ob die nachfolgenden Drehungen ebenfalls so sind.

GPT-6 Luna ist die Antwort eines Anbieters. Um zu sehen, wie allgemein die Lektion ist, führten wir die gleichen Platzierungen bei einem aktuellen Modell von jedem der 4 Labs durch, mit einem identischen 2.5K-Token-Prompt, jeweils fest an einen einzelnen Anbieter geknüpft:

GPT-6 Luna speichert ganze Nachrichten. Eine geänderte Zeile löscht die Nachricht, die sie enthält, und alles danach.

Claude Opus 5.5 speichert dort, wo der Aufrufer es markiert. Die Modelle von Anthropic speichern nur bis zu einem cache_control-Marker, den das Harness setzt. Ohne Marker wurde derselbe Prompt bei jedem Aufruf zum vollen Preis berechnet. Mit dem Marker im Systemprompt kostete eine Uhr innerhalb dieses Blocks 1.24×, während eine Uhr in einer zweiten Systemnachricht danach bei 0.08× gelesen wurde. Die Platzierung, die GPT-6 Luna bestraft, ist bei Opus sicher. Bei Opus-Preisen betrug der Unterschied pro Zugöffnung $0.0214 gegen $0.0023. Opus zählte den identischen Prompt ebenfalls als 4,056 Tokens, während GPT-6 Luna 2,395 zählte, sodass derselbe Text vor Anwendung eines Preises 1.69× mehr Tokens kostet.

DeepSeek V4.1 Flash speichert in 256-Token-Blöcken und berechnet nichts extra zum Schreiben. Lesevorgänge kamen in genauen Vielfachen von 256 zurück: 2.560 Tokens für den unveränderten Prompt, 2.304 mit der Uhr am Ende des Systemprompts. Eine geänderte Zeile kostet nur den Block, der sie enthält. Erste Aufrufe wurden zum reinen Eingabepreis berechnet, und Lesevorgänge bei 0.03–0.04×. Über 8 Läufe pro Platzierung verfehlten 2 einzelne Aufrufe den Cache bei einem Zug, den derselbe Lauf dann las, was als Anforderung auf einen anderen Server interpretiert wird, statt als Effekt der Platzierung. Der eigene Endpunkt von DeepSeek ist der einzige, der OpenRouter automatisch als Cache markiert, und die Datenschutzeinstellung meines Kontos schließt ihn aus, weil dieser Endpunkt auf bezahlten Traffic trainiert. Die Läufe gingen durch DeepInfra, der gecacht hat, ebenso wie Fireworks und Morph in einer 2‑Aufruf‑Prüfung.

Muse Spark 1.3 liest seinen Cache innerhalb einer Tool‑Schleife und verfehlte den Start jedes neuen Zugs. Unsere ersten Tests, die eine frische Frage gegen denselben Systemprompt stellten, lieferten höchstens 113 Tokens aus dem Cache in 10 Aufrufen, bei 2.9K, 8.9K und 19.4K Tokens. Wenn ein Folgeanruf die vorherige Anfrage verlängert, wie es ein Agenten-Tool-Loop tut, las Muse 2,801 von 2,966 Tokens und berechnete 0.17×. Der nächste Benutzerzugriff, mit der gesamten Historie vor sich, las nichts. OpenRouter meldet eine 86.1% Cache-Hit-Rate für Muse im Live-Traffic, die zu einer Arbeitslast passt, die von Tool-Loops dominiert wird. Zu Beginn eines Zugriffs macht die Uhr bei Muse keinen Unterschied, da dieser Aufruf ohnehin misslingt.

Die gleiche Harness-Entscheidung kostet bei jedem Modell einen anderen Betrag. Zu wissen, welches Mechanismus Ihr Anbieter verwendet, kommt vor der Feinabstimmung von irgendetwas.

Wir erwarteten, dass gecachte Runden schneller antworten. Bei 10 aufeinanderfolgenden Paaren von GPT-6 Luna-Aufrufen bei 8.5K Tokens, dauerte der Median des ersten Aufrufs 437 ms vom Cache und 490 ms ohne ihn. Diese Lücke liegt innerhalb der Streuung der Stichproben. In dieser Größe ändert das Caching, was ein Turn kostet, und lässt die Dauer ungefähr gleich bleiben.

Also die Pause, die ich mich erinnere, wenn ich nach der Zeit frage, hat einen anderen Grund. Was ein Uhrwerk an der falschen Stelle kostet, ist Geld.

Eine Uhr im Systemprompt steht vor dem gesamten Gespräch, sodass jede Umschreibung die wachsende Historie dahinter sowie die Anweisungen abdeckt. Hier ist die gemessene Kosten eines 12-Runden GPT-6 Luna Gesprächs, mit der vollständigen vom Anbieter gemeldeten Rechnung, einschließlich Ausgabe und der Aufrufe innerhalb jeder Runde:

Die beiden Zeilen teilen sich ihre erste Runde, wenn beide den Cache schreiben. Von da an kostet jede Runde mit der Uhr im Systemprompt 5.7× so viel, wie die gleiche Runde mit der Uhr am Ende der Benutzernachricht kostet. Bis zur Runde 12 hatte das Gespräch Kosten von 4.1× so viel, und die Lücke vergrößert sich mit jeder Runde.

Bruchteile eines Cents werden bei Skalierung zu einem Posten. Diese Projektion bewertet den ersten Aufruf jeder Runde für ein Produkt, das 10,000 Gespräche pro Tag bedient, jedes mit einem 8.5K-Token Systemprompt, 20 Runden, und eine Historie, die 1,500 Tokens pro Runde wächst. Jedes Modell verwendet seinen aufgeführten Preis und das Cache-Verhalten, das oben gezeigt wurde:

DeepSeek's blocks behalten die Systemaufforderung, wenn die Uhr sich ändert, und das Modell kommt immer noch 13× teurer heraus, weil die Geschichte hinter der Uhr die Anweisungen in wenigen Runden übersteigt. Muse Spark zeigt die andere Seite: es verpasste zu Beginn jeder Runde in unseren Durchläufen, sodass die Platzierung dort nichts sparte und jede Rundenöffnung den vollen Preis zahlte, $2.1M ein Jahr für denselben Verkehr.

Unsere Messungen verwenden einen kontrollierten Prompt. OpenRouter veröffentlicht, was die gleichen Modelle auf dem Verkehr aller Leute kosten, und der gleiche Mechanismus taucht dort bei Skalierung auf. Fast alles, was an diese Modelle gesendet wird, ist Eingabe: 96,3 % der GPT-6 Luna Tokens an ihrem ersten Tag, 98,5 % der Claude Opus 5,5 und DeepSeek V4,1 Flash, und 98,9 % der Muse Spark 1,3. Eingabe ist der Ort, an dem Caching anwendbar ist, sodass die Trefferquote die meisten Kosten eines Unternehmens bestimmt.

Kunden zahlten $0.87 pro Million Eingabetokens für Claude Opus 5.5 gegen einen gelisteten $4.00, $0.30 gegen $1.25 für Muse Spark 1.3, und $0.036 gegen $0.10 für GPT-6 Luna. Über Endpunkte, die dasselbe Modell am selben Tag bedienen, folgt der gezahlte Preis der Trefferquote:

Die Preisgestaltung jedes Fehlers als Cache-Schreiben und jedes Treffers als Lesevorgang vorhersagt die veröffentlichten Preise der 5 Hauptendpunkte innerhalb von 2–13%. Die Trefferquote allein erklärt die Streuung. Bei GPT-6 Luna läuft das gleiche Muster von $0.025 bei einer 88.1% Trefferquote bis $0.075 bei 49.4%, ein Faktor von 3.

Die gleiche Platzierungsentscheidung wirkt sich unterschiedlich auf jede Art von Organisation aus, die auf diesen APIs aufbaut.

Harness‑Builder setzen die Hit‑Rate für jeden Nutzer gleichzeitig. Die 5 Apps, die Claude Opus 5.5 am meisten Traffic an ihrem ersten Tag schickten, waren alle Agenten, zwischen 2.9B und 16.3B Tokens je. Für einen Harness bei 10B Input‑Tokens pro Tag auf diesem Modell ist jeder Punkt der Cache‑Hit‑Rate wert $175K pro Jahr. Die Lücke zwischen den 92.2% und 77.4% Endpunkten oben beträgt $2.07M pro Jahr bei diesem Volumen. Ein Clock im System‑Prompt, der jeden Turn‑Opening neu schreibt, kostet zwischen $1.75M und $8.76M pro Jahr, je nachdem, ob Turn‑Openings 1 Call in 10 oder 1 in 2 sind. Die Entscheidung reist auch: jedes Produkt, das auf einem Harness gebaut wird, erbt seine Platzierung. Während wir das schrieben, fanden wir denselben System‑Prompt‑Clock in einem zweiten Harness von uns, der eine ältere Version des gleichen Runners nutzt.

Unternehmen, die eine interne AI‑Plattform betreiben, setzen sie für jedes Team hinter ihnen. Ein Gateway, das jeden Request‑System‑Prompt mit einem Zeitstempel oder Request‑ID für Audits versieht, wandelt jede Turn‑Opening eines Applications in Writes um, egal was die Teams darüber aufbauen. Buchhaltung ist die zweite Exposition. Zur Listenpreis zurückgebucht, sehen die Input‑Kosten 2.8× größer aus als die Rechnung bei GPT-6 Luna, 4.1× bei Muse Spark 1.3 und 4.6× bei Claude Opus 5.5. Unser eigenes Ledger hat 33 Calls um 2.7× überschätzt, und ich kam kurz davor, Modelle wegen dessen Stärke zu wechseln.

Unternehmen, die AI‑Produkte versenden, zahlen es bei jeder Konversation. Innerhalb einer Konversation kostete der falsch platzierte Clock 5.7× pro Turn. Auf dem Markt laufen die Einsätze größer. Am 21. September nahm Muse Spark 1.3 88,5 B Input‑Tokens durch OpenRouter. Zum Listenpreis sind das $110.6K; Kunden zahlten $26.9K, und jeder Punkt der Hit‑Rate auf diesem Traffic ist wert $355K pro Jahr. DeepSeek V4.1 Flash nahm am selben Tag 2,68 T Input‑Tokens, und bei DeepInfra's Preisen ist jeder Punkt wert $1,33 M pro Jahr. Diese Zahlen decken einen Router. Der Verkehr, der direkt an die Anbieter gesendet wird, erscheint nicht bei ihnen.

Jeder dieser Kosten lässt sich auf denselben Mechanismus zurückführen, und das Gleiche gilt für die Lösung. Die Konventionen gut gebauter Agent-Harnesses lesen sich wie ihre Konsequenzen:

Die oben genannte Lösung ist eine einzige Bearbeitung. Die Bedingungen darum herum bewegen sich weiter. Ein Harnis erhält einen neuen Hook, ein Gateway beginnt Anfragen mit einer ID zu stempeln, ein Team wechselt zu einem Modell mit einem anderen Cache-Mechanismus, ein Anbieter ändert, wie lange ein inaktiver Präfix warm bleibt. Die vier hier genannten Modelle cachen auf vier verschiedene Arten, und Claude Opus 5.5 ließ einen Cache innerhalb von 10 Minuten inaktiv kalt werden. Der zweite Harnis, bei dem wir die gleiche Uhr gefunden haben, blieb einfach auf einer älteren Version aktiv. Keines davon löst einen Fehler aus.

Jeder Aufruf gibt bereits zurück, was nötig ist, um ihn zu sehen: Prompt-Tokens, gecachte Tokens, Cache-Schreib-Tokens und die berechnete Kosten. Aufzeichnung pro Aufruf, zusammen mit ob der Aufruf einen neuen Durchgang eröffnete oder einen fortsetzte, geben drei Zahlen, die für jede Route und jedes Modell beobachtet werden sollten:

Ein Schwellenwert für diese Zahlen fängt einen plötzlichen Abfall ein. Die Ursache über Wochen von Daten zu benennen ist ein Klassifizierungsproblem, und eine neuere Modellklasse passt dazu. Jev, aus TypeSafe, ist das, was sein Hersteller ein System One Modell nennt. Es erzeugt keinen Text. Es nimmt einen Zustand und typisierte Fragen und gibt typisierte Antworten mit einer Wahrscheinlichkeitsverteilung und einem Vertrauen zurück: eine Auswahl unter Optionen, eine Wahrscheinlichkeit von Ja oder eine Position auf einer geordneten Skala. Angesichts des täglichen Cache-Profils einer Route kann es das Muster benennen, dem der Tag entspricht (gesund, Öffnungen umschreiben, Cache läuft zwischen den Runden ab, Verkehr erreicht ein Ziel, das nicht gecacht wird) und sagen, wie sicher es ist, sodass eine Änderung der Kategorie zur Warnung wird. Wir verwenden es in der Produktion, um Dokumente zu klassifizieren und, in der Beobachtung, um abgeschlossene Agentenepisoden zu bewerten. OpenRouter listet es bei $0.042 pro Million Eingabetoken ohne Kosten für die Ausgabe. Zu diesem Preis kostet die Klassifizierung eines 2K-Token-Tagesprofils für jede der 1,000 Routen etwa $31 pro Jahr, gegenüber $175K pro Jahr für einen einzelnen Trefferpunkt bei der oben genannten Harness-Skala.

Ein System, das seinen Cache ständig umschreibt, zahlt die Prämie bei jeder Runde jeder Konversation, solange es läuft, und die Rechnung sagt selten, warum. Die Lösung kann so klein sein wie die Stelle, an der die Zeit geschrieben wird. Das Festhalten erfordert eine Anzahl, die jemand beobachtet.

Jede gemessene Zahl oben stammt aus den eigenen pro-Aufruf Feldern von OpenRouter (cached tokens, cache-write tokens und berechnete Kosten) vom 23. September 2026. Die Marktzahlen stammen von den öffentlichen Modellseiten von OpenRouter gelesen an diesem Tag: der tatsächlich gezahlte gewichtete Eingabepreis, der effektive Preis jedes Endpunkts und die Trefferquote des Caches sowie ein Tag Token-Aktivität pro Modell. Claude Opus 5.5 und GPT-6 Luna wurden am 22. September gestartet, sodass ihre Aktivitätszahlen einen Teil des ersten Tages abdecken, und der Artikel verwendet sie nur als Anteile. Die Experimente kosteten insgesamt $0.63, und der Probe wurde abgelehnt, sobald der Kontonutzung einen $1-Grenzwert erreichte. Die Preise sind die gelisteten Preise von OpenRouter gelesen an diesem Tag. OpenRouters Caching‑Guide listet OpenAI Cache-Lesevorgänge zu 0,25–0,50×; GPT-6 Luna berechnete seine Lesevorgänge zu 0,10×, und dieser Artikel berichtet, was berechnet wurde.

Noch offen: der genaue Punkt, an dem der inaktive Cache jedes Modells abläuft, welcher einzelne zeitlich begrenzte Lauf nur die Klammern bildet; wie oft eine stündliche oder datumsbasierte Uhr bei echten Gesprächslücken versagt; warum Muse Spark zu Beginn jeder Runde fehlte, wenn seine Historie unverändert war; und das Verhalten von DeepSeek an seinem eigenen Endpunkt. Die pro-Runde-Lösung ist in unserem Produktionsagenten aktiv, und die gleiche Erkenntnis wurde für ein zweites Harness in Warteschlange gestellt, das eine ältere Version desselben Runners ausführt.

Von mir. Die Frage hinter dem Artikel: warum KI nie scheinbar das Datum und die Uhrzeit genau kannte und Sekunden brauchte, um sie zu nennen, obwohl es sofort sein sollte. Die Idee, dass die Zeit im Verlauf einer Sitzung veraltet und erneut bereitgestellt werden muss, meine Vermutung, dass eine deterministische, nur-bei-veraltet Nachricht den Prompt cached, und der Versuch, dies durch Experiment zu testen. Die Kostenrahmung: quantifiziert für die Unternehmen, die auf diesen Modellen aufbauen, von Harness-Bauern bis zu Unternehmen, die ihre eigenen internen KI-Plattformen betreiben, wie es heute steht und wie es sich kumuliert. Der Abschluss der laufenden Beobachtung, mit einem System One Modell wie Jev, das das Cache‑Profil im Zeitverlauf klassifiziert, weil die Lösung nur so lange hält, wie jemand weiter beobachtet.

Von Claude Opus 5.5. Es stellte fest, dass unser Kostenbuch die Caching versteckte, 2.7× bei 33 Aufrufen, und die Ursache auf 2 Zeilen im Systemprompt zurückführte, die sich bei jedem Zug änderten. Es entwickelte die Runner‑Lösung, die jetzt in Produktion ist, die Probe, die Analyse und das Kostenmodell hinter jeder Zahl hier, und verglich den Mechanismus mit OpenRouter's öffentlichen Marktzahlen. Über die 4 Modelle hinweg identifizierte es 3 verschiedene Cache‑Verhalten, einschließlich des gesamten Nachrichtenverhaltens von GPT-6 Luna, und ein viertes Modell ohne nutzbaren Cache.