Dicas Práticas para Economizar Tokens no Claude Code CLI

O Claude Code cobra por token — cada rodada de busca evitada, cada contexto que não precisa ser carregado, se traduz diretamente em custo. Este post cobre as principais alavancas disponíveis, de hábitos rápidos de escrita de prompts a decisões mais profundas de arquitetura de sessão.

Os Dois Eixos de Economia de Tokens #

Há duas dimensões independentes a considerar:

• Dentro de uma sessão — quanto contexto acumula enquanto você trabalha
• Entre sessões — quanto re-explicação e re-exploração acontece cada vez que você começa do zero

Cada uma tem suas próprias ferramentas.

Economizando Tokens Dentro de uma Sessão #

Seja específico desde o início #

Prompts vagos forçam o Claude a explorar antes de agir. Dizer “olhe src/auth/middleware.ts” é mais barato do que “encontre o middleware de autenticação” — o segundo dispara rodadas de Glob e Grep antes de qualquer trabalho real começar. Aponte para arquivos diretamente sempre que puder.

Use /compact #

/compact comprime a conversa no lugar pedindo ao Claude (o próprio modelo) que a resuma. Não é um algoritmo determinístico — o Claude decide o que vale manter com base na relevância para a tarefa. A chamada de sumarização em si consome tokens, então /compact é uma troca: você paga um custo pequeno agora para evitar um custo acumulado maior depois.

Tende a reter:

• Estado atual da tarefa e onde você está nela
• Decisões-chave tomadas
• Caminhos de arquivos e símbolos referenciados ou editados
• Erros encontrados e como foram resolvidos
• Instruções explícitas e preferências que você declarou

Tende a descartar:

• Trocas exploratórias que não levaram a lugar nenhum
• Explicações repetidas da mesma coisa
• Tangentes resolvidas e resultados de chamadas de ferramentas já utilizados

Dica: quanto mais limpa e focada for sua sessão, melhor o resumo do compact. Uma sessão cheia de mudanças de direção produz um resultado mais vago.

Use /clear entre tarefas não relacionadas #

Se você está mudando para uma tarefa completamente diferente, /clear é mais barato do que carregar todo o contexto anterior. Cada turno em uma sessão longa paga por tudo que veio antes.

Escolha o modelo certo para a tarefa #

Modelos da classe Haiku são significativamente mais baratos por token do que Sonnet ou Opus. Use-os para tarefas mecânicas — renomear, formatar, gerar boilerplate — e reserve os modelos mais pesados para trabalho que exige raciocínio. Consulte a documentação de modelos da Anthropic para o ID atual do modelo Haiku, pois esses mudam a cada geração.

Use --print para tarefas únicas #

--print (abreviação -p) roda o Claude Code em modo não-interativo: ele processa seu prompt e encerra, imprimindo a resposta no stdout. Nenhuma sessão é aberta.

claude --print "resuma este arquivo" < arquivo.txt
claude -p "o que esta função faz?" < src/auth.ts

A economia de tokens vem de dois lugares: não há inicialização de sessão (sem carregamento de memória, sem inicialização de contexto do projeto) e o modelo vê apenas seu prompt e a entrada redirecionada — nada mais. Para pipelines scriptados, Makefiles ou etapas de CI, esta é a opção mais enxuta. Para qualquer coisa que precise de ida e volta, use a sessão interativa.

Economizando Tokens Entre Sessões #

Como a memória funciona #

O Claude Code tem um sistema de memória baseado em arquivos em ~/.claude/memory/. Ele tem duas camadas:

• MEMORY.md — o arquivo de índice, sempre carregado no início de cada sessão. Uma linha por arquivo de memória, mantido conciso.
• Arquivos de memória individuais — carregados sob demanda. O Claude lê o índice, julga quais arquivos são relevantes para a tarefa atual e busca apenas esses.

Isso significa que ter muitas memórias não sobrecarrega cada sessão. Uma memória sobre PostgreSQL não será carregada se você estiver perguntando sobre CSS — a menos que o Claude julgue relevante. A descrição de uma linha no MEMORY.md é o que impulsiona essa decisão de relevância, então descrições vagas levam a memórias que passam despercebidas.

Salve contexto antes de limpar #

O padrão “salvar + limpar” é o mais próximo de uma remoção seletiva de contexto:

1. Diga ao Claude o que salvar — seja explícito:
   “Salve na memória: decidimos usar PostgreSQL para o armazenamento de sessão, e o middleware de autenticação fica em src/auth/middleware.ts.”
2. Execute /clear para limpar a conversa. Os arquivos de memória permanecem intocados.
3. Comece seu próximo turno normalmente. O Claude carrega o índice e puxa as memórias relevantes.

O contexto salvo sobrevive. O assunto indesejado não volta.

Isso é o que o /compact faz automaticamente — mas sem qualquer seletividade. O padrão salvar + limpar dá a você controle total sobre o que sobrevive para a próxima janela de contexto.

Torne as descrições de memória específicas #

Como as entradas do MEMORY.md impulsionam as decisões de relevância, escreva-as de forma que possam ser encontradas:

“Decidiu usar PostgreSQL para armazenamento de sessão” ✓
“Algumas decisões de backend” ✗

Você também pode acionar um carregamento de memória explicitamente referenciando o tópico em sua primeira mensagem: “continuando o trabalho no sistema de autenticação” sinaliza ao Claude para puxar memórias relacionadas à autenticação antes de você perguntar qualquer coisa específica.

Arquitetura de Sessão: Por Pasta vs. Sandbox Compartilhado #

Uma pergunta comum de fluxo de trabalho: você deve abrir uma sessão Claude separada por pasta de projeto, ou trabalhar a partir de um sandbox pai contendo múltiplos repositórios?

O que você ganha com sessões por pasta #

Isolamento de memória. Cada projeto tem seu próprio índice MEMORY.md e pool de memória. Nenhum contexto vaza entre repositórios não relacionados.

Busca de arquivos com escopo. Glob e Grep rodam a partir da raiz do projeto. “Encontre o middleware de autenticação” acerta uma base de código, não três. Menos desperdício de tokens em desambiguação.

Configurações por projeto. .claude/settings.json aplica-se apenas a essa pasta. Diferentes repositórios podem ter diferentes permissões, comandos permitidos e hooks.

Resumos /compact mais limpos. O resumo reflete apenas o trabalho do projeto atual — sem ruído de repositórios irmãos.

O que você abre mão #

Tarefas entre repositórios exigem troca de sessão. Há atrito em abrir e fechar sessões conforme você se move entre projetos.

A troca na prática #

Para repositórios não relacionados, por pasta é estritamente mais limpo. Para repositórios fortemente relacionados onde você frequentemente alterna entre eles, um sandbox compartilhado troca isolamento por conveniência — uma escolha razoável.

Você pode trocar de pasta no meio de uma sessão e obter comportamento por pasta? #

Ainda não. Quando uma sessão do Claude Code começa, o diretório de trabalho ancora a identidade do projeto — pool de memória, índice e configurações estão todos vinculados ao caminho de lançamento. Não há um comando /switch-project que recarregue esses elementos para uma pasta diferente no meio de uma sessão.

O que funciona parcialmente:

• Arquivos CLAUDE.md por repositório — o Claude os lê quando navega para uma subpasta, então instruções específicas do projeto entram em vigor contextualmente
• Escopo explícito do trabalho do Claude: “trabalhe em ./repo-b/ a partir daqui”

O que não funciona:

• A memória não troca — memórias do repo-b não carregam automaticamente
• As configurações não mudam — hooks e permissões permanecem como no lançamento

Se o isolamento por pasta é importante, sessões separadas permanecem a opção mais limpa.

Referência Rápida #

A eficiência de tokens no Claude Code é principalmente sobre reduzir trabalho redundante — buscas que poderiam ser evitadas, contexto que não precisa ser carregado, re-explicações que uma memória poderia substituir. As ferramentas estão todas lá; é principalmente uma questão de construir o hábito de usá-las no momento certo.