Após a autora analisar uma carga de trabalho do OpenClaw, descobriu-se que 79% do consumo de tokens vinha da reprodução de prefixos em cache (cached prefix replay), e não da entrada do usuário ou da saída do modelo. Ela propôs três grandes estratégias de otimização de contexto, que efetivamente reduziram os custos operacionais do AI Agent. Este artigo é baseado na obra de MOSHIII (Why My OpenClaw Sessions Burned 21.5M Tokens in a Day (And What Actually Fixed It)), editado e traduzido por Dongqu. (Resumo: A MEXC entrou no Top 3 global de CEXs, aprofundando sua estratégia no mercado de commodities e spot) (Contexto adicional: O mercado em baixa se sustenta com o rendimento das stablecoins: comparação de taxas de juros em várias plataformas OSL 18%, MEXC 15%, Binance 8%...) Analisei uma carga de trabalho real do OpenClaw e descobri um padrão que acredito que muitos usuários de Agent reconheceriam: o uso de tokens parecia muito "ativo" as respostas pareciam normais, mas o consumo de tokens de repente disparou. Abaixo está a análise desta vez, a decomposição da estrutura, as causas fundamentais e os caminhos de correção viáveis. Maior motor de custo: reprodução de prefixos em cache. O principal fator de custo não é que as mensagens dos usuários sejam muito longas. Em vez disso, são enormes quantidades de prefixos em cache que estão sendo reproduzidos repetidamente. Com base nos dados da sessão: Total de tokens: 21,543,714 cacheRead: 17,105,970 (79.40%) input: 4,345,264 (20.17%) output: 92,480 (0.43%) Em outras palavras: a maior parte do custo das chamadas não está realmente em processar novas intenções dos usuários, mas sim em ler repetidamente enormes contextos históricos. Eu inicialmente pensei que o alto uso de tokens vinha de: prompts de usuários muito longos, uma grande quantidade de geração de saída, ou chamadas de ferramentas caras. Mas o padrão que realmente dominou foi: input: centenas a milhares de tokens cacheRead: 170,000 a 180,000 tokens por chamada. Ou seja, o modelo está lendo repetidamente o mesmo enorme prefixo estável em cada rodada. Decomposição dos dados da sessão. Analisei dados em dois níveis: 1. logs de execução (runtime logs) 2. transcrições de sessões (session transcripts) É importante notar que: os logs de execução são principalmente usados para observar sinais de comportamento (como reinicializações, erros, problemas de configuração). Estatísticas precisas de tokens vêm da coluna de uso no JSONL da sessão. Scripts utilizados: scripts/session_token_breakdown.py scripts/session_duplicate_waste_analysis.py Arquivos de análise gerados: tmp/session_token_stats_v2.txt tmp/session_token_stats_v2.json tmp/session_duplicate_waste.txt tmp/session_duplicate_waste.json tmp/session_duplicate_waste.png Houve uma sessão cujo consumo foi muito maior do que os outros: 570587c3-dc42-47e4-9dd4-985c2a50af86: 19,204,645 tokens. Em seguida, houve uma queda acentuada: ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1,505,038 ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649,584 tokens. Principalmente provenientes de: toolUse: 16,372,294 stop: 5,171,420 Explicando que o problema está mais na cadeia de chamadas de ferramentas do que em conversas normais. De onde vêm os picos de tokens? Os picos de tokens não são aleatórios, mas se concentram em alguns períodos curtos: 2026-03-08 16:00: 4,105,105 2026-03-08 09:00: 4,036,070 2026-03-08 07:00: 2,793,648 Não é o conteúdo da conversa, mas principalmente grandes produtos intermediários: enormes blocos de dados de toolResult longas trilhas de raciocínio/pensamento grandes instantâneas de JSON listas de arquivos dados coletados do navegador registros de conversas de Sub-Agentes Na sessão máxima, a quantidade de caracteres é aproximadamente: toolResult:text: 366,469 caracteres assistant:thinking: 331,494 caracteres assistant:toolCall: 53,039 caracteres Uma vez que esse conteúdo é mantido no contexto histórico, cada chamada subsequente pode lê-los novamente através do prefixo em cache. Os blocos de contexto massivos apareceram repetidamente nos seguintes locais: sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70 Grande log JSON do gateway (cerca de 37.000 caracteres) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134 Instantânea do navegador + embalagem de segurança (cerca de 29.000 caracteres) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219 Saída de lista de arquivos enorme (cerca de 41.000 caracteres) sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311 snapshot de status da sessão + estrutura de prompt grande (cerca de 30.000 caracteres) Também medi a proporção de conteúdo repetido dentro de uma única chamada: Proporção de repetição: aproximadamente 1.72%. Certamente existe, mas não é o principal problema. O verdadeiro problema é: a quantidade absoluta de prefixos em cache é muito grande. A estrutura é: um enorme contexto histórico, leitura repetida em cada chamada, apenas uma pequena quantidade de nova entrada sendo adicionada por cima. Portanto, o foco da otimização não deve ser na remoção de duplicatas, mas sim no design da estrutura do contexto. Três mecanismos de expansão de contexto Três mecanismos se sobrepõem: 1. Uma quantidade massiva de saídas de ferramentas sendo escritas no contexto histórico. 2. Os loops de ferramentas geram chamadas de intervalos curtos em grandes quantidades. 3. As variações de prefixo são mínimas → o cache lê novamente a cada vez. Se a compactação do contexto não for acionada de maneira estável, o problema se amplifica rapidamente. Estratégias de otimização práticas Para saídas de ferramentas extremamente grandes: · Manter resumos ...