Por que rodar teste e build no Claude Code gasta tanto token?

Fala aí, beleza? Aquele npm test tu roda UMA vez, mas o log dele continua sendo cobrado em toda mensagem que vier depois

Esse é o tipo de coisa que quase ninguém contabiliza na hora de economizar. Você já trocou pro modelo mais barato, já encurtou o prompt, já parou de colar arquivo inteiro no chat, e mesmo assim a sessão infla e o gasto de tokens no Claude Code segue subindo do nada

Neste post eu quero te mostrar três coisas: o mecanismo (por que a saída do comando vira custo recorrente), como reconhecer os comandos mais barulhentos do seu projeto, e o que dá pra fazer pra conter isso com o que a documentação oficial já entrega hoje

Bora?

O que acontece com o log do teste depois que o comando termina

O sintoma: a sessão fica cara e lenta sem ninguém escrever código novo

Você rodou a suíte, rodou o build, instalou uma dependência

Depois disso ficou só conversando, ajustando detalhe, pedindo uma renomeação boba… e a impressão é que cada resposta ficou mais pesada que a anterior

Não é impressão, não

A causa: saída de ferramenta é contexto, e contexto é reenviado

A janela de contexto do Claude Code guarda tudo o que ele sabe da sessão: suas instruções, os arquivos lidos, as respostas dele e conteúdo que nunca aparece no seu terminal

A saída de ferramenta entra nesse pacote

Então o log de teste não é um evento que acontece e some. Ele vira parte da conversa e acompanha a requisição seguinte, e a próxima, e a próxima

"Mas não existe cache?" Existe, e é automático

O Claude Code usa prompt caching e ordena cada requisição colocando primeiro o que muda pouco entre turnos. Quando a mudança acontece na camada de conversa, o system prompt e o contexto de projeto continuam em cache; quando a mudança acontece no system prompt, tudo o que vem depois dele é invalidado

Se liga no detalhe que importa aqui: o log do teste cai na camada que MUDA

E cache não é de graça. Nos multiplicadores documentados da plataforma, a leitura de cache custa 0,1x o preço do token de entrada base e a escrita de cache de 5 minutos custa 1,25x o preço de entrada base

Pra ter noção de escala, o Claude Sonnet 5 é cobrado a US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de tokens de saída

A solução: não deixar comando verboso rodar na conversa principal

A correção não é "escrever prompt menor"

É decidir, antes de mandar o agente executar, se a saída daquele comando precisa mesmo estar inteira na conversa principal pelo resto da sessão

Na maioria das vezes você quer as falhas, não as 400 linhas de "PASS" antes delas

Como reconhecer os comandos mais barulhentos da sua sessão

Não precisa de ferramenta nenhuma pra fazer essa triagem. É padrão visual mesmo

Os suspeitos de sempre:

• suíte de teste completa, que imprime uma linha por caso e repete o sumário no fim
• build, que despeja etapa por etapa, warning de dependência e tabela de bundle
• instalação de dependência, que é basicamente uma cascata de nomes de pacote
• leitura de log longo, que é o pior de todos porque quase nada ali é sinal

O critério prático é esse: se a saída é feita de linhas repetidas, barra de progresso e warning que você já ignora há meses, ela é candidata a ser filtrada antes de chegar no modelo

A própria documentação de custos usa um exemplo bem direto: em vez de o Claude ler um log de 10.000 linhas, um hook faz grep por ERROR e devolve só as linhas que casam, reduzindo de dezenas de milhares para centenas de tokens

Mesma lógica vale pra suíte de testes. É bem diferente de simplesmente fazer o agente rodar os testes e engolir o relatório inteiro: você continua rodando, só que devolve o pedaço que importa

E as ferramentas MCP?

Essas também entram na conta, com um comportamento próprio

O Claude Code avisa quando a saída de uma ferramenta MCP passa de 10.000 tokens (esse limiar é fixo) e corta a saída num teto padrão de 25.000 tokens, que dá pra elevar com MAX_MCP_OUTPUT_TOKENS

Detalhe que ajuda: as definições das ferramentas MCP são carregadas sob demanda via tool search, então só os nomes ocupam contexto até o Claude usar uma delas

Ou seja: o problema do MCP quase nunca é a definição, é o RETORNO 🙂

Como medir o quanto a saída de comando está ocupando

Chega de achismo, bora medir com os comandos oficiais

1. Rode /context ANTES da suíte. Ele mostra a divisão do contexto por categoria, com sugestões de otimização e quais arquivos CLAUDE.md e de memória foram carregados. O erro comum deste passo é pular a foto do "antes": sem linha de base, o depois não prova nada
2. Rode o comando barulhento normalmente, do jeito que você já faz no dia a dia. O erro comum aqui é escolher um comando manso pra testar e concluir que "não é tanta coisa assim"
3. Rode /context de novo e compare categoria por categoria. É nessa comparação que a saída de ferramenta aparece pelo que ela é: um bloco que não vai embora sozinho
4. Abra /usage pra ver o uso de tokens atual, olhando o bloco Session, que traz o uso de tokens de API
5. Leia o detalhamento do /usage se você está em plano Pro, Max, Team ou Enterprise: ele sinaliza comportamentos responsáveis por 10% ou mais do uso recente, como contexto longo ou cache miss, cada um com uma dica pra reduzir. O erro comum deste passo é bater o olho no total e fechar, sem ler o que foi sinalizado
6. Use /compact pra resumir a conversa e liberar espaço quando o diagnóstico confirmar que a janela está entupida

