Agent OpenClaw en panne à 65 % de contexte : 683 k tokens, aucune lecture de cache sur Ollama/GLM

Un développeur a fait tourner un agent OpenClaw nommé Francis sur Discord pendant environ 23 heures avec GLM 5.3 Flash sur Ollama Cloud, avec une fenêtre de contexte nominale de 1 048 576 tokens. Environ 6 humains répartis sur plusieurs salons Discord lui ont parlé pendant qu'il gérait des appels d'outils, des reçus, des tâches de codage, des revues de code et des lectures de fichiers. Il a tenu bon sur environ 800 événements de transcription, puis a échoué brutalement à environ 65 % de la fenêtre de contexte configurée.

Chronologie de la panne

• ~683k tokens : Francis a répondu à un message concernant une tâche de configuration terminée avec des instructions d'un projet complètement différent discuté environ 19 heures plus tôt. Anglais toujours cohérent, mauvais moment.
• 2 minutes plus tard : Un long monologue interne de planification sur la tâche obsolète, puis effondrement en des centaines de répétitions du mot design.
• Ensuite : des coches, tool tool tool, toolResult, une fausse transcription, des nombres répétés et des fragments de sa propre enveloppe d'orchestration.
• ~688k tokens : derniers tours défectueux.

La session ne s'est jamais rétablie. Les commandes normales (/new, /reset, /stop) n'ont pas pu l'interrompre, et l'opérateur a dû tuer la session OpenClaw elle-même.

Le point qui compte vraiment : il a signalé un succès

Aucune erreur de dépassement. Aucune erreur du fournisseur. Aucun timeout. Du point de vue du harness, design design design était une complétion de modèle parfaitement valide. La compaction automatique était prévue autour du moment où il restait environ 25 % de la fenêtre — elle a échoué environ 100k tokens avant que le filet de sécurité ne doive se déclencher.

Statistiques de cache : cacheRead=0, cacheWrite=0

Chaque tour Ollama/GLM affecté a montré zéro lecture de cache visible et zéro écriture de cache. La télémétrie du cache était indisponible ou nulle, donc OpenClaw n'avait aucune preuve que le préfixe répété était réutilisé. Environ dix tours dans les 25 dernières minutes portaient chacun un prompt d'environ 680k tokens — soit environ 6,1 millions de tokens d'entrée poussés en si peu de temps.

Une session d'agent distincte juste avant l'effondrement principal a enregistré 6 912 253 tokens d'entrée, 28 956 tokens de sortie, zéro lecture de cache, zéro compaction, aucun timeout, aucune erreur du fournisseur. Quelques minutes plus tard, cet agent a affirmé que son historique de conversation contenait des personnes, des outils et des canaux fabriqués, et a admis qu'il ne pouvait plus distinguer quelles parties de son contexte étaient réelles.

La conversation sur la mise en cache

Quelques minutes avant l'effondrement, l'opérateur a demandé à Francis si une couche de cache valait la peine d'être construite, étant donné tout le texte répété qui circulait dans le système. Francis a affirmé avec assurance qu'il n'y avait rien d'utile à faire car le contexte répété est déjà bon marché chez le fournisseur via le cache de prompt/KV. C'est une bonne réponse pour OpenAI ou Anthropic, où les préfixes stables sont mis en cache et la télémétrie le prouve. C'était faux pour la route Ollama/GLM utilisée — l'agent disait effectivement à l'opérateur « ce bout est bon marché » alors que le harness renvoyait ~680k tokens par tour.

La leçon n'est pas « petit modèle mauvais » — l'agent a fait du vrai travail pendant presque une journée entière d'abord. Le problème est que le harness a fait confiance à un cache qui n'était pas là, n'avait pas de déclencheur de compaction avant ~75 %, et a traité une sortie dégénérée comme une complétion réussie. Si vous exécutez des agents à long contexte contre des fournisseurs sans télémétrie de cache vérifiable, surveillez l'accumulation de vos tokens d'entrée, pas seulement votre pourcentage de contexte.