Seus 20 Devs Rodam Claude Code e Você Não Sabe Nem Quanto Gastam? Duas Variáveis Resolvem

Vou te contar uma coisa que eu vejo acontecer em quase toda software house que mentoro.

O CEO aprova Claude Code para o time. Vinte licenças, R$200 por cabeça por mês. Quatro mil reais saindo todo mês. Às vezes mais — tem SH pagando R$4.000 por dev no plano Max. E quando eu pergunto: “Quanto cada dev gasta em tokens? Qual modelo consome mais? O prompt cache está funcionando? Aquele script Bash que o Claude rodou na sexta de noite fez o quê exatamente?” — silêncio.

Ninguém sabe.

Ninguém monitora.

O Claude Code é a ferramenta de desenvolvimento mais poderosa que existe hoje, e a maioria das SHs roda ela com a mesma visibilidade que tinha do Notepad++ em 2010: nenhuma.

Isso mudou na v2.1.97, com uma feature que parece pequena mas fecha o último gap de observabilidade que existia: propagação automática de TRACEPARENT para subprocessos Bash. Agora, quando o Claude Code roda um npm test, um docker build ou qualquer script, esse processo herda o contexto de trace W3C do Claude Code — e aparece como um span filho no seu Jaeger, Grafana Tempo ou Honeycomb. Distributed tracing de ponta a ponta. Do prompt do dev até o último chmod que o Claude executou.

Mas essa feature só faz sentido se você entender o stack completo de observabilidade que o Claude Code oferece — e que 95% das SHs ignora completamente.

O que é o stack OTEL do Claude Code

O Claude Code tem integração nativa com OpenTelemetry — o segundo projeto mais ativo da CNCF, atrás apenas do Kubernetes. Não é um plugin. Não é um MCP server. É telemetria embutida que exporta métricas, eventos e traces para qualquer backend compatível.

Para ativar, são literalmente duas variáveis de ambiente:

export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp

Pronto. O Claude Code começa a exportar dados para o seu collector. Prometheus, Grafana, Datadog, Honeycomb, Elasticsearch, Jaeger — qualquer um que fale OTLP.

Mas o “pronto” básico é só o começo. O stack completo inclui três camadas:

Camada 1: Métricas (time series)

Oito métricas nativas que o Claude Code exporta a cada 60 segundos:

Cada métrica carrega atributos de session.id, user.account_uuid, organization.id e model. Ou seja: você sabe quanto cada dev gasta, em qual modelo, com qual eficiência de cache, em tempo real.

Camada 2: Eventos (logs estruturados)

Cinco tipos de eventos que contam a história completa de cada interação:

• user_prompt — quando o dev envia um prompt (conteúdo redatado por padrão, tamanho sempre registrado)
• tool_result — cada ferramenta executada: nome, duração, sucesso/falha, e com OTEL_LOG_TOOL_DETAILS=1, o comando Bash completo, inclusive o git_commit_id quando um commit é feito
• api_request — cada chamada à API: modelo, custo, tokens, cache hits, duração, modo fast/normal
• api_error — erros com status code, tentativa de retry, duração
• tool_decision — cada vez que o dev aceita ou rejeita uma edição, com a fonte da decisão (config, hook, user)

Todos os eventos carregam um prompt.id — um UUID que correlaciona tudo que aconteceu desde um único prompt do dev. Você filtra por esse ID e vê: o dev perguntou X → o Claude chamou a API Y → executou as ferramentas Z → gerou o commit W. Auditoria completa.

Camada 3: Traces (beta) — a novidade

E aqui é onde o TRACEPARENT entra.

Quando você ativa traces com CLAUDE_CODE_ENHANCED_TELEMETRY_BETA=1 e OTEL_TRACES_EXPORTER=otlp, o Claude Code gera spans que linkam cada prompt do dev → chamadas de API → execuções de ferramenta. Você abre o Jaeger ou Grafana Tempo e vê um waterfall diagram de tudo que aconteceu.

Mas até a v2.1.96, tinha um buraco: quando o Claude Code rodava um npm test ou um ./deploy.sh via Bash, esse processo era uma caixa preta. Aparecia como “Bash tool” no trace, mas o que acontecia dentro dele — subitens, chamadas de rede, queries de banco — sumia.

Na v2.1.97, o Claude Code propaga automaticamente a variável TRACEPARENT para todo subprocess Bash. Seguindo o padrão W3C Trace Context, qualquer processo que leia TRACEPARENT pode criar seus próprios spans como filhos do trace do Claude Code.

Na prática:

1. Dev pede: “rode os testes e faça deploy para staging”
2. Claude Code cria um span “Bash tool”
3. O npm test herda o TRACEPARENT, e se sua test suite tem instrumentação OTEL (ou se usa um runner que tem), cada teste aparece como span filho
4. O ./deploy.sh herda o TRACEPARENT, e o Terraform/kubectl dentro dele também podem reportar spans
5. Resultado: um trace único do prompt do dev até o pod subindo no Kubernetes

Isso é distributed tracing real. O mesmo que você faz entre microserviços, agora entre humano → IA → scripts → infraestrutura.

Como configurar em 15 minutos

Para uma SH com 20 devs, a configuração mínima viável é:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.suash.com:4317",
    "OTEL_RESOURCE_ATTRIBUTES": "department=engineering,team.id=backend,cost_center=eng-001"
  }
}

Os OTEL_RESOURCE_ATTRIBUTES são ouro: com department, team.id e cost_center, você segmenta métricas por time no Grafana. O time de frontend gasta quanto? O backend? Aquele dev que está fazendo o projeto novo — quanto está consumindo?

Para traces completos com TRACEPARENT:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "CLAUDE_CODE_ENHANCED_TELEMETRY_BETA": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_TRACES_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.suash.com:4317"
  }
}

E para enterprise com autenticação dinâmica, o Claude Code suporta otelHeadersHelper — um script que gera tokens frescos a cada 29 minutos:

{
  "otelHeadersHelper": "/opt/scripts/generate-otel-token.sh"
}

O admin configura uma vez. Os devs não tocam em nada. A telemetria flui.

Privacidade sob controle

Três variáveis controlam o que é coletado:

• OTEL_LOG_USER_PROMPTS=1 — inclui conteúdo dos prompts (desligado por padrão)
• OTEL_LOG_TOOL_DETAILS=1 — inclui comandos Bash, nomes de MCP tools, argumentos (desligado por padrão, truncado em 512 chars/4KB total)
• OTEL_LOG_TOOL_CONTENT=1 — inclui input/output completo em spans (desligado por padrão, truncado em 60KB)

Por padrão, o Claude Code não coleta conteúdo. Só metadados: quanto, quando, quem, qual modelo, quanto custou. Para compliance e LGPD, isso é fundamental — você tem visibilidade total sem expor código-fonte nos logs.

Por que isso importa para sua software house

Deixa eu traduzir os números.

80% dos trabalhadores usam ferramentas de IA não aprovadas — o chamado Shadow AI (SQ Magazine, 2026). Na sua SH, pode ser dev usando Claude Code na conta pessoal enquanto a empresa paga a licença corporativa. Ou pior: usando um modelo diferente do que você configurou.

Shadow AI adiciona US$670.000 ao custo médio de um breach (Aona AI, 2026). Não é hipotético. 20% das organizações já reportaram breaches causados especificamente por Shadow AI. O custo médio de um breach envolvendo IA não governada: US$4,2 milhões.

45% dos desenvolvedores admitem usar code assistants não sancionados — e com isso, código proprietário da sua SH pode estar sendo absorvido por dados de treinamento de terceiros. Sem telemetria, você nem sabe que isso acontece.

Agora olha pelo lado financeiro. 48,5% das organizações já usam OpenTelemetry, e o ROI médio de investimento em observabilidade é 2,6x (Grafana Labs, 2026). Organizações que investem em governance de IA têm 30% menos custos com riscos.

O Gartner projeta que gastos com AI governance vão atingir US$492 milhões em 2026 e ultrapassar US$1 bilhão até 2030. As empresas que já estão medindo vão pagar menos. As que não estão vão pagar em breach, em desperdício e em compliance.

Para uma SH com 20 devs a R$200/mês (plano Pro), são R$48.000/ano. No Max (R$4.000/mês), R$960.000/ano. No Bedrock pay-per-use, pode ser mais ou menos — mas sem telemetria, você literalmente não sabe quanto.

Com OTEL ativado, você abre o Grafana e vê:

• Custo por dev por dia, por modelo (Opus, Sonnet, Haiku)
• Token breakdown: input vs output vs cache read vs cache creation
• Cache hit rate: se o prompt caching está funcionando (pode reduzir input em 90%)
• Tempo ativo real: quanto tempo cada dev está efetivamente usando vs idle
• Ferramentas mais usadas: Edit, Bash, Read, Write — quem está usando o Claude para quê
• Taxa de aceitação: quantas edições o dev aceita vs rejeita
• Erros: rate limits, 429s, falhas de API
• E agora com TRACEPARENT: cada script Bash que o Claude roda vira um span no trace — debugging e auditoria ponta a ponta

Isso é FinOps para IA de verdade. Não é dashboard bonito — é P&L por desenvolvedor.

O que eu penso

Na minha experiência com 300+ software houses, o padrão é sempre o mesmo: a empresa adota a ferramenta, paga a licença, e a governança fica para “depois”. Esse “depois” nunca chega — até que chega uma fatura surpresa, um incidente de segurança, ou uma auditoria.

O Claude Code é a primeira ferramenta de AI coding que trata observabilidade como cidadão de primeira classe. Não é um plugin. Não é uma integração de terceiros. São variáveis de ambiente que conversam com o mesmo stack que a sua SH já usa para monitorar produção: Prometheus, Grafana, Jaeger.

E o TRACEPARENT é a cereja. Distributed tracing para AI agents não é conceito acadêmico — a Red Hat publicou um guia completo sobre isso há 3 dias. O OpenTelemetry já tem um working group dedicado a observabilidade de AI agents. E o Claude Code é o primeiro AI coding tool que implementa isso nativamente.

Se a sua SH roda Claude Code sem segurança na inicialização, sem monitoramento de custos e sem tracing, você está pilotando um avião sem painel. Funciona — até que não funciona.

Duas variáveis de ambiente. Quinze minutos de setup. E você nunca mais vai responder “não sei” quando perguntarem quanto a IA custa na sua operação.

Sou Thulio, mentoro 300+ SHs desde 2016.