O erro comum que atravessa todos os passos é o mais caro de todos: olhar só o preço por milhão de tokens do modelo e ignorar o volume que já está morando na janela

Modelo barato com janela inchada continua saindo caro, beleza?

Quatro formas de conter a saída de comando (e o que cada uma resolve)

Uma observação sobre o BASH_MAX_OUTPUT_LENGTH: ele é configurável no shell ou em settings.json, na chave env

export BASH_MAX_OUTPUT_LENGTH=10000

{
  "env": {
    "BASH_MAX_OUTPUT_LENGTH": "10000"
  }
}

Se o seu caso é rodar rotina pesada fora do fluxo de conversa, vale considerar rodar o agente por script e trazer só o resultado de volta, em vez de deixar tudo acontecer na sessão interativa

Quando a saída é grande demais e a compactação trava

O sintoma: erro de thrashing e sessão empacada

Você manda uma coisa simples e não sai do lugar

A sessão fica tentando se organizar sozinha e devolve um erro de thrashing

A causa: uma única saída de ferramenta grande demais

Quando isso acontece, o Claude Code para de compactar automaticamente depois de algumas tentativas, em vez de entrar em loop

Pra entender o cenário completo: as sessões compactam automaticamente antes de a janela encher, por volta de 967K tokens por padrão. Esse limiar é configurável por CLAUDE_CODE_AUTO_COMPACT_WINDOW, que aceita a contagem de tokens, e pelo comando /autocompact, que aceita janela de 100K a 1M

E a ordem da limpeza é bem específica: o Claude Code apaga primeiro as saídas de ferramenta mais antigas e só depois resume a conversa, preservando os pedidos do usuário e trechos de código chave

Olha que interessante isso: a saída de ferramenta é a primeira coisa que a ferramenta joga fora

Se é o primeiro item da fila do descarte, é porque é o mais dispensável. Só que enquanto ele está lá, você paga por ele

A solução: cortar na origem, não contar com a compactação

A compactação é rede de segurança, não estratégia

Dependendo dela você já pagou o transporte daquele log por vários turnos antes de ele ser limpo

Vale lembrar que janela de 1M está disponível nos planos Pro, Max, Team e Enterprise com Sonnet 5, Fable 5, Opus 5, Opus 4.8, Opus 4.7 e Opus 4.6, e que requisição de contexto longo é cobrada a preço padrão, sem multiplicador: uma requisição de 900K tokens é cobrada pela mesma taxa por token de uma de 9K

Ou seja: cabe mais, sim, mas cada token continua custando o mesmo

E tem duas configurações que limitam a janela a 200K em vez de 1M: gateway LLM (quando ANTHROPIC_BASE_URL aponta pra um gateway) e CLAUDE_CODE_DISABLE_1M_CONTEXT=1

O que vi comparando Claude Code com outra ferramenta em tarefa real

No vídeo eu coloco o Claude Code e o Antigravity pra fazer a mesma tarefa e vou narrando o que acontece

A fase inicial de planejamento levou cerca de 5 minutos, antes de qualquer linha de código sair. Depois, com as duas ferramentas escrevendo o sistema de comentários, foram mais uns 3 minutos ainda em código. No fim, a mesma funcionalidade saiu com cerca de 2 minutos de diferença a favor do Claude Code

O que me chamou atenção não foi o cronômetro, foi o COMPORTAMENTO

O Claude Code fez a etapa de desenvolvimento em poucas idas e vindas, entregando um bloco grande de uma vez, enquanto a outra ferramenta ficou alternando raciocínio e repetindo requisição, o que alongou o processo

E quando o código ficou pronto, a ferramenta partiu sozinha pra subir o servidor e testar o projeto. Ou seja: a execução entra no mesmo ciclo do agente, e a saída dela cai no mesmo lugar que tudo o mais

Quando o servidor de desenvolvimento acusou porta ocupada, eu resolvi rodar o comando por conta própria em vez de deixar a ferramenta executar, justamente pra não gastar token nessa ida e volta

Mesma postura quando a página quebrou ao recarregar: copiei o erro direto do console do navegador e colei de volta na ferramenta, em vez de pedir pra ela investigar sozinha

Ah, e eu autorizo os comandos de execução logo no começo do projeto, pra não ficar aprovando chamada a cada rodada

Sessão longa de tarefa real é exatamente o cenário onde a saída acumulada pesa mais. Não é o prompt grande que te pega, é o vigésimo log de servidor subindo 😀

No vídeo dá pra ver na prática o momento em que a ferramenta sai do código e começa a executar comando, que é onde a saída passa a mandar no tamanho da sessão

O que fazer na próxima vez que for rodar a suíte

A ideia central do post é essa: o token do teste não é cobrado uma vez, ele MORA na janela

Enquanto estiver lá, ele viaja junto em toda requisição seguinte, e você paga transporte

O próximo passo é concreto e verificável, dá pra fazer hoje:

1. rode /context antes da próxima suíte
2. rode a suíte
3. rode /context de novo e compare
4. escolha UMA tática pro comando mais barulhento: limite de saída, hook de filtro ou subagente

Uma só, no comando mais barulhento. Depois você repete pro próximo

Pra fechar com noção de escala: em implantações corporativas o custo médio do Claude Code fica em torno de US$ 13 por desenvolvedor por dia ativo e US$ 150 a 250 por desenvolvedor por mês, com 90% dos usuários abaixo de US$ 30 por dia ativo

Dentro dessa faixa, log que ninguém lê ocupando janela é desperdício puro…

Até o próximo post! =)