Claude Code sem desperdício: economize token em 5 níveis

A Anthropic vem reduzindo os limites de uso do Claude Code ao longo do tempo, e isso muda a forma como vale a pena usar a ferramenta no dia a dia. Quando o limite era generoso, gastar token sem pensar não fazia diferença prática. Agora faz, e bastante. Separei cinco níveis de otimização, do mais simples ao mais avançado, que juntos reduzem muito o consumo sem abrir mão da qualidade das respostas.

Nível 1: auditoria e corte de peso morto

O primeiro passo é entender onde o token está sendo gasto antes de mudar qualquer hábito. Existe um tipo de auditoria pessoal de uso que roda sobre o seu próprio histórico e revela padrões que você provavelmente nem sabia que existiam.

Três coisas aparecem quase sempre nesse tipo de análise. A primeira é o "preload", o tanto de token que é consumido automaticamente só de abrir uma conversa nova, antes mesmo de você escrever qualquer coisa. Esse número pode chegar a dezenas de milhares de tokens sem nenhuma linha de prompt. A segunda é o nível de esforço do modelo configurado mais alto do que precisa, o que gera respostas maiores e mais caras pra tarefas que nem exigiam tanto. A terceira varia de pessoa pra pessoa, são hábitos específicos de cada fluxo de trabalho que acabam custando mais do que deveriam.

A dica mais concreta que saiu dessa auditoria foi olhar pros conectores e MCPs ligados ao Claude Code e remover os que não são usados no dia a dia. Cada conector ativo soma ao preload de toda conversa nova, mesmo quando você não usa ele naquela sessão específica. Depois de limpar os conectores que estavam parados, o preload caiu de uma faixa de 170 a 180 mil tokens pra menos de 70 mil. Se precisar de algum conector removido depois, dá pra reconectar na hora.

Nível 2: cinco hábitos que economizam token

Esses hábitos valem pra qualquer pessoa, independente do tipo de projeto ou do modelo usado.

Use /clear entre tarefas diferentes, não /compact. O /compact tenta resumir o contexto anterior, mas pra fazer esse resumo ele reprocessa tudo, o que gasta token, e o resultado preserva o contexto pior do que parece. O /clear zera a janela de contexto de vez. O modelo começa a tarefa nova "com a cabeça limpa", o que gera respostas melhores e mais baratas.
Use um único modelo por tarefa. Trocar de modelo no meio de uma conversa força o modelo novo a reprocessar todo o histórico anterior pra entender o contexto, o que custa mais token do que economiza. Troca de modelo só deve acontecer depois de um /clear, numa conversa nova.
Evite mensagens picadas. Mandar uma frase por vez faz o modelo reler toda a conversa anterior a cada mensagem nova. Juntar tudo que você quer dizer num prompt único e completo economiza muito mais do que ir completando a ideia aos poucos.
Edite, não corrija. Quando a resposta não é bem o que você queria, em vez de mandar uma mensagem nova corrigindo, o que soma mais uma rodada de reprocessamento em cima do que já foi gerado, use a função de editar a própria mensagem anterior, reescreva o prompt original e reenvie. Isso descarta a resposta errada do histórico em vez de acumular contexto desnecessário em cima dela.
Prefira texto a print ou PDF. Screenshot e PDF custam muito mais token do que copiar e colar o texto relevante direto no prompt. Print ainda é necessário em alguns casos, por exemplo pra mostrar um erro visual que não dá pra descrever em texto, mas deve ser a exceção, não a regra.

Nível 3: peça respostas sem enrolação

Pedir explicitamente pro modelo responder de forma direta, sem parágrafos longos de explicação que você não pediu, reduz o custo porque resposta maior significa mais token gasto no output, além de tomar mais tempo de leitura.

Isso também depende de como o esforço do modelo está configurado. Pra perguntas simples, esforço baixo ou médio já resolve. Esforço máximo gera respostas mais longas e mais caras, e na maioria das tarefas do dia a dia isso é desperdício.

Uma forma de fixar esse padrão é colocar instruções de estilo de comunicação no arquivo de memória do projeto, o CLAUDE.md, explicando como você prefere receber as respostas, direto, sem rodeio. Depois que o modelo aprende esse estilo numa conversa, dá pra pedir pra ele transformar esse padrão de comunicação numa skill reutilizável, pra manter esse tom em qualquer conversa futura sem precisar repetir a instrução.

Nível 4: o modelo certo pra cada tarefa

Usar sempre o modelo mais caro disponível é um dos maiores desperdícios de token que existem. Cada modelo tem um ponto forte.

Haiku é o modelo mais simples e barato, ideal pra tarefa braçal, renomear arquivo, formatar, localizar algo dentro do projeto.
Sonnet é o modelo do dia a dia, versátil, rápido e com ótimo custo-benefício, ideal pra escrever e executar código em tarefas cotidianas, como criar uma página HTML simples ou fazer um ajuste pontual.
Modelos de fronteira, Opus e a família Fable da Anthropic, ficam reservados pra projeto grande e complexo. Opus funciona bem como condutor de projetos longos, decisões que exigem muito contexto acumulado, como construir um sistema completo do zero. Fable funciona bem como arquiteto, focado em revisão de arquitetura, segurança e identificação de bug, o que faz sentido considerando que a família Fable tem histórico ligado a modelos voltados pra cibersegurança.

A troca de modelo deve ser feita pelo comando /model, sempre depois de um /clear numa conversa nova, nunca no meio da mesma tarefa.

Uma dica de segunda opinião barata, depois de construir e revisar algo com os modelos da Anthropic, pedir pro próprio Claude Code chamar a Codex CLI, a ferramenta de linha de comando da OpenAI, pra fazer uma revisão externa adicional usando um modelo forte da OpenAI. Essa segunda revisão encontra bug que os modelos da Anthropic deixaram passar em cerca de 30% dos casos. Vale a pena se você já tem assinatura da OpenAI, mesmo o plano básico.

Outra dica de organização que economiza token e tempo, manter um CLAUDE.md bem estruturado funcionando como um mapa do projeto, indicando onde estão as coisas de design, de arquitetura, de cada parte importante. Isso evita que o modelo precise ler o projeto inteiro linha por linha pra achar uma informação simples, e melhora a qualidade das respostas junto.

Nível 5: transforme o que funciona em skill

Qualquer resultado aprovado, texto, design, estilo de resposta, vale a pena transformar numa skill reutilizável. Isso evita reescrever os mesmos prompts longos repetidamente. E o oposto também importa, limpar e remover skills que não são mais usadas, porque skill acumulada também pesa no contexto carregado em cada conversa nova.

Evitar print continua valendo aqui, reforçando o ponto do nível 2. Ditar ou digitar a explicação em texto é mais barato do que mandar uma captura de tela. Pra quem prefere falar em vez de digitar, apps de transcrição de voz como Whisper Flow ou Handy, esse último gratuito, resolvem bem essa parte.

Preferência de design aprovada, cor, fonte, espaçamento, componente, também vale transformar numa spec ou design system reutilizável, pra não precisar repetir a mesma correção de estilo em cada material novo.

Em projetos mais complexos, um loop de críticos ajuda bastante, uma segunda camada de revisão onde um agente ou modelo revisa o design, outro revisa arquitetura e funcionalidade, comparando o resultado com o que foi combinado originalmente no projeto. Se possível, complementar essa revisão final com outra assinatura de IA que você já tenha, Gemini ou OpenAI, por exemplo, porque erro sempre pode passar despercebido, mesmo depois de múltiplas revisões.

Conclusão

O caminho completo passa por auditoria pessoal, bons hábitos de conversa, pedir resposta objetiva, usar o modelo certo pra cada tarefa, e fechar com um processo de refinamento feito de skill e revisão. O resultado é gastar muito menos token e ainda sair com respostas de melhor qualidade no final.