Otimização de Custos do Claude Code: Preços, Caching e Gestão de Tokens

Vamos falar de dinheiro. O Claude Code pode ficar caro depressa — ou custar menos que o seu café diário. A diferença está num punhado de decisões que toma uma vez e uns poucos hábitos que constrói ao longo do tempo.

Os 10% melhores setups na nossa análise (pontuação 8+/10) gastam cerca de 8$/dia em Claude Code. Os seus ganhos de produtividade superam largamente o custo, mas chegam lá percebendo para onde vão os tokens e como desperdiçar menos.

Eis o que eles sabem e você provavelmente ainda não.

As duas opções de preço (e como escolher)

O Claude Code oferece dois modelos de faturação. Escolher o errado é o erro de custos mais comum que vemos.

Plano Max: tarifa mensal fixa

• Max 5x (100$/mês) — cerca de 2-3 horas de sessões ativas por dia
• Max 20x (200$/mês) — para quem programa com o Claude a maior parte do dia

Se usa o Claude Code todos os dias úteis durante 2+ horas, o plano Max poupa-lhe dinheiro face ao pagamento por token. E as faturas são previsíveis — sem surpresas no fim do mês.

Preços API: pague o que usa

Uma sessão típica gera 50.000-200.000 tokens por hora. Com tarifas Sonnet:

• Sessão ligeira (perguntas rápidas, edições pequenas): ~0.30$/hora
• Sessão média (trabalho em features, alterações multi-ficheiro): ~0.90$/hora
• Sessão intensa (grandes refactorings, muita leitura de ficheiros): ~2.25$/hora

Com Opus, multiplique por 5. Uma sessão Opus intensa custa cerca de 11.25$/hora. Por isso a escolha do modelo importa tanto (voltamos a isso já a seguir).

As contas do ponto de equilíbrio

A intensidade média com Sonnet (~0.90$/hora):

• Max 5x (100$/mês) atinge equilíbrio a ~111 horas/mês, cerca de ~5.5 horas/dia útil
• Max 20x (200$/mês) a ~222 horas/mês

Para a maioria dos utilizadores diários, Max 5x é o ponto ideal. Se usa o Claude Code apenas algumas vezes por semana, os preços API são mais baratos.

Para onde vão realmente os seus tokens

Não se pode otimizar o que não se compreende. Eis a distribuição de uma sessão típica:

Duas coisas saltam à vista: a leitura de ficheiros e o histórico de conversação dominam. São os dois pontos onde a otimização tem maior impacto.

O truque /compact (reduza o consumo de tokens drasticamente)

Um comando que a maioria não conhece: /compact.

Quando a sua sessão se alonga — 15+ turnos, muito vai e vem — o histórico de conversação incha. Cada nova mensagem inclui todo o histórico anterior. Os seus tokens acumulam-se.

/compact resume a conversação numa representação mais curta. Após compactar:

• Os turnos seguintes custam menos (menos histórico para enviar)
• As respostas chegam mais rápido (menos para o Claude processar)
• Evita atingir o limite da janela de contexto

Quando compactar

• A sessão já leva 15+ turnos
• O Claude começa a repetir coisas que já lhe disse
• As respostas ficam visivelmente mais lentas
• Está a mudar para uma tarefa diferente na mesma sessão

Quando NÃO compactar

• Está no meio de uma operação multi-passo que requer memória precisa
• O Claude precisa de referir código específico de 2-3 turnos atrás
• Está prestes a fazer commit — compacte DEPOIS do commit, não antes

Compact vs nova sessão

Às vezes recomeçar do zero é melhor que compactar:

A minha regra: Mudar de tarefa? Nova sessão. Mesma tarefa mas já leva muito tempo? Compact. E sempre fazer commit antes de qualquer um dos dois — o git preserva os detalhes que a compactação perde.

Opus vs Sonnet: a questão do 5x

O Opus custa 5x mais que o Sonnet por token. Vale a pena? Às vezes. Eis como decidir.

Sonnet (predefinido) para a maior parte do trabalho

O Sonnet lida bem com a vasta maioria das tarefas de desenvolvimento:

• Escrever funções e componentes
• Corrigir bugs diretos
• Executar testes e interpretar resultados
• Explorar e pesquisar ficheiros
• Refactoring com instruções claras
• Rever código

Isto cobre provavelmente 90% do que faz num dia.

Opus para as coisas difíceis

O Opus justifica o seu preço em situações específicas:

• Decisões de arquitetura — conceber sistemas com múltiplos componentes que interagem
• Diagnóstico de bugs subtis — bugs que cruzam múltiplos caminhos de código e camadas de abstração
• Grandes refactorings — alterações em muitos ficheiros que precisam de consistência
• Resolução de problemas novos — tarefas onde a resposta não é um padrão standard

O workflow híbrido

A abordagem que funciona melhor: Sonnet por defeito, Opus quando precisa de potência extra.

# Trabalho diário (Sonnet)
claude

# Problema difícil (Opus)
claude --model opus

# Ou mudar durante a sessão
> /model opus

Alguns programadores vão mais longe — Opus para planear, Sonnet para executar:

1. Começar com Opus: "Planeia a arquitetura do sistema de notificações"
2. Rever o plano, ajustá-lo
3. Mudar para Sonnet: "Implementa o plano que discutimos"

Pensamento de qualidade Opus nas decisões difíceis, velocidade de execução Sonnet na implementação. O melhor dos dois mundos.

Quatro hábitos que mantêm os custos baixos

1. Sessões focadas (a maior poupança individual)

Em vez de uma sessão maratona que acumula contexto durante horas:

Sessão 1: "Adicionar migração de BD para notificações"
  → Concluir, commit, fechar

Sessão 2: "Implementar endpoints API"
  → Concluir, commit, fechar

Sessão 3: "Construir a UI de notificação"
  → Concluir, commit, fechar

Cada sessão começa limpa com eficiência total de cache. Sem contexto irrelevante de tarefas anteriores a pesar em cada turno.

2. Aponte o Claude para ficheiros específicos

Cada ficheiro que o Claude lê custa tokens. Um ficheiro de 500 linhas são cerca de 500 tokens de entrada. Ler 50 ficheiros numa sessão de exploração adiciona 25.000 tokens — cerca de 0.08$ em Sonnet mas 0.38$ em Opus.

Ajude o Claude a ler menos:

• "Vê as linhas 45-80 de src/api/route.ts" em vez de "lê o ficheiro route"
• Aponte para ficheiros específicos em vez de deixar o Claude pesquisar amplamente
• Mantenha a documentação de arquitetura atualizada para que o Claude não precise de explorar

3. Mova rules para fora do CLAUDE.md

Subtil mas acumula-se. Cada linha do CLAUDE.md é carregada em cada turno. As rules em .claude/rules/ só quando os seus padrões glob correspondem.

200 linhas de convenções frontend, 150 de regras backend e 100 de padrões de BD no CLAUDE.md? O Claude carrega todas as 450 linhas em cada turno — mesmo quando só edita um ficheiro CSS.

Mova instruções específicas de ficheiros para ficheiros de rules. O CLAUDE.md fica leve (20-30 linhas de essenciais do projeto), e poupa ~100 linhas de tokens na maioria dos turnos.

4. Faça commit antes de compactar

Padrão dos nossos melhores setups. Sempre commit antes de /compact ou de fechar sessão.

1. Concluir a unidade de trabalho atual
2. git add + git commit
3. /compact (ou nova sessão)
4. Continuar com a próxima unidade

A compactação perde detalhes. O git preserva-os. Se precisar de retomar uma tarefa mais tarde, a mensagem de commit e o diff são muito mais fiáveis do que um resumo compactado.

Números de custos reais

O que custam diferentes perfis de utilização, com base em setups analisados:

A média de 8$/dia dos melhores setups dá ~160-180$/mês — perto do plano Max 20x. São utilizadores intensivos que trabalham com o Claude Code como ferramenta principal.

Monitorizar os gastos

No plano Max

A Anthropic oferece dashboards de utilização. Verificar semanalmente. Sempre no limite? Tier mais alto. Mal usa metade? Tier mais baixo ou API.

Nos preços API

Configurar alertas:

1. Settings > Billing > Alerts na consola Anthropic
2. Alerta diário (ex. 15$/dia)
3. Teto orçamental mensal

Para automatização CI/CD, limitar turnos contra custos descontrolados:

claude -p "Revê este PR" --max-turns 10 --output-format json

Próximos passos

A otimização de custos não é coisa de uma vez. As estratégias aqui — escolha de modelo, sessões focadas, /compact, rules em vez de CLAUDE.md inchado — acumulam-se com o tempo. Um programador que aplica todas gasta 40-60% menos do que alguém que usa o Claude Code com as predefinições.

Para as bases sobre as quais estas estratégias assentam:

• Configurar o projeto corretamente — um bom CLAUDE.md reduz tokens desperdiçados em mal-entendidos
• Usar rules em vez de inchar o CLAUDE.md — rules com alcance por caminho poupam tokens em cada turno
• Analise o seu setup para ver que otimizações teriam maior impacto

Perguntas frequentes

Vale a pena o plano Max se uso o Claude Code apenas 3-4 dias por semana?

Depende da intensidade. Se esses 3-4 dias envolvem 4+ horas cada, Max 5x a 100$/mês é provavelmente mais barato que API. Se são 1-2 horas nesses dias, a API ganha. Registe o seu consumo durante um mês na API, multiplique pelas tarifas e compare.

O prompt caching funciona automaticamente?

Sim. Não precisa de configurar nada. A API reconhece quando pedidos consecutivos partilham o mesmo prefixo (system prompt, CLAUDE.md, rules carregadas) e cobra 90% menos pela porção em cache. Pode ajudar o caching mantendo o CLAUDE.md estável durante uma sessão — cada edição invalida o cache e força uma releitura ao preço total.

Quando usar /compact vs nova sessão?

Menos de 10 turnos e mesma tarefa: continuar. 15-20 turnos e mesma tarefa: compactar. Mudança de tarefa: nova sessão. Se o Claude começa a "esquecer" coisas de antes na conversa, é um sinal forte para compactar ou recomeçar.

Posso usar Sonnet para tudo e ignorar o Opus?

Muitos programadores fazem exatamente isso. O Sonnet lida com 90%+ das tarefas bem. O Opus supera genuinamente apenas em casos estreitos: raciocínio arquitetural profundo, refactorings multi-ficheiro com requisitos subtis de consistência, e depuração complexa que cruza múltiplas camadas de abstração. Se o seu trabalho é principalmente desenvolvimento de features, correção de bugs e revisões, o Sonnet basta — e custa 5x menos.

Como as equipas gerem custos do Claude Code?

A maioria usa planos Max individuais — um por programador. Para custos partilhados (CI/CD, revisões automatizadas), uma única chave API com alertas de gastos. O tech lead monitoriza gastos mensais e ajusta a frequência de automatização se os custos subirem. Um CLAUDE.md partilhado e bem otimizado também ajuda — reduz o desperdício de tokens por exploração do projeto por cada programador.