Agente OpenClaw quebrou aos 65% de contexto: 683k tokens, zero leituras de cache no Ollama/GLM

Um desenvolvedor rodou um agente OpenClaw chamado Francis no Discord por cerca de 23 horas com o GLM 5.3 Flash na Ollama Cloud, com uma janela de contexto nominal de 1.048.576 tokens. Cerca de 6 humanos, em vários canais do Discord, conversaram com ele enquanto o agente lidava com chamadas de ferramentas, recibos, tarefas de programação, revisões de código e leitura de arquivos. Ele se manteve firme ao longo de ~800 eventos de transcrição e então falhou de vez aos 65% da janela de contexto configurada.

A linha do tempo da falha

• ~683 mil tokens: Francis respondeu a uma mensagem sobre uma tarefa de configuração concluída com instruções de um trabalho completamente não relacionado, discutido ~19 horas antes. O inglês ainda era coerente, só o momento estava errado.
• 2 minutos depois: um longo monólogo interno de planejamento sobre a tarefa obsoleta, seguido de colapso em centenas de repetições da palavra design.
• Depois disso: checkmarks, tool tool tool, toolResult, transcrição falsa, números repetidos e fragmentos do seu próprio envelope de orquestração.
• ~688 mil tokens: turnos finais quebrados.

A sessão nunca se recuperou. Os controles normais (/new, /reset, /stop) não conseguiram interrompê-la, e o operador teve que encerrar a própria sessão do OpenClaw.

A parte que realmente importa: ele reportou sucesso

Sem erro de overflow. Sem erro do provedor. Sem timeout. Do ponto de vista do harness, design design design era uma conclusão de modelo perfeitamente válida. Esperava-se compactação automática por volta do ponto em que restassem cerca de 25% da janela — mas ele quebrou cerca de 100 mil tokens antes de a rede de segurança ser acionada.

Estatísticas de cache: cacheRead=0, cacheWrite=0

Todo turno afetado do Ollama/GLM mostrou zero leituras de cache visíveis e zero gravações de cache. A telemetria de cache estava indisponível ou zerada, então o OpenClaw não tinha evidência de que o prefixo repetido estava sendo reaproveitado. Cerca de dez turnos nos 25 minutos finais carregavam cada um um prompt de aproximadamente 680 mil tokens — cerca de 6,1 milhões de tokens de entrada empurrados em uma janela curta.

Uma sessão separada do agente, pouco antes do colapso principal, registrou 6.912.253 tokens de entrada, 28.956 tokens de saída, zero leituras de cache, zero compactações, sem timeout e sem erro do provedor. Minutos depois, esse agente alegou que seu histórico de conversa continha pessoas, ferramentas e canais fabricados, e admitiu que já não conseguia distinguir quais partes do seu contexto eram reais.

A conversa sobre cache

Minutos antes do colapso, o operador perguntou a Francis se valia a pena construir uma camada de cache, dado todo o texto repetido circulando pelo sistema. Francis respondeu com confiança que não havia nada útil a fazer, porque o contexto repetido já sai barato no provedor via cache de prompt/KV. Essa é uma boa resposta para OpenAI ou Anthropic, onde prefixos estáveis são cacheados e a telemetria comprova isso. Era falso para a rota Ollama/GLM em uso — o agente estava efetivamente dizendo ao operador "essa parte é barata" enquanto o harness reenviava ~680 mil tokens por turno.

O aprendizado não é "modelo pequeno é ruim" — o agente fez trabalho de verdade por quase um dia inteiro antes. O problema é que o harness confiou em um cache que não existia, não tinha gatilho de compactação antes de ~75% e tratou saída degenerada como conclusão bem-sucedida. Se você roda agentes de contexto longo contra provedores sem telemetria de cache verificável, acompanhe a acumulação de tokens de entrada, não só a porcentagem do seu contexto.