Você olhou o /cost no meio de uma sessão e levou um susto. Ou chegou na quarta-feira com o limite do Pro estourado, a semana ainda não acabou, e o agente parou de responder.

Não é impressão. Claude Code consome tokens de forma agressiva quando o contexto não é gerenciado, e dá pra cortar 40-60% do gasto sem sacrificar nada na qualidade do código. As técnicas aqui são concretas, testadas, e fazem diferença já na primeira sessão.

Por que o contexto cresce tão rápido

Cada sessão do Claude Code é uma janela de contexto que vai crescendo a cada turno. A primeira mensagem tem só o seu pedido. Mas depois de 20 minutos de trabalho, o contexto inclui o conteúdo de vários arquivos lidos, as respostas anteriores, os outputs de ferramentas, resultados de testes, logs de erro, além de tudo que o agente decidiu carregar automaticamente ao explorar o projeto.

Numa sessão média com um projeto .NET de porte médio, chegar em 100k tokens em meia hora não é exceção. Em sessões exploratórias (o agente lendo vários arquivos pra entender a estrutura antes de qualquer edição), pode ultrapassar 200k.

Cada token custa. No plano Pro (US$20/mês, cerca de R$110-120 dependendo da cotação), a janela de uso se renova a cada 5 horas, mas com sessões pesadas ela vai embora rápido. E na API, os custos escalam: Sonnet 4.6 custa US$3 por milhão de tokens de entrada e US$15 por milhão de saída. Uma sessão descuidada pode custar mais que o esperado.

Mas a maioria dos gastos excessivos tem a mesma causa raiz: contexto mal gerenciado. E isso tem solução técnica.

Técnica 1: CLAUDE.md focado e enxuto

O arquivo CLAUDE.md é lido no início de toda sessão e incluído como contexto em cada mensagem enviada ao agente. Esse detalhe que muita gente não percebe.

Um CLAUDE.md de 5.000 tokens descrevendo toda a arquitetura do projeto, histórico de decisões, configurações de ambiente e preferências pessoais vai custar esses 5.000 tokens multiplicados pelo número de mensagens da sessão. Numa sessão de 40 mensagens, são 200k tokens só de contexto fixo.

A regra prática: mantenha o CLAUDE.md abaixo de 500 tokens. Inclua só o que o agente precisa saber pra tomar decisões corretas na ausência de instrução explícita:

# API de pedidos (.NET 9 + PostgreSQL)

## Stack
- ASP.NET Core Minimal API
- Entity Framework Core + Npgsql
- xUnit para testes

## Convenções
- Nomes de variáveis e métodos em inglês
- Migrations via `dotnet ef migrations add NomeDaMigration`
- Testes em `tests/` (mesmo namespace com sufixo `.Tests`)

## Restrições importantes
- Nunca usar `.Result` ou `.Wait()` em código async
- Não commitar `.env` ou `appsettings.Development.json`

Menos de 300 tokens. Suficiente pra evitar os erros mais custosos de corrigir.

O que não precisa estar no CLAUDE.md: histórico do projeto, motivações de arquitetura, tutoriais internos, preferências de estilo que o agente vai ignorar de qualquer forma. Esses documentos são úteis pra você. Não pra ele.

Técnica 2: /compact e /clear no momento certo

Quando a sessão tá longa e você vai mudar de contexto, não deixe o histórico acumular passivamente.

/compact comprime o histórico da sessão atual num resumo. Mantém o que importa, descarta o volume. É a melhor opção quando você ainda precisa de algum contexto da sessão mas quer cortar o peso antes de continuar.

/clear zera tudo. Começa do zero. Ideal quando a tarefa mudou completamente: terminou de refatorar o módulo de pedidos, vai começar o módulo de notificações.

Na prática: use /compact a cada 30-40 minutos de trabalho contínuo. Antes de iniciar uma tarefa diferente, avalie se /clear faz mais sentido. O custo médio por tarefa cai consideravelmente só com esse hábito.

Só que tem um detalhe: /compact não é mágica. Se você compactar uma sessão onde o agente leu 30 arquivos, o resumo ainda vai conter as informações relevantes desses arquivos. O ganho é real, mas não elimina o contexto, só comprime ele.

Técnica 3: Pedidos cirúrgicos, não exploratórios

Esse é o ponto que mais impacta o custo e que menos gente ajusta no uso do dia a dia.

"Leia o projeto e me diz como melhorar a performance" vai fazer o agente ler dezenas de arquivos antes de responder. Cada arquivo lido entra no contexto e fica lá pelo resto da sessão.

"No arquivo Services/PedidoService.cs, o método ProcessarAsync faz uma query N+1 no EF. Adiciona um .Include() pra resolver" vai fazer o agente ler um arquivo, editar um método, fechar.

A diferença pode ser 10x no consumo de tokens pra um resultado equivalente.

Quanto mais específico o pedido, menos o agente precisa explorar. Dê a ele o arquivo, o método, o problema exato. Não dê o mapa inteiro do projeto esperando que ele encontre a moeda.

Dá pra escrever pedidos vagos e deixar o agente explorar. Em alguns casos faz sentido. Mas quando você sabe o que quer e onde está, pedido vago é gasto desnecessário.

Técnica 4: Escolha o modelo certo pra cada tarefa

No Claude Pro e Max, você escolhe o modelo com /model dentro da sessão. Na API, você passa o parâmetro na chamada.

Regra prática: Sonnet pra 80% das tarefas, Opus quando realmente importa.

O Opus custa cerca de 8x mais tokens de saída que o Sonnet via API. E pra a maioria das tarefas rotineiras de desenvolvimento (refatoração com contexto claro, geração de testes xUnit, ajuste de endpoint, correção de bug com stack trace em mãos) o Sonnet entrega resultado equivalente.

Os casos onde Opus justifica: análise de código legado confuso sem documentação, tarefas que exigem raciocínio multi-step longo com pouca supervisão, arquitetura de sistemas onde erros de julgamento têm custo alto de reverter.

E tem uma nuance que a comunidade BR foi percebendo ao longo de 2025: modelos mais novos não são necessariamente mais econômicos que versões anteriores pra todas as tarefas. Antes de migrar de versão, teste se a qualidade pra sua tarefa específica justifica o custo. O benchmarking aqui paga em real.

Técnica 5: Monitore com /cost antes que vire problema

O comando /cost dentro de qualquer sessão mostra o consumo atual de tokens e o custo estimado. Parece óbvio, mas a maioria dos desenvolvedores só olha quando o limite estoura ou a fatura surpreende.

Olhar o /cost a cada 20-30 minutos cria consciência de consumo. Você começa a perceber padrões: quais tipos de pedido são caros (exploração de código desconhecido, geração de múltiplos arquivos de uma vez, debug sem contexto) e quais são baratos (edição pontual com localização exata).

Monitorando por uma semana você tem dados reais sobre o seu uso. Esses dados valem mais que qualquer regra geral.

A documentação oficial do Claude Code sobre gerenciamento de custos tem detalhes dos planos e como o orçamento funciona por janela de 5 horas. Vale ler antes de escolher entre Pro, Max 5x e Max 20x.

O que não faz tanta diferença (mitos comuns)

Escrever prompts mais curtos não resolve. O tamanho da sua mensagem é uma fração mínima do custo total. O que pesa é o contexto acumulado da sessão, não o seu pedido.

Usar menos ferramentas MCP também não é o ponto. Cada chamada de ferramenta tem um custo fixo pequeno. O custo está no contexto que fica carregado depois da chamada, não na chamada em si.

Sessões mais curtas não economizam automaticamente. Uma sessão de 15 minutos onde o agente leu 50 arquivos pra responder uma pergunta vaga pode custar mais que uma sessão de 2 horas de edições pontuais. A métrica é contexto acumulado, não tempo.

O foco real é: contexto permanente enxuto no CLAUDE.md, pedidos específicos com localização clara, compressão regular do histórico com /compact, e modelo adequado pra cada tipo de tarefa.

Quanto esperar gastar

Pra um desenvolvedor usando Claude Code como ferramenta principal de trabalho:

• Uso moderado (1-2 horas/dia, projetos pequenos): Pro (US$20/mês) cobre bem
• Uso intenso (4+ horas/dia, projetos médios a grandes): Max 5x (US$100/mês) ou API com Sonnet
• Via API com boas práticas: um projeto .NET de porte médio fica entre US$5-20/mês

Sem gerenciamento de contexto, esses números podem triplicar. Com as técnicas acima, ficam dentro do esperado.

Se você tá começando com o Claude Code agora, leia primeiro o que é Claude Code e como ele funciona. As técnicas aqui fazem mais sentido com a base conceitual clara. E se você ainda tá decidindo entre Claude Code e GitHub Copilot, o comparativo direto para devs C#/.NET cobre custo, qualidade e casos de uso de cada ferramenta.

Uma observação honesta: economizar tokens não substitui aprender a usar o agente de forma eficaz. Um desenvolvedor que sabe dar contexto cirúrgico, estruturar tarefas em etapas e reconhecer quando não usar o agente vai gastar consistentemente menos do que quem joga texto solto esperando resultado. Tem muito a ver com não cair nas armadilhas do vibe coding. Os tokens são um sintoma. O hábito é a causa.