O que faz o Claude Code gastar mais tokens em tarefas longas?

Você pede uma coisa boba, tipo renomear uma variável, e vê o gasto subir como se tivesse pedido um refactor inteiro

A parte chata é que isso não é aleatório, e nem é culpa do modelo ter acordado caro naquele dia

O custo do Claude Code escala com o tamanho do contexto: quanto mais contexto ele processa, mais token é consumido. E a maior parte do que infla esse contexto é hábito de uso, não capricho da ferramenta

Neste post eu separo as causas uma a uma (sintoma, o que está por trás e o que fazer) e mostro como reformular o pedido pra chegar no mesmo resultado com bem menos idas e vindas 🙂

Por que o custo cresce sozinho conforme a sessão avança

O sintoma é clássico: no começo da sessão tudo parece barato, e lá pela terceira hora até um "adiciona um log aqui" sai caro

A causa é que a sessão nunca começa vazia

Antes de você digitar qualquer coisa, já entram no contexto o CLAUDE.md, a auto memory, os nomes das ferramentas MCP e as descrições das skills

Depois disso a bola de neve rola sozinha: cada leitura de arquivo soma ao contexto, regras path-scoped carregam junto dos arquivos correspondentes e hooks PostToolUse disparam depois de cada edição

E a auto-compactação, aquela que limpa a bagunça pra você, só entra em ação por volta de 967K tokens por padrão. Ou seja: dá tempo de acumular MUITA coisa que você nem lembra que pediu

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

E o que já está ocupando a janela?

Essa é a pergunta certa, e ela tem comando

/context

Ele mostra o que está ocupando a janela de contexto naquele momento

Rode isso antes de culpar o modelo, beleza? Na maioria das vezes o vilão está listado ali na sua frente

"Mas ele reprocessa a conversa toda a cada mensagem?"

Não, e essa parte é boa notícia

O Claude Code gerencia prompt caching automaticamente, sem você configurar nada. Sem cache, a API reprocessaria o histórico inteiro a cada turno; com cache, ela reusa o que já processou, cobra a releitura na tarifa de token cacheado e processa por inteiro só o que mudou

Na plataforma Claude, a escrita de cache custa 1,25x o preço base de input e a leitura custa 0,1x

Se você conhece cache de aplicação web, a lógica é a mesma: guardar o que não muda sai muito mais barato que refazer

O que não some é o efeito do tamanho: contexto grande continua sendo contexto grande em toda mensagem seguinte

Pedir para o Claude ler o projeto inteiro

Sintoma: você manda um "dá uma olhada no projeto e me diz onde está o problema de autenticação", ele sai lendo arquivo atrás de arquivo, e a conversa fica cara pelo resto da sessão. Não só naquele pedido, no resto TODO

Causa: explorar uma base grande enche o contexto principal com leitura de arquivo, e aquilo fica lá

A doc de boas práticas é direta nisso: escope a investigação de forma estreita ou use subagentes

Por que subagente é mais barato aqui

Cada subagente roda na própria janela de contexto, com system prompt próprio e acesso de ferramentas próprio, e devolve apenas o resultado pra conversa principal

É como mandar um estagiário ler o calhamaço inteiro e voltar com meia página de resumo: o calhamaço fica com ele, o resumo fica com você

A própria doc de custos recomenda delegar a subagente as tarefas de saída verbosa:

• rodar testes
• buscar documentação
• processar arquivos de log

Assim o output ocupa o contexto do subagente e só o resumo volta pra sessão principal

Transforme isso em padrão, não em exceção. Saída longa e chata não precisa morar na sua conversa

Repetir contexto e escrever pedido vago

Sintoma: três, quatro rodadas até ele acertar o que você queria. E cada rodada nova carrega o histórico anterior junto

Causa: instrução imprecisa gera correção, correção gera mais turno, e mais turno é mais token

A doc de boas práticas coloca isso de forma bem simples: quanto mais precisa a instrução, menos correções são necessárias

Na prática, ser específico é:

• referenciar os arquivos específicos que importam
• citar as restrições (o que não pode mudar)
• apontar um padrão de exemplo já existente no projeto pra ele seguir

Parece burocracia, mas é o oposto: você escreve dez palavras a mais uma vez pra não pagar duas rodadas de conserto depois

E o plan mode, entra sempre?

Não. O plan mode é útil, porém adiciona overhead

Em tarefa de escopo claro e correção pequena (corrigir typo, adicionar log, renomear variável) vale pedir direto

A regrinha que eu gosto: se dá pra descrever o diff em uma frase, pule o plano

Guarde o plano pra quando existe incerteza de abordagem, mudança em vários arquivos ou código que você não conhece. Aí ele paga o próprio custo com folga

Tem tarefa que nem plano nem agente resolvem melhor que a sua mão, e vale saber quando fazer na mão sai mais rápido antes de abrir a sessão

Deixar a sessão acumular tentativas falhas

Sintoma: a conversa virou um museu de tentativas que não deram certo, e todo prompt novo paga ingresso pra visitar o museu

Causa: contexto velho desperdiça tokens em toda mensagem seguinte. Aquela abordagem que você abandonou há uma hora continua lá, ocupando espaço

Inclusive, gasto inesperadamente alto em plano de API ou cloud provider normalmente vem de duas coisas: sessão longa que nunca foi limpa e Opus deixado como modelo padrão

Os comandos que resolvem

/clear
/compact
/compact focus on the auth bug fix
/rewind

Como escolher:

• /clear quando você troca pra um trabalho não relacionado. Começa do zero mesmo
• /compact quando você ainda precisa do fio da meada: ele resume a conversa pra liberar espaço, e aceita instrução junto (do tipo focar no bug de auth) pra ele saber o que preservar
• /rewind, ou Esc pressionado duas vezes, abre o menu de rewind: dá pra restaurar só a conversa, só o código, os dois, ou resumir a partir de uma mensagem selecionada

Tome cuidado com o medo de limpar, que é o que trava a maioria das pessoas

A doc indica usar /rename antes de limpar e /resume pra voltar depois. Ou seja, limpar não é queimar ponte

Bônus: limpar reconstrói o cache

O cache é invalidado quando o conjunto de definições de ferramentas muda entre turnos, e a causa mais comum disso é um servidor MCP conectando ou desconectando no meio da sessão

/clear e /compact resetam essa situação porque reconstroem o cache naquele ponto

Então se um MCP caiu e voltou no meio do caminho, compactar não é só arrumação, é economia

Modelo caro no padrão e thinking no talo

Sintoma: gasto alto até em tarefa trivial, daquelas que qualquer modelo resolveria

Causa dupla:

1. Opus deixado como modelo padrão pra tudo
2. tokens de extended thinking, que são cobrados como tokens de output, com budget padrão que pode chegar a dezenas de milhares de tokens por requisição dependendo do modelo

Em tarefa simples, isso é raciocínio caro sendo gasto pra decidir onde colocar uma vírgula

Em tarefas simples dá pra reduzir o custo assim:

• baixar o nível de esforço com /effort ou dentro do /model
• desabilitar thinking no /config
• reduzir o budget com a variável de ambiente MAX_THINKING_TOKENS

O objetivo não é rodar tudo no barato, é reservar modelo forte e esforço alto pro problema que realmente exige

Pra quem está no plano de assinatura e quer esticar o limite, tem um caminho complementar de como fazer o plano render mais que combina bem com o que está aqui

Como reformular um pedido caro em um pedido barato

Rotina curta, pra rodar quando a sessão começa a pesar:

1. Abra o /context e veja o que já está ocupando a janela. O erro comum aqui é pular esse passo e sair compactando no escuro, sem saber se o peso vem do histórico, das leituras de arquivo ou das ferramentas carregadas

2. Decida entre compactar e limpar. Se você continua no mesmo assunto, /compact focus on the auth bug fix mantém o fio; se mudou de assunto, /clear é o certo. O erro comum é usar /clear no meio de um problema que você ainda não resolveu e jogar fora o raciocínio bom junto com o lixo. Rode /rename antes de limpar e depois você volta com /resume

3. Reescreva o pedido apontando arquivos e restrições em vez de descrever o objetivo de forma ampla. O erro comum é achar que "deixar em aberto" dá liberdade pro modelo: na prática dá é rodada de correção, e cada correção carrega o histórico inteiro junto

4. Delegue leitura ampla e saída verbosa a subagente. Teste, busca em documentação e processamento de log vão pra janela dele, e só o resumo volta. O erro comum é delegar depois de já ter enchido o contexto principal com as leituras: aí o estrago já está feito

5. Acompanhe com /usage ou configure a status line pra exibir o uso continuamente. O erro comum é levar o número ao pé da letra na hora de conferir a fatura: por padrão o Claude Code calcula os valores que mostra a preço de tabela (list price), então quem tem tarifa contratada vê números que não batem com o que é cobrado

E se você prefere compactar antes do padrão em vez de esperar os 967K, existe o /autocompact:

/autocompact 500k
/autocompact auto

Dá pra fazer o mesmo passando a flag --autocompact ao iniciar, ou definindo a variável CLAUDE_CODE_AUTO_COMPACT_WINDOW. Ele aceita de 100K a 1M tokens e vale pra sessão atual e pras seguintes

Quando vale deixar o contexto acumular

Agora o outro lado, porque sair cortando tudo também é jeito de perder tempo (e token) 😀

A própria doc de boas práticas avisa que esses padrões não são regra fixa: às vezes vale deixar o contexto acumular porque você está fundo em um problema complexo e o histórico é valioso

Se as dez últimas mensagens são exatamente o que impede o modelo de repetir um caminho que já falhou, jogar fora é pagar duas vezes pela mesma descoberta

Sessão longa em base de código grande também tem folga: os modelos recentes suportam janela de contexto de 1 milhão de tokens justamente pra isso

As heurísticas são ponto de partida, não lei. Quem decide é você olhando pro /context, não o post 🙂

O que apareceu no painel quando testei na prática

Essa parte foi a que mais me pegou de surpresa

No vídeo eu monto um roteamento de modelos por complexidade e faço um teste de propósito bobo: dois pedidos, só isso

Um pedindo a estrutura do projeto em árvore, outro pedindo um README curto com título e duas linhas de descrição

Duas execuções minhas, certo? Pois é, o painel contabilizou 16 mensagens depois desses dois prompts

O custo total ficou abaixo de um centavo de dólar, e o painel apontou 4 dólares de economia naquele teste

Se liga no que isso significa: uma mensagem sua não é uma chamada de modelo

O agente conversa consigo mesmo, raciocina, lê, tenta, volta. Você conta 2, a conta conta 16

É exatamente por isso que o gasto foge da percepção: a gente estima pelo número de coisas que digitou, e a cobrança acontece num lugar que a gente não vê

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

No vídeo acima você vê a coisa acontecendo na tela: a configuração (que é a parte chatinha, com login, autorização e colagem de chave), os dois pedidos simples e o painel contando as interações que eu não pedi diretamente

Conclusão

O resumo do resumo: o gasto acompanha o contexto, e o contexto acompanha os seus hábitos

A maior parte do desperdício não vem do modelo estar caro, vem de pedir leitura ampla quando bastava apontar dois arquivos, de escrever pedido vago que gera rodada de correção, e de arrastar tentativa falha por horas dentro da mesma sessão

Próximo passo, bem prático, pra próxima sessão longa:

1. rode /context antes de reclamar do gasto
2. decida entre /compact com foco no assunto atual e /clear pra trabalho não relacionado
3. reescreva o próximo pedido apontando arquivos e restrições, em vez de pedir leitura ampla

Faça o teste na próxima tarefa longa e compare com o /usage, é o tipo de coisa que a gente só acredita vendo

até o próximo post! 😀