Seus 20 Devs Usam Claude Code e Você Não Sabe Quem Usa Opus? Um Comando Mostra Tudo

Você sabe quanto cada dev da sua SH gasta com IA por dia?

Não estou falando de “ah, a gente paga o Claude Code”. Estou falando de saber que o João usa Opus para formatar JSON, que a Maria tem 0% de cache hits porque limpa a sessão a cada pergunta, e que o estagiário gasta mais que o tech lead porque roda 5 agents em paralelo sem compactar contexto.

Na minha experiência com 300+ software houses, a conversa sobre IA sempre começa empolgada — “vamos colocar Claude Code pra todo mundo” — e três meses depois vira um “quanto a gente está gastando com isso?” seguido de silêncio constrangedor.

O problema nunca foi gastar. O problema é gastar sem saber onde vai o dinheiro.

E a versão v2.1.92 do Claude Code acabou de resolver isso de um jeito que eu achei brilhante: o comando /cost agora mostra breakdown por modelo e por cache hits. Parece simples. Muda tudo.

O que mudou no /cost

Antes, o /cost mostrava um número agregado: “você gastou $0.55 nessa sessão”. Útil? Mais ou menos. Era como receber a conta de luz sem saber se foi o ar-condicionado ou o chuveiro.

Agora o output ficou assim:

claude-sonnet-4-6: 9.4k input, 33.7k output, 2.3m cache read, 172.2k cache write ($3.10)
claude-opus-4-6: 1.2k input, 4.8k output, 890k cache read, 45k cache write ($1.85)
claude-haiku-4-5: 500 input, 1.2k output, 0 cache read, 0 cache write ($0.02)

Três informações que não existiam antes:

1. Qual modelo está sendo usado — e quanto cada um custa separadamente
2. Quanto do input veio do cache — os “cache read” tokens custam apenas 10% do preço normal
3. Quanto cache está sendo criado — cache write tokens existem, mas você quer que eles sejam lidos depois

Essa transparência é nova. E é poderosa.

Por que cache hits importam mais do que você pensa

Vou ser direto: prompt caching é provavelmente a maior economia invisível do Claude Code. E a maioria dos devs nem sabe que existe.

Quando você conversa com o Claude Code, o sistema prompt, suas instruções do CLAUDE.md, schemas de ferramentas MCP — tudo isso é reenviado a cada mensagem. Em uma sessão longa, isso pode ser milhões de tokens repetidos.

O prompt caching guarda esse conteúdo estático por 5 minutos. Na próxima mensagem, em vez de enviar tudo de novo ao preço cheio, o cache é lido a 10% do custo.

A matemática é brutal:

• Sem cache: 2 milhões de tokens de input × preço cheio = caro
• Com cache hit: 2 milhões de tokens × 10% do preço = 90% mais barato
• Com cache miss (expirou os 5 minutos): volta pro preço cheio

Estudos mostram que prompt caching reduz custos de 45% a 80% em aplicações com conteúdo estático significativo. Em RAG systems, a economia chega a 90%.

Mas aqui está o ponto: sem o breakdown de cache hits no /cost, você não tinha como saber se o caching estava funcionando na sua sessão. Agora tem.

Se seus “cache read” estão zerados, algo está errado. Talvez o dev esteja limpando a sessão com frequência demais. Talvez esteja demorando mais de 5 minutos entre mensagens. Talvez tenha modificado o CLAUDE.md no meio da sessão e invalidou o cache.

O ponto é: agora você vê.

Para Pro users: o hint de cache expiry

A v2.1.92 trouxe outra melhoria sutil para quem está no plano Pro: quando você volta a uma sessão depois que o prompt cache expirou, um hint no footer mostra quantos tokens serão enviados sem cache na próxima mensagem.

É como se o Claude Code dissesse: “ei, você ficou 15 minutos sem mandar mensagem, o cache expirou, sua próxima mensagem vai custar mais”.

Pra quem paga por subscription, isso parece irrelevante em termos de billing — o uso já está incluso no plano. Mas o rate limit não é infinito. Se o dev está mandando 2 milhões de tokens uncached a cada mensagem, ele come o rate limit muito mais rápido.

Na prática, esse hint incentiva um comportamento melhor: manter sessões ativas, usar /compact antes de pausas longas, ou simplesmente estar ciente de que “essa próxima mensagem vai ser pesada”.

Como funciona na prática para uma SH com 20 devs

Vou pintar o cenário real. Sua SH tem 20 devs usando Claude Code via API. O custo médio é $6 por dev por dia, o que dá $120/dia ou ~$2.600/mês. Para 90% dos usuários, o custo diário fica abaixo de $12.

Mas essa média esconde uma variância enorme. Na prática:

• 3 devs seniors usam Opus para decisões arquiteturais complexas — justificado
• 5 devs usam Opus para tudo, inclusive formatar código — injustificado
• 8 devs usam Sonnet corretamente — custo ótimo
• 2 devs usam Haiku para subagents — economia máxima
• 2 devs não sabem qual modelo estão usando — voando cego

Sem o breakdown por modelo, tudo isso era invisível. Agora, cada dev pode rodar /cost e ver:

• “Ah, eu gastei $4.20 com Opus e $0.30 com Sonnet. Talvez eu não precise de Opus para tudo.”
• “Meus cache reads estão em zero. Preciso parar de limpar a sessão.”
• “O Haiku do meu subagent custou $0.02. Vale a pena.”

E para o CTO/tech lead que está pagando a conta, os dados ficam acionáveis.

O stack completo de observabilidade

O /cost com breakdown por modelo não existe isolado. Ele é a camada mais acessível de um stack de observabilidade que a Anthropic vem construindo nos últimos meses:

1. /cost per-model breakdown (v2.1.92) — visibilidade individual por sessão
2. X-Claude-Code-Session-Id (v2.1.86) — header em toda API request para proxy agregar por sessão
3. OpenTelemetry — 8 métricas + 5 tipos de eventos, incluindo claude_code.token.usage com atributo model e type (input, output, cacheRead, cacheCreation)
4. modelOverrides — controle de quais modelos os devs podem usar
5. OTEL_RESOURCE_ATTRIBUTES — segmentação por departamento, time, centro de custo

O token counter do OTel já exporta cacheRead e cacheCreation como tipos separados. Isso significa que no seu Grafana ou Datadog, você pode ter um dashboard mostrando:

• Cache hit rate por dev
• Custo por modelo por semana
• Tendência de cache efficiency ao longo do tempo
• Devs com 0% cache hits (candidatos a treinamento)

Os números que deveriam te preocupar

40% das empresas gastam mais de $250 mil por ano com LLMs. O gasto com API de IA saltou de $500 milhões em 2023 para $8.4 bilhões em meados de 2025. E 72% das organizações esperam gastar mais em 2026.

Mas aqui está o dado assustador: só 30% das organizações têm visibilidade completa de como seus funcionários usam ferramentas de IA. 85% dos decision-makers reconhecem que gaps em IT visibility representam risco significativo.

E o que as empresas querem mais? AI cost management é o skillset #1 mais desejado em FinOps em 2026. 98% dos respondentes de FinOps já gerenciam AI spend.

O problema é claro: todo mundo está gastando, poucos sabem onde.

Uma SH que paga R$15-30 mil por mês de Claude Code sem breakdown por modelo é como um restaurante que paga a conta de energia sem saber se o freezer está com a porta aberta.

3 ações práticas para sua SH

1. Faça seus devs rodarem /cost no final de cada sessão

Parece básico, mas consciência é o primeiro passo. Quando o dev vê “gastei $8.50 com Opus para fazer algo que Sonnet faria”, o comportamento muda sozinho.

2. Configure OpenTelemetry para visibilidade centralizada

Para SHs com 10+ devs, o /cost individual não escala. Configure o OTel export com:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp
export OTEL_LOGS_EXPORTER=otlp
export OTEL_EXPORTER_OTLP_ENDPOINT=http://seu-collector:4317

Isso exporta claude_code.token.usage com breakdown por model e type (incluindo cacheRead). Use OTEL_RESOURCE_ATTRIBUTES="team.id=backend,cost_center=eng-01" para segmentar por time.

3. Restrinja modelos com modelOverrides + availableModels

Se o custo com Opus está alto demais e a maioria dos casos de uso não justifica, use availableModels no managed settings para limitar o picker:

{
  "availableModels": ["claude-sonnet-4-6", "claude-haiku-4-5"]
}

Opus disponível só para tech leads ou por aprovação. Sonnet para 90% dos casos. Haiku para subagents.

O que eu penso

De todas as features que o Claude Code lançou nos últimos meses, essa é das mais silenciosas — mas talvez a mais importante para quem paga a conta.

Não é uma feature que faz “uau” num demo. Ninguém vai twittar “olha o breakdown de cache hits do /cost!” com 500 likes. Mas é exatamente o tipo de feature que separa uma SH que usa IA de verdade de uma que “tem IA” na planilha do board.

Um artigo no DEV Community alertou que o Claude Code pode queimar 10-20x o budget de tokens sem que o dev perceba. Com o breakdown por modelo e cache hits, pelo menos agora dá pra ver o fogo antes que vire incêndio.

IA não é mágica. É infraestrutura. E infraestrutura se monitora.

Conclusão

O /cost com breakdown por modelo e cache hits é a peça que faltava entre “estamos pagando Claude Code” e “sabemos exatamente como estamos usando Claude Code”.

Para SHs pequenas (5 devs), o /cost individual já resolve. Para SHs médias e grandes (15+ devs), combine com OTel, Session ID header e modelOverrides para ter visibilidade completa.

A pergunta não é se sua SH deveria estar monitorando custos de IA. A pergunta é: por que ainda não está?

Se você quer implementar esse nível de observabilidade na sua software house e parar de pagar conta de IA no escuro, fala comigo.

Sou Thulio, mentoro 300+ SHs desde 2016.