O custo invisível dos tokens desperdiçados e como parar de queimar dinheiro com IA

Quanto você gasta por mês com IA para programar? Se você usa Claude, GPT-4 ou qualquer modelo de fronteira via API, a resposta provavelmente é “mais do que deveria”. E o pior: a maioria desse custo é invisível.

Não estou falando de planos mensais fixos. Estou falando de quem usa a API diretamente, seja via Claude Code, agentes autônomos ou pipelines de CI/CD integrados com LLMs. Nesse cenário, cada token conta, e a maioria das pessoas está desperdiçando entre 30% e 50% deles.

Anatomia do desperdício

Tokens desperdiçados vêm de quatro fontes principais:

1. Contexto repetido entre sessões

Você abre uma sessão nova com seu agente de IA e explica: “estou trabalhando no projeto X, que usa TypeScript, Prisma, o banco é PostgreSQL, a API segue REST com autenticação JWT…”. Na sessão seguinte, repete tudo. E na próxima. E na próxima.

Esse briefing repetitivo consome entre 500 e 2.000 tokens por sessão. Em 50 sessões por mês, são 25.000 a 100.000 tokens gastos dizendo a mesma coisa.

2. Respostas de ferramentas infladas

Quando um agente chama list_directory, recebe a árvore inteira do projeto. Quando chama read_file, recebe o arquivo completo. Na maioria das vezes, o agente só precisava de uma fração dessa informação.

Em uma sessão típica com 20 chamadas de ferramentas, o desperdício de tokens em respostas irrelevantes pode chegar a 40.000 tokens. O agente processa tudo, mas usa uma fração.

3. Context rot (degradação de contexto)

Pesquisas da Chroma demonstraram que a performance de LLMs cai significativamente quando a janela de contexto ultrapassa 32K tokens. O modelo não fica “burro”, ele fica distraído. Com muita informação na janela, a atenção se dilui e respostas ficam menos precisas.

O paradoxo: você paga mais tokens para obter respostas piores. Cada token irrelevante não só custa dinheiro, ele reduz a qualidade da resposta.

4. Cache inexistente

Se você pergunta “como funciona o módulo de autenticação?” e depois “explique o fluxo de auth”, são duas queries semanticamente idênticas processadas do zero. Sem cache semântico, o agente faz busca, síntese e resposta duplicadas.

Quanto isso custa (números reais)

Vamos fazer as contas com preços atuais:

Modelo	Preço (input)	Preço (output)
Claude Opus 4	$15/1M tokens	$75/1M tokens
Claude Sonnet 4	$3/1M tokens	$15/1M tokens
GPT-4o	$2.50/1M tokens	$10/1M tokens

Um desenvolvedor ativo que usa Claude Sonnet via API com 50 interações/dia, ~5K tokens por interação:

Consumo mensal: ~7.5M tokens
Custo sem desperdício: ~$22.50 (input) + ~$112.50 (output) = ~$135/mês
Com 40% de desperdício: ~$189/mês
Diferença: ~$54/mês por pessoa

Em um time de 5 desenvolvedores, são $270/mês jogados fora. Em um ano, $3.240. E isso com Sonnet — com Opus, multiplique por 5x.

Para agentes autônomos que fazem dezenas de chamadas de ferramentas por tarefa, o desperdício é ainda maior. Um agente resolvendo um bug pode facilmente consumir 50K tokens em chamadas de ferramentas que retornam informação irrelevante.

Técnicas que reduzem o desperdício

1. Memória persistente

Em vez de repetir contexto a cada sessão, use uma ferramenta que persiste decisões e padrões. O MCP Context Hub, por exemplo, armazena informações do projeto e entrega apenas os trechos relevantes quando o agente precisa. O briefing de 2.000 tokens se transforma em um context_pack de 500 tokens otimizados.

Economia estimada: 50-70% de redução em tokens de contexto repetitivo.

2. Compressão de contexto

Em vez de enviar documentação bruta, comprimir mantendo a informação essencial. A técnica não é nova — o paper “LLMLingua” da Microsoft Research (EMNLP 2023) mostrou que prompts podem ser comprimidos em até 20x sem perda significativa de qualidade.

Na prática, compressão dual-path funciona bem: regras para 80% dos casos (rápida, menos de 50ms) e LLM local para os 20% complexos.

Economia estimada: 30-60% de redução no tamanho do contexto enviado.

3. Progressive disclosure para ferramentas

Em vez de deixar respostas brutas de ferramentas irem direto para o contexto do agente, usar níveis progressivos de detalhe. Comece com um resumo (100 tokens). Se o agente precisa de mais, ele pede e recebe o próximo nível.

O proxy_call do MCP Context Hub implementa isso com 4 níveis (L0-L3) e expand-on-use automático. Na prática, economiza entre 60% e 90% dos tokens gastos com ferramentas externas.

Economia estimada: 60-90% de redução em tokens de resposta de ferramentas.

4. Cache semântico

Armazenar respostas e reconhecer quando uma nova pergunta é semanticamente equivalente a uma já respondida. Não precisa ser correspondência exata — similaridade de cosseno acima de 0.88 já é suficiente para a maioria dos casos.

Cache semântico transforma uma busca de 1.3 segundos em uma resposta de 1.6ms. Além de economizar tokens, economiza tempo e chamadas de API.

Economia estimada: 20-40% de redução em queries repetitivas.

5. Session delta tracking

Rastrear quais informações o agente já recebeu na sessão atual. Se ele já tem contexto sobre autenticação, não enviar de novo quando uma pergunta relacionada aparece. Enviar apenas o delta.

Economia estimada: 30-50% de redução em sessões longas.

O efeito composto

Essas técnicas não são mutuamente exclusivas. Na prática, elas se compõem:

Cache semântico intercepta queries repetitivas (20-40% de economia)
Session tracking remove chunks já enviados (30-50% a mais)
Compressão reduz o tamanho dos chunks restantes (30-60% a mais)
Progressive disclosure otimiza respostas de ferramentas (60-90%)

O efeito composto chega a 80%+ de economia total de tokens. E não é um número teórico — é o que os benchmarks do MCP Context Hub demonstram com corpus de teste real e metodologia aberta.

Além do custo: qualidade

O argumento econômico é convincente, mas o impacto na qualidade é ainda mais importante.

Context rot é real. Um modelo que recebe 50K tokens de contexto onde apenas 10K são relevantes produz respostas piores do que o mesmo modelo recebendo apenas os 10K relevantes. Isso está documentado em múltiplos papers e é observável na prática diária.

Otimizar tokens não é só economizar dinheiro. É dar ao modelo as condições ideais para responder bem. Menos ruído, mais sinal. Menos distração, mais foco.

E para agentes autônomos, isso é crítico. Um agente com contexto otimizado comete menos erros, precisa de menos correções e completa tarefas mais rápido. O ROI não está só nos tokens economizados — está no tempo não gasto corrigindo erros da IA.

Calculando o desperdício na prática: exemplos concretos

Vamos sair das estimativas gerais e calcular cenários específicos que encontro no dia a dia.

Cenário 1: agente autônomo resolvendo um bug

Um bug típico de produção. O agente precisa entender o contexto, encontrar o problema e corrigir.

Etapa	Tokens consumidos	Tokens úteis	Desperdício
Leitura do arquivo principal (350 linhas)	4.200	800	3.400
Listagem do diretório do projeto	2.100	300	1.800
Leitura de 3 arquivos relacionados	9.600	2.400	7.200
Leitura do stacktrace completo	1.800	600	1.200
Resposta com correção	3.200	3.200	0
Total	20.900	7.300	13.600

Nesse cenário, 65% dos tokens foram desperdiçados. Com progressive disclosure (enviar apenas as seções relevantes dos arquivos), o consumo cairia para aproximadamente 9.000 tokens. A diferença em um mês com 100 bugs resolvidos: 1.190.000 tokens economizados, o equivalente a $3.57 com Sonnet ou $17.85 com Opus, só nessa categoria.

Cenário 2: sessão de desenvolvimento de feature

Uma sessão de 2 horas onde o desenvolvedor está construindo uma feature nova com assistência do agente. Estimativa baseada em sessões reais que monitorei:

40 interações ao longo de 2 horas
Contexto repetido em cada interação: ~1.500 tokens (descrição do projeto, stack, padrões)
Total de contexto repetido: 60.000 tokens
Com memória persistente: 8.000 tokens (contexto enviado uma vez + deltas)
Economia: 52.000 tokens por sessão

Se o desenvolvedor faz 3 sessões dessas por semana, são 624.000 tokens economizados por mês. Com Opus, isso representa $9.36 por desenvolvedor por mês apenas em contexto repetido.

Cenário 3: pipeline de CI/CD com revisão de código por IA

Um pipeline que roda revisão de código automática em cada PR. Cada revisão envia o diff completo mais os arquivos modificados.

15 PRs por dia no time
Tokens por revisão (sem otimização): ~25.000
Tokens por revisão (com diff otimizado + contexto comprimido): ~8.000
Economia diária: 255.000 tokens
Economia mensal (22 dias úteis): 5.610.000 tokens
Em dinheiro (Sonnet): $16.83/mês de input + $84.15/mês de output = ~$100/mês

Cem dólares por mês pode parecer pouco para um time, mas escale para 10 times em uma empresa e você tem $12.000 por ano. E isso é só a revisão de código.

Estratégias de otimização com código

Além das técnicas conceituais, aqui estão implementações práticas que uso em projetos.

Filtragem de contexto antes do envio

Em vez de enviar um arquivo inteiro, extraia apenas a função ou classe relevante:

// Antes: enviar arquivo inteiro (300 linhas, ~3.600 tokens)
const fullFile = fs.readFileSync('auth.service.ts', 'utf-8');

// Depois: enviar apenas a função relevante (~400 tokens)
function extractFunction(filePath: string, functionName: string): string {
  const ast = parseTypeScript(filePath);
  const node = findFunction(ast, functionName);
  if (!node) return '';

  const startLine = node.startPosition.row;
  const endLine = node.endPosition.row;
  const lines = fs.readFileSync(filePath, 'utf-8').split('\n');
  return lines.slice(startLine, endLine + 1).join('\n');
}

const relevantCode = extractFunction('auth.service.ts', 'validateToken');

Essa abordagem reduz o contexto em 80-90% para a maioria dos casos. A chave é saber qual trecho o agente precisa antes de enviar.

Cache semântico simples com embeddings

Uma implementação básica de cache semântico que evita queries duplicadas:

import { cosineSimilarity } from './utils';

interface CacheEntry {
  embedding: number[];
  query: string;
  response: string;
  timestamp: number;
}

class SemanticCache {
  private entries: CacheEntry[] = [];
  private threshold = 0.88;

  async get(query: string): Promise<string | null> {
    const queryEmbedding = await embed(query);

    for (const entry of this.entries) {
      const similarity = cosineSimilarity(queryEmbedding, entry.embedding);
      if (similarity >= this.threshold) {
        return entry.response;
      }
    }
    return null;
  }

  async set(query: string, response: string): Promise<void> {
    const embedding = await embed(query);
    this.entries.push({
      embedding,
      query,
      response,
      timestamp: Date.now()
    });
  }
}

Com um threshold de 0.88, perguntas como “como funciona a autenticação?” e “explique o fluxo de auth do projeto” retornam o mesmo resultado cacheado. Na prática, isso intercepta 20-30% das queries em uma sessão típica.

Monitorando o consumo de tokens

Não dá para otimizar o que você não mede. Aqui estão as métricas que monitoro e como.

Métricas essenciais

Tokens por tarefa concluída: quantos tokens o agente consome para resolver um bug, implementar uma feature, ou fazer uma revisão. Essa é a métrica mais importante porque conecta consumo a valor.
Taxa de tokens úteis vs. totais: do total de tokens consumidos, quantos foram efetivamente usados na resposta final. Esse é o indicador direto de desperdício.
Tokens de contexto por sessão: quanto contexto está sendo enviado em cada interação. Se esse número cresce ao longo da sessão sem que novas informações estejam sendo adicionadas, há repetição.
Cache hit rate: se você usa cache semântico, qual porcentagem das queries está sendo resolvida via cache. Abaixo de 15% sugere que o cache não está calibrado corretamente.

Como monitorar na prática

A forma mais simples é instrumentar as chamadas de API. Se você usa o SDK da Anthropic, cada resposta inclui usage.input_tokens e usage.output_tokens:

const response = await anthropic.messages.create({
  model: 'claude-sonnet-4-20250514',
  messages: [...],
  max_tokens: 4096
});

// Log de consumo
console.log({
  task: 'bug-fix-auth-middleware',
  input_tokens: response.usage.input_tokens,
  output_tokens: response.usage.output_tokens,
  total_tokens: response.usage.input_tokens + response.usage.output_tokens,
  timestamp: new Date().toISOString()
});

Acumule esses logs em um arquivo ou banco de dados e analise semanalmente. Você vai identificar padrões: quais tipos de tarefa consomem mais, quais sessões têm mais desperdício, quais desenvolvedores do time precisam de ajuda com prompts mais eficientes.

Dashboard simples

Não precisa de nada sofisticado. Um script que lê os logs e gera um resumo semanal já é suficiente para começar:

Total de tokens consumidos (input + output)
Custo estimado em dólares
Top 5 tarefas mais caras
Taxa média de desperdício (se você está medindo tokens úteis)
Comparação com a semana anterior

A visibilidade muda o comportamento. Quando o time vê que uma tarefa simples consumiu 200K tokens, alguém vai perguntar “por que tanto?” e a otimização acontece naturalmente.

Comece pelo mais simples

Se você não quer adotar uma stack completa de otimização, comece pelo básico:

CLAUDE.md / .cursorrules: documente patterns e decisões do projeto. O agente lê uma vez e não precisa que você repita.
Seja específico nos prompts: “corrija o bug no middleware de autenticação na linha 47 do arquivo auth.ts” gasta menos tokens que “tem um bug no login, dá uma olhada”.
Divida tarefas grandes: em vez de “refatora o módulo inteiro”, divida em sub-tarefas. Cada sub-tarefa usa menos contexto e gera resultados melhores.
Revise antes de enviar: se você está colando um arquivo de 500 linhas no prompt, pergunte: “o agente precisa de tudo isso ou só de uma seção específica?”
Meça antes de otimizar: adicione logs de consumo de tokens nas suas chamadas de API. Sem dados, você está otimizando no escuro.
Estabeleça budgets por tarefa: defina limites razoáveis (ex: bug fix simples = máximo 30K tokens, feature nova = máximo 150K tokens). Quando uma tarefa ultrapassa o budget, investigue por quê.

Essas práticas já reduzem significativamente o desperdício. E quando você quiser ir além, ferramentas como o MCP Context Hub automatizam todo esse processo.

O ponto é simples: tokens são recursos finitos e pagos. Tratar eles com a mesma atenção que você trata chamadas de API ou queries de banco não é otimização prematura. É engenharia de software básica.

Referências: