Como é que isso acontece com o OpenClaw e como é que se pode possivelmente corrigir isso… O meu bot continuamente despeja resultados de ferramentas massivos e repetitivos, faz um trabalho de execução pesado e entra em loops de depuração na sessão compartilhada em que estão os meus DMs e fica preso durante 10 minutos de cada vez até que ele expira ou o gateway falha e reinicia. Isto causa mensagens perdidas, bot não responsivo e falhas de OOM várias vezes por hora. Mesmo quando consigo que o bot delegue, os subagentes despejam resultados na janela de contexto. Fiz com que o codex investigasse e ele encontrou: • 56 resultados de ferramentas ≥150k caracteres já incorporados na história da sessão atual • A poda não funciona no nosso caminho de modelo principal (Codex/OpenAI Oauth) • Sem aplicação em tempo de execução para parar grandes despejos de ferramentas no contexto • A manutenção da sessão limpa após o dano, não o previne Estou bastante certo de que o comportamento padrão do OpenClaw não deveria estar despejando resultados de ferramentas de 200k caracteres na transcrição. Algo na minha configuração específica deve estar a desativar uma salvaguarda ou a ignorar a truncagem para resultados de ferramentas… Como estou a usar lossless-claw, isso pode piorar ainda mais: Arquivo de sessão de 81MB, 31.6MB é apenas texto de resultados de ferramentas 😬 169 resultados de ferramentas com mais de 50k caracteres. Um tem 285k caracteres (da sessions_list.) Há uma lógica de poda que corta resultados de ferramentas das mensagens de contexto. buildContextPruningFactory Mas os modelos têm que ser “cache-ttl" Os provedores elegíveis são aparentemente apenas: anthropic moonshot zai Para mim, o meu bot diz que o código de poda se recusa a ativar em provedores que não são da Anthropic. Estou a usar openai-codex 5.3 muito, então quando a poda está configurada, o código existe, apenas nunca ativa silenciosamente. A API de Respostas da OpenAI usa compactação do lado do servidor & o OpenClaw ativa isso automaticamente para modelos openai diretos, então a OpenAI lida com a compactação do lado deles. Mas estou no openai-codex/*, não openai/*. O caminho do Codex OAuth passa por um runtime diferente (aparentemente pi-ai), não pela API de Respostas. Então: • poda cache-ttl > apenas Anthropic • compactação do lado do servidor da OpenAI > apenas API openai direta • LCM/lossless-claw > não poda resultados de ferramentas antigos afaik O meu bot insiste que a via openai-codex não recebe nenhum dos caminhos de poda. Então fico com um bot que depende da função de truncagem de emergência truncateOversizedToolResultsInSession com demasiada frequência como recuperação de último recurso de transbordo sem poda preventiva / salvaguardas. Como o LCM/lossless-claw não tem a sua própria gestão de resultados de ferramentas, herda transcrições enormes e excessivas e tem que trabalhar extra para resumir para 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 acumulando-se para sempre em um arquivo de 81MB, sem nenhum mecanismo em tempo de execução realmente a limpá-los. Quando o meu bot começa a depurar, ele começa a grepar e despejar texto massivo na sessão principal, depois fica preso nesse loop e morre, depois tem que fazer isso novamente, agravando o problema. Estou sem ideias sobre como abordar este problema, é múltiplas camadas de profundidade.

@quinnzeda Mas você pode estar certo... Eu talvez tenha que tirar uma semana de folga antes de tentar isso.