OpenClaw-Agent brach bei 65 % Kontext ab: 683k Token, keine Cache-Lesevorgänge bei Ollama/GLM

Ein Entwickler betrieb einen OpenClaw-Agenten namens Francis etwa 23 Stunden lang in Discord gegen GLM 5.3 Flash auf Ollama Cloud, mit einem nominalen Kontextfenster von 1.048.576 Tokens. Ungefähr 6 Menschen in mehreren Discord-Kanälen sprachen mit ihm, während es Tool-Aufrufe, Belege, Codierungsaufgaben, Code-Reviews und Dateilesevorgänge bewältigte. Es hielt etwa 800 Transkript-Ereignisse lang durch und versagte dann hart bei etwa 65 % des konfigurierten Kontextfensters.

Die Fehler-Zeitleiste

• ~683k Tokens: Francis antwortete auf eine Nachricht über eine abgeschlossene Setup-Aufgabe mit Anweisungen aus einem völlig unrelated Job, der ~19 Stunden früher besprochen worden war. Noch kohärentes Englisch, falscher Moment.
• 2 Minuten später: Ein langer interner Planungsmonolog über die veraltete Aufgabe, dann Zusammenbruch in Hunderte Wiederholungen des Wortes design.
• Danach: Häkchen, tool tool tool, toolResult, gefälschtes Transkript, wiederholte Zahlen und Fragmente seiner eigenen Orchestrierungs-Hülle.
• ~688k Tokens: letzte kaputte Turns.

Die Sitzung erholte sich nie. Normale Steuerungen (/new, /reset, /stop) konnten sie nicht unterbrechen, und der Operator musste die OpenClaw-Sitzung selbst beenden.

Der Teil, der wirklich zählt: Es meldete Erfolg

Kein Overflow-Fehler. Kein Provider-Fehler. Kein Timeout. Aus Sicht des Harness war design design design eine vollkommen gültige Modell-Vervollständigung. Automatische Kompaktierung wurde etwa zu dem Zeitpunkt erwartet, an dem ungefähr 25 % des Fensters verblieben waren – es brach etwa 100k Tokens, bevor das Sicherheitsnetz ausgelöst werden sollte.

Cache-Statistiken: cacheRead=0, cacheWrite=0

Jeder betroffene Ollama/GLM-Turn zeigte null sichtbare Cache-Reads und null Cache-Writes. Die Cache-Telemetrie war nicht verfügbar oder null, sodass OpenClaw keine Hinweise darauf hatte, dass das wiederholte Präfix wiederverwendet wurde. Etwa zehn Turns in den letzten 25 Minuten trugen jeweils einen Prompt von ungefähr 680k Tokens – etwa 6,1 Millionen Input-Tokens, die in diesem kurzen Fenster durchgeschleust wurden.

Eine separate Agentensitzung kurz vor dem Hauptzusammenbruch verzeichnete 6.912.253 Input-Tokens, 28.956 Output-Tokens, null Cache-Reads, null Kompaktierungen, keinen Timeout, keinen Provider-Fehler. Minuten später behauptete dieser Agent, seine Konversationshistorie enthalte erfundene Personen, Tools und Kanäle, und gab zu, nicht mehr unterscheiden zu können, welche Teile seines Kontexts real waren.

Die Caching-Diskussion

Minuten vor dem Zusammenbruch fragte der Operator Francis, ob es sich lohne, eine Caching-Schicht zu bauen, angesichts all des wiederholten Textes, der durch das System lief. Francis sagte selbstbewusst, es gäbe nichts Nützliches zu tun, weil wiederholter Kontext beim Provider durch Prompt/KV-Caching bereits günstig sei. Das ist eine gute Antwort für OpenAI oder Anthropic, wo stabile Präfixe gecacht werden und die Telemetrie dies belegt. Für die verwendete Ollama/GLM-Route war es falsch – der Agent sagte dem Operator effektiv „dieser Teil ist günstig“, während das Harness pro Turn ~680k Tokens erneut sendete.

Die Erkenntnis ist nicht „kleines Modell schlecht“ – der Agent leistete fast einen ganzen Tag lang echte Arbeit. Das Problem ist, dass das Harness einem Cache vertraute, der nicht existierte, keinen Kompaktierungs-Trigger vor ~75 % hatte und degenerierten Output als erfolgreiche Vervollständigung behandelte. Wenn Sie Long-Context-Agenten gegen Provider ohne verifizierbare Cache-Telemetrie betreiben, beobachten Sie Ihre Input-Token-Akkumulation, nicht nur Ihren Kontext-Prozentsatz.