Claude Code consome muitos tokens: como reduzir custos

Claude Code consome muitos tokens quando um loop relê contexto, executa ferramentas e verifica resultados por vários turnos. Eu vou te mostrar como cortar esse desperdício sem mandar o Claude Code parar de testar. Quando gravei este vídeo, eu estava otimizando uma meta de Lighthouse (performance de um site) e vi como uma automação aparentemente simples pode virar uma conta bem salgada.

Sumário

• Por que Claude Code consome muitos tokens em loops?
• Como definir um critério de parada no Claude Code?
• Como reduzir o contexto que o Claude Code relê?
• Qual modelo usar para gastar menos tokens no Claude Code?
• Qual modelo usar para gastar menos tokens no Claude Code?
• Controle de loop é controle de custo
• Perguntas frequentes

Por que Claude Code consome muitos tokens em loops?

Claude Code consome muitos tokens em tarefas iterativas porque cada nova tentativa pode processar novamente contexto, arquivos, resultados de testes, logs e diffs. O custo não está só no código que o Claude Code escreve. O custo cresce principalmente quando o Claude Code precisa ler evidências para decidir se continua, corrige ou encerra a tarefa.

Na minha máquina, eu pedi uma meta simples: melhorar a nota do Lighthouse da página inicial. A tela devolveu uma boa nota logo no começo, mas a versão mobile ainda ficou abaixo do alvo. A partir daí, cada tentativa passou a olhar o relatório, alterar algo, rodar a medição e ler a nova saída. Parece um ciclo inocente. Não é.

Pensa numa pessoa revisando uma planilha. Escrever uma célula leva segundos. Conferir cem linhas, fórmulas e abas para saber se aquela célula não quebrou nada leva muito mais tempo. Com agentes, a moeda desse trabalho de conferência são tokens de entrada.

Isso não prova que o Claude Code leu só código. Esses tokens incluem contexto, instruções, logs, resultados de ferramentas e diffs. Mas deixa uma lição bem clara: mandar o Claude Code “tentar de novo” sem desenhar o ciclo é um jeito eficiente de comprar leitura repetida. Então, o que exatamente precisa existir dentro de um loop para ele não virar uma torneira aberta?

Como definir um critério de parada no Claude Code?

Engenharia de loop é o desenho deliberado de ciclos de agentes, com tarefa, contexto, ferramentas, verificação e regras para continuar ou encerrar. Um loop agente funciona como um entregador: recebe um endereço, faz uma ação, olha o comprovante e decide se volta para buscar outra encomenda. Sem endereço e sem horário de fechamento, o entregador fica rodando pela cidade.

Eu gosto de reduzir o desenho a três peças. O gerador altera o código ou coleta informação. O verificador mede o resultado. O critério de parada decide se o trabalho acabou. Se qualquer peça estiver vaga, o Claude Code tende a compensar a incerteza buscando mais contexto e fazendo mais turnos.

"Loop sem critério objetivo não é autonomia. É uma conta sem teto." — Anwar Hermuche

No teste do Lighthouse, “deixe o site bom” seria uma instrução ruim. Bom para mim não é necessariamente bom para você. Eu troquei a opinião por uma régua: uma nota de performance definida no relatório. Compilação sem erros, testes passando, fila vazia e métrica acima de um limiar seguem a mesma lógica.

A documentação do Claude Code explica que o comando /goal mantém a sessão trabalhando até uma condição ser confirmada. Depois de cada turno, um avaliador rápido e separado julga a evidência que apareceu na conversa. Esse avaliador não usa ferramentas. Por isso, eu não confio em uma frase subjetiva como “o código está perfeito”. Eu peço que o Claude Code rode o teste e traga o resultado.

Um detalhe chato, mas importante: escrever “pare depois de cinco tentativas” no texto não cria um teto nativo garantido para /goal. O comando fica ativo até a condição ser confirmada ou até você executar a limpeza explícita. Para custo de verdade, eu uso controle externo. Mas qual controle segura um loop quando a meta continua distante?

Como reduzir o contexto que o Claude Code relê?

Claude Code consome muitos tokens sem um orçamento operacional porque uma condição difícil pode manter a sessão ativa e ampliar o contexto a cada turno. Eu controlo esse risco com escopo pequeno, timeout, orçamento máximo, acompanhamento de /usage e cancelamento explícito. O teste define sucesso; os limites definem até onde vale pagar para buscar esse sucesso.

Eu não começaria uma mudança gigante pedindo que o Claude Code “melhore o sistema inteiro”. Eu escolheria um componente, um comando de teste e uma alteração reversível. Se o piloto gastar mais do que entrega, eu paro ali. É muito menos dolorido cancelar um experimento pequeno do que descobrir uma semana depois que uma rotina ficou mastigando logs sem fim.

No caso do Bun, cerca de 50 dynamic workflows rodaram por 11 dias, segundo o Bun Blog em 2026. O pico chegou a cerca de 64 instâncias do Claude em paralelo. O custo aproximado, em preços de API, foi de US$ 165 mil em 2026. Eu não uso esse número para fazer terrorismo. Eu uso para lembrar que paralelismo multiplica capacidade e também multiplica consumo.

Dynamic workflow é o recurso do Claude Code que planeja, divide e orquestra subtarefas com subagentes paralelos e checagens. A Anthropic recomenda começar com escopo limitado porque dynamic workflows podem gastar substancialmente mais tokens que uma sessão típica. Eu concordo totalmente. Abrir dezenas de agentes antes de saber se o teste está bem definido é ruim. Você ganha velocidade para chegar mais rápido na direção errada.

Eu configuro o trabalho nesta ordem:

1. Escolho uma alteração pequena e reversível.
2. Defino um comando de build, teste, lint ou métrica como evidência.
3. Estabeleço timeout e orçamento fora do prompt.
4. Acompanho /usage durante o piloto.
5. Cancelo o loop quando o custo marginal superar o ganho.

Com o teto operacional definido, sobra outra fonte clássica de desperdício: pedir contexto demais antes de cada ação. Como eu reduzo essa bagagem?

Qual modelo usar para gastar menos tokens no Claude Code?

Para reduzir o contexto que o Claude Code relê, eu separo tarefas não relacionadas, mantenho CLAUDE.md curto, uso compactação e carrego instruções especializadas apenas quando preciso. Contexto é como uma mochila. Se eu coloco manual, histórico de bug, documentação antiga e três projetos dentro dela para consertar um botão, o Claude Code paga para carregar tudo em cada percurso.

Eu já vi o problema aparecer quando uma conversa começava tratando um erro de interface e terminava discutindo arquitetura, testes e dependências. O Claude Code continuava com material útil, mas também com muita sobra. Eu prefiro encerrar a sessão e abrir uma tarefa limpa quando o assunto mudou. Dá um pouco mais de trabalho manual. Gasta bem menos contexto inútil.

Prompt caching ajuda quando um prefixo de contexto se repete, porque reaproveita partes da entrada e reduz custo e latência em relação ao reprocessamento integral. Mesmo assim, caching não é licença para despejar repositório inteiro no prompt. Arquivos novos, logs novos, resultados de ferramentas e diffs ainda entram na conta.

Eu também tiro instruções muito específicas do CLAUDE.md e deixo esse arquivo com regras realmente universais do repositório. Instruções de um domínio ou fluxo particular ficam em Skills carregadas sob demanda. A documentação do Claude Code recomenda exatamente essa separação para manter o contexto menor.

No meu teste, a rotina agendada ainda falhou porque a API pública de medição atingiu a cota diária. A tela mostrou o motivo sem enrolação. Foi um bom lembrete: repetir uma checagem sem nova informação não é monitoramento inteligente. É polling caro.

Quando existe um evento confiável, como um evento do GitHub ou uma chamada de API, eu prefiro disparar a automação na mudança real. E, quando preciso de volume, a escolha de modelo entra como próxima alavanca. Qual modelo merece cada parte do loop?

Qual modelo usar para gastar menos tokens no Claude Code?

Modelos menores reduzem o custo do Claude Code quando executam tarefas repetitivas, bem delimitadas e verificadas por regras mecânicas. Eu reservo modelos mais capazes para planejamento, decisões de arquitetura e revisão de alto risco. Usar o modelo mais caro para classificar arquivos ou aplicar uma mudança padronizada é como chamar um cirurgião para colar uma etiqueta.

No caso Bun, a revisão não ficou nas mãos do mesmo agente que implementava. Um agente fazia a mudança e dois ou mais revisores independentes procuravam razões para ela estar errada. Essa estratégia se chama revisão adversarial. O objetivo não é concordar com o código. O objetivo é encontrar regressão, exceção e quebra escondida.

Eu gosto dessa separação porque o implementador tende a defender o caminho que acabou de construir. Um revisor com contexto separado olha o diff com outra pergunta: “onde isso falha?”. Só que eu não espalharia revisores caros em toda tarefa. Eu colocaria a revisão forte nos pontos que mudam regra de negócio, segurança, migração ou dados críticos.

A Anthropic recomenda deixar implementação de grande volume com modelos menores e guardar modelos mais capazes para revisão e para regras que orientarão outros agentes. A parte decisiva é ter um árbitro mecânico. Compilador, suíte de testes, lint e diff verificável vencem a impressão subjetiva do modelo.

A tabela resume como eu distribuo esse trabalho:

Controle de loop é controle de custo

Claude Code entrega muito quando recebe um problema fechado, um teste que decide e um limite que protege seu bolso. Eu não tento fazer o Claude Code trabalhar menos. Eu faço o Claude Code trabalhar com evidência e com escopo. Comece hoje por uma tarefa pequena do seu repositório, defina o comando de teste, estipule o orçamento e acompanhe o uso antes de ampliar o loop. Se você quer aprender a desenhar agentes, automações e produtos de IA sem cair em promessa vazia, entra na DascIA. Eu ensino desde o uso prático no trabalho até a formação completa em engenharia de IA.

Perguntas frequentes

Por que o Claude Code gasta tantos tokens lendo código?

O Claude Code gasta muitos tokens lendo código porque cada turno processa instruções, arquivos, diffs, logs e resultados de ferramentas antes de decidir a próxima ação. Em tarefas iterativas, esse contexto retorna várias vezes. Prompt caching reduz parte do custo, mas não elimina novas leituras nem novas saídas.

Como limitar o custo de uma meta no Claude Code?

Para limitar o custo de uma meta no Claude Code, defina um teste objetivo, um timeout externo, um orçamento de uso e monitoramento contínuo. O comando de meta continua ativo até a condição ser confirmada ou você o limpar. Um limite escrito somente no prompt não é um teto garantido.

O comando goal verifica testes sozinho?

O comando goal usa um avaliador rápido separado para decidir se a condição foi atendida, mas esse avaliador não chama ferramentas. Por isso, o Claude Code precisa trazer para a conversa a evidência de build, lint, teste ou métrica. Critérios baseados em comandos reproduzíveis são mais confiáveis.

Usar modelo menor no Claude Code reduz custo?

Usar modelo menor no Claude Code reduz custo quando a tarefa é repetitiva, volumosa e tem verificação mecânica. Eu deixo modelos mais capazes para planejamento, regras de arquitetura e revisão de alto risco. Implementação padronizada, classificação e triagem costumam caber em modelos menores.