Como isso acontece com o OpenClaw e como você pode consertar... Meu bot continua despejando resultados massivos e repetitivos de ferramentas, faz trabalho pesado de executivo e entra em loops de depuração na sessão compartilhada em que meus DMs estão, ficando travado por 10 minutos até que ele seta o tempo ou o gateway trave e reinicia. Isso causa mensagens caídas, bots não responsivos e travamentos do OOM várias vezes por hora. Mesmo quando faço o bot delegar, os subagentes despejam os resultados na janela de contexto. Pedi para o Codex investigar e ele encontrou: • 56 resultados de ferramentas ≥150k caracteres já incorporados ao histórico atual das sessões • A poda não funciona no caminho principal do nosso modelo (Codex/OpenAI Oauth) • Nenhuma aplicação em tempo de execução para impedir grandes despejos de ferramentas em contexto • A manutenção de sessão limpa após o dano, não o impede Tenho quase certeza de que o comportamento padrão do OpenClaw não deveria despejar resultados da ferramenta de 200k caracteres na transcrição. Algo na minha configuração específica deve ser ou desativar uma salvaguarda ou pular o truncamento para resultados de ferramentas... Como estou usando o lossless-claw, isso pode piorar ainda mais: 81MB de sessão de arquivo, 31,6MB é apenas texto 😬 do resultado da ferramenta 169 resultados de ferramentas em 50 mil caracteres. Um deles tem 285 mil caracteres (de sessions_list.) Existe a lógica de poda que elimina os resultados da ferramenta das mensagens de contexto. buildContextoPodaFábrica Mas os modelos precisam ser "cache-ttl" Os provedores elegíveis aparentemente são apenas: Anthropic Moonshot Zai No meu caso, meu bot me diz que o código de poda se recusa a ativar em provedores que não são Anthropics. Estou usando muito o openai-codex 5.3, então quando a poda está configurada, o código existe, só que silenciosamente nunca ativa. A API de Respostas do OpenAI usa compactação do lado do servidor e o OpenClaw habilita isso automaticamente para modelos OpenAI diretos, então o OpenAI cuida da compactação do lado deles. Mas estou usando openai-codex/*, não openai/*. O caminho do Codex OAuth passa por um runtime diferente (aparentemente pi-ai), não pela API Responses. Então: • poda cache-ttl > apenas antropica • Compactação OpenAI no lado do servidor > apenas API OpenAI direta • LCM/lossless-claw > não poda resultados antigos, pelo que eu saiba Meu bot insiste que a faixa do openai-codex não recebe nenhum dos caminhos de poda. Então fico com um bot que depende da função de truncamento de emergência truncateOversizedToolResultsInSession com muita frequência como recuperação de transbordamento de último recurso, sem poda preventiva / proteção. Como LCM/lossless-claw não tem sua própria ferramenta de gerenciamento de resultados, ele herda transcrições enormes e superdimensionadas e precisa trabalhar muito para resumir os nós DAG. Não tenho manutenção de sessão e sessões longas, então nada limita a transcrição ao longo do tempo, resultando em: 4.707 resultados de ferramentas se acumulando para sempre em um arquivo de 81MB, sem nenhum mecanismo de execução realmente limpando-os. Quando meu bot começa a depurar, ele começa a fazer grepping e despejar texto enorme na sessão principal, depois fica preso nesse loop, morre e precisa repetir, agravando o problema. Não sei como lidar com esse problema, ele tem várias camadas profundas.

@quinnzeda Mas você pode estar certo... Mas talvez eu precise tirar uma semana de folga antes de tentar isso.