Por que minhas sessões do OpenClaw queimaram 21,5 milhões de tokens em um dia (e o que realmente resolveu)
Autor original: MOSHIII
Compilação original: Peggy, BlockBeats
Nota do editor: No momento em que os aplicativos de Agent estão se tornando amplamente difundidos, muitas equipes observaram um fenômeno aparentemente paradoxal: o sistema opera normalmente, mas o custo dos tokens aumenta continuamente e silenciosamente. Este artigo, ao analisar uma carga de trabalho real do OpenClaw, descobriu que a causa do aumento de custos geralmente não está nas entradas do usuário nem nas saídas do modelo, mas sim no negligenciado replay de contexto em cache (cached prefix replay). O modelo lê repetidamente grandes contextos históricos em cada chamada, gerando um consumo massivo de tokens.
O artigo combina dados de sessão específicos para mostrar como grandes artefatos intermediários, como saídas de ferramentas, instantâneos de navegador e logs JSON, são continuamente gravados no contexto histórico e lidos repetidamente no ciclo do agente.
Através deste caso, o autor apresenta uma abordagem clara de otimização: desde o design da estrutura de contexto, gerenciamento da saída de ferramentas até a configuração do mecanismo de compaction. Para desenvolvedores que estão construindo sistemas de Agentes, isso não é apenas um registro de diagnóstico técnico, mas também um guia prático para economizar dinheiro.
The following is the original text:
Analisando uma carga de trabalho real do OpenClaw, identifiquei um padrão que acho que muitos usuários de Agent reconhecerão:
O uso do token parece muito "ativo"
A resposta também parece normal
Mas o consumo de tokens experimentou um crescimento explosivo súbito
Abaixo está a análise estrutural, a causa raiz e o caminho de correção praticável para esta análise.
TL;DR
O maior fator de custo não é a mensagem do usuário ser muito longa, mas sim a grande quantidade de prefixos em cache (cached prefix) sendo repetidamente retransmitidos.
A partir dos dados da sessão:
Total de tokens: 21.543.714
cacheRead: 17.105.970 (79,40%)
4.345.264 (20,17%)
saída: 92.480 (0,43%)
Em outras palavras: o custo da maioria das chamadas não está realmente em processar novas intenções do usuário, mas em ler repetidamente grandes contextos históricos.
O momento de “Espere, como isso aconteceu?”
Eu originalmente pensei que o alto uso de token vinha de: prompts de usuário muito longos, grande quantidade de saída gerada ou chamadas de ferramentas caras.
Mas o padrão realmente dominante é:
Centenas a milhares de tokens
cacheRead: 170.000 a 180.000 tokens por chamada
Ou seja, o modelo lê repetidamente o mesmo prefixo estável e enorme em cada rodada.
Intervalo de dados
Analisiei os dados em dois níveis:
1. Logs de execução (runtime logs)
2. Transcrições da sessão
É importante salientar que:
Os logs de execução são usados principalmente para observar sinais de comportamento (como reinícios, erros e problemas de configuração).
Estatísticas precisas de tokens provenientes do campo usage do JSONL da sessão
Script utilizado:
scripts/session_token_breakdown.py
scripts/session_duplicate_waste_analysis.py
Arquivo de análise gerado:
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
Onde o token é realmente consumido?
1) Sessão concentrada
Uma sessão consumiu muito mais do que as outras:
570587c3-dc42-47e4-9dd4-985c2a50af86: 19.204.645 tokens
E depois uma queda acentuada e clara:
ef42abbb-d8a1-48d8-9924-2f869dea6d4a: 1.505.038
ea880b13-f97f-4d45-ba8c-a236cf6f2bb5: 649.584
2) Comportamento concentrado
Os tokens vêm principalmente de:
toolUse：16,372,294
parar: 5.171.420
O problema está principalmente na cadeia de chamadas de ferramentas em ciclo, e não na conversa normal.
3) Concentração de tempo
Os picos de token não são aleatórios, mas concentrados em alguns períodos horários:
2026-03-08 16:00: 4.105.105
2026-03-08 09:00: 4.036.070
2026-03-08 07:00: 2.793.648
O que há no grande prefixo de cache?
Não é o conteúdo da conversa, mas principalmente o grande subproduto:
Grande bloco de dados toolResult
Longas trilhas de raciocínio / pensamento
Grande snapshot JSON
Lista de arquivos
Coleta de dados pelo navegador
Registro da conversa do Subagente
No maior session, a quantidade de caracteres é aproximadamente:
366.469 caracteres
assistant:thinking：331,494 caracteres
assistant:toolCall：53,039 caracteres
Uma vez que esses conteúdos forem mantidos no contexto histórico, cada chamada subsequente poderá lê-los novamente por meio do prefixo cache.
Exemplos específicos (do arquivo de sessão)
Blocos de contexto de grande volume apareceram repetidamente no seguinte local:
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:70
Arquivo de log JSON de grande gateway (aproximadamente 37 mil caracteres)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:134
Captura do navegador + encapsulamento seguro (aproximadamente 29.000 caracteres)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:219
Grande lista de arquivos de saída (aproximadamente 41 mil caracteres)
sessions/570587c3-dc42-47e4-9dd4-985c2a50af86.jsonl:311
session/status instantâneo de status + estrutura de prompt grande (aproximadamente 30 mil caracteres)
"Desperdício de conteúdo repetido" vs "Carga de retransmissão de cache"
Também medir a proporção de conteúdo repetido dentro de uma única chamada:
Proporção de repetição aproximada: 1,72%
Exists, but it's not the main issue.
A verdadeira questão é que o volume absoluto do prefixo de cache é muito grande
A estrutura é: grande contexto histórico, leitura reiniciada a cada chamada, com apenas poucas entradas novas adicionadas acima
Portanto, o foco da otimização não é a remoção de duplicatas, mas sim o design da estrutura do contexto.
Por que o ciclo do Agent é particularmente propenso a esse problema?
Três mecanismos se sobrepõem:
1. Grande quantidade de saídas de ferramentas foi gravada no contexto histórico
2. O ciclo da ferramenta gerará muitas chamadas com intervalos curtos.
3. A alteração do prefixo é mínima → o cache será lido novamente a cada vez
Se a compactação do contexto não for acionada de forma estável, o problema se amplificará rapidamente.
As estratégias de correção mais importantes (classificadas por impacto)
P0 — Não insira saídas de ferramentas enormes no contexto longo
Para saída de ferramenta ultra grande:
- Manter resumo + caminho/ID de referência
- Gravar payload original no arquivo artifact
- Não mantenha o texto original completo no histórico do chat
Restrições prioritárias para estas categorias:
- JSON grande
- Lista longa de catálogo
- Captura completa do navegador
- Transcrição completa do Sub Agent
P1—Garantir que o mecanismo de compactação esteja realmente ativo
Nestes dados, problemas de compatibilidade de configuração apareceram várias vezes: chave de compactação inválida
Isso desativará silenciosamente o mecanismo de otimização.
Prática correta: use apenas configurações compatíveis com a versão
Em seguida, verifique:
openclaw doctor --fix
E verifique os logs de inicialização para confirmar que a compactação foi aceita.
P1—Reduzir a persistência de texto de reasoning
Evite que textos de raciocínio longos sejam repetidamente reproduzidos
Em ambiente de produção: salve um resumo curto, em vez do raciocínio completo
P3 — Melhorar o design do cache de prompts
O objetivo não é maximizar o cacheRead. O objetivo é usar o cache em prefixos compactos, estáveis e de alto valor.
Sugestão:
- Coloque as regras estáveis no prompt do sistema
- Não coloque dados instáveis no prefixo estável
- Evite injetar grandes volumes de dados de debug a cada rodada
Plano de stop-loss prático (se eu precisasse lidar com isso amanhã)
1. Encontre a sessão com a maior proporção de cacheRead
2. Execute /compact on runaway session
3. Adicionar truncagem + artificalização à saída da ferramenta
4. Execute token statistics again after each modification
Monitore quatro KPIs principais:
cacheRead / totalTokens
toolUse avgTotal/call
Número de chamadas >= 100k tokens
Maior porcentagem de sessão
Sinal de sucesso
Se a otimização entrar em vigor, você deverá ver:
Chamadas de token reduzidas em mais de 100 mil
Proporção de cacheRead diminuiu
Peso da chamada toolUse reduzido
Redução do domínio de um único session
Se esses indicadores não mudaram, significa que sua estratégia de contexto ainda está muito flexível.
Comandos para reproduzir o experimento
python3 scripts/session_token_breakdown.py 'sessions' \
--include-deleted \
--top 20 \
--limiar-de-outlier 120000 \
--json-out tmp/session_token_stats_v2.json \
> tmp/session_token_stats_v2.txt
python3 scripts/session_duplicate_waste_analysis.py 'sessions' \
--include-deleted \
--top 20 \
--png-out tmp/session_duplicate_waste.png \
--json-out tmp/session_duplicate_waste.json \
> tmp/session_duplicate_waste.txt
Conclusão
Se o seu sistema Agent parecer estar funcionando normalmente, mas os custos estiverem aumentando continuamente, verifique primeiro este problema: você está pagando por novas inferências ou por uma grande repetição de contextos antigos?
No meu caso, a maior parte do custo vem realmente da reprodutibilidade do contexto.
Assim que você perceber isso, a solução torna-se clara: controle rigorosamente os dados que entram no contexto longo.