Agente OpenClaw se rompió al 65% de contexto: 683k tokens, cero lecturas de caché en Ollama/GLM

Un desarrollador ejecutó un agente de OpenClaw llamado Francis en Discord durante aproximadamente 23 horas contra GLM 5.3 Flash en Ollama Cloud, con una ventana de contexto nominal de 1.048.576 tokens. Unos 6 humanos en varios canales de Discord hablaron con él mientras gestionaba llamadas a herramientas, recibos, tareas de programación, revisiones de código y lecturas de archivos. Se mantuvo en pie durante ~800 eventos de transcripción, y luego falló estrepitosamente alrededor del 65% de la ventana de contexto configurada.

La línea temporal del fallo

• ~683k tokens: Francis respondió a un mensaje sobre una tarea de configuración terminada con instrucciones de un trabajo completamente distinto discutido ~19 horas antes. Inglés aún coherente, momento equivocado.
• 2 minutos después: Un largo monólogo interno de planificación sobre la tarea obsoleta, y luego colapso en cientos de repeticiones de la palabra design.
• Después de eso: marcas de verificación, tool tool tool, toolResult, transcripción falsa, números repetidos y fragmentos de su propio sobre de orquestación.
• ~688k tokens: turnos finales rotos.

La sesión nunca se recuperó. Los controles normales (/new, /reset, /stop) no pudieron interrumpirlo, y el operador tuvo que matar la propia sesión de OpenClaw.

La parte que realmente importa: reportó éxito

Sin error de desbordamiento. Sin error del proveedor. Sin timeout. Desde el punto de vista del harness, design design design era una finalización del modelo perfectamente válida. Se esperaba una compactación automática alrededor del punto en que quedara aproximadamente el 25% de la ventana — se rompió unos 100k tokens antes de que la red de seguridad debiera activarse.

Estadísticas de caché: cacheRead=0, cacheWrite=0

Cada turno afectado de Ollama/GLM mostró cero lecturas de caché visibles y cero escrituras de caché. La telemetría de caché no estaba disponible o era cero, así que OpenClaw no tenía evidencia de que el prefijo repetido se estuviera reutilizando. Alrededor de diez turnos en los últimos 25 minutos llevaban cada uno un prompt de aproximadamente 680k tokens — unos 6,1 millones de tokens de entrada procesados en esa corta ventana.

Una sesión de agente separada poco antes del colapso principal registró 6.912.253 tokens de entrada, 28.956 tokens de salida, cero lecturas de caché, cero compactaciones, sin timeout, sin error del proveedor. Minutos después, ese agente afirmó que su historial de conversación contenía personas, herramientas y canales fabricados, y admitió que ya no podía distinguir qué partes de su contexto eran reales.

La conversación sobre el caché

Minutos antes del colapso, el operador le preguntó a Francis si valía la pena construir una capa de caché, dado todo el texto repetido que circulaba por el sistema. Francis dijo con confianza que no había nada útil que hacer porque el contexto repetido ya es barato en el proveedor mediante caché de prompt/KV. Esa es una buena respuesta para OpenAI o Anthropic, donde los prefijos estables se cachean y la telemetría lo demuestra. Era falsa para la ruta Ollama/GLM en uso — el agente le estaba diciendo efectivamente al operador "esto es barato" mientras el harness reenviaba ~680k tokens por turno.

La conclusión no es "modelo pequeño malo" — el agente hizo trabajo real durante casi un día entero primero. El problema es que el harness confió en un caché que no estaba ahí, no tenía un disparador de compactación antes del ~75%, y trató la salida degenerada como una finalización exitosa. Si ejecutas agentes de contexto largo con proveedores sin telemetría de caché verificable, vigila la acumulación de tokens de entrada, no solo el porcentaje de contexto.