Gestão de Tokens em Produção: Como Usar IA Intensamente Sem Explodir o Custo

Existe um padrão que se repete em times que adotam LLMs com seriedade. No começo, tudo parece razoável: o custo de API é alto, mas o valor que o time está entregando também é. Aí o uso cresce — mais devs usando Claude Code, mais pipelines em produção, mais agentes rodando tarefas automatizadas. E em algum momento da semana, geralmente na quinta-feira, alguém percebe que o budget do mês acabou.

Não é irresponsabilidade. É um efeito natural de como LLMs em produção consomem tokens. Em 2026, um agente em produção facilmente manda 50K a 500K tokens de input por request. Contra apenas algumas centenas de output. A proporção de input para output é frequentemente 100:1 ou mais.

Isso muda completamente onde você deve otimizar. A maioria das pessoas foca em reduzir output — respostas mais curtas, menos texto gerado. Mas se input é 100x maior que output, uma redução de 80% no custo de input vai ter muito mais impacto do que cortar o output pela metade.

O que segue é um playbook ordenado por ROI: as técnicas que mais retornam por menor esforço de implementação, com honestidade sobre quando cada uma não vale a pena.

---

O Problema Antes das Soluções

Quando você está construindo algo novo com LLMs, a tendência natural é testar tudo, mandar contextos imensos, iterar rápido sem se preocupar com eficiência. É o comportamento correto para descoberta — você quer velocidade, não frugalidade.

O problema aparece quando esse comportamento vai para produção sem ajustes. Os mesmos contextos imensos agora estão sendo reprocessados em cada request, de cada usuário, de cada pipeline automatizado.

Há também um problema específico de budget de planos de time. Claude Team e Business têm limites mensais por usuário. OpenAI Team é similar. Devs que usam intensamente — especialmente Claude Code em projetos grandes — podem atingir esses limites antes do meio do mês, deixando o time sem acesso na hora errada.

A solução não é usar menos IA. É usar com mais inteligência.

---

1. Prompt Caching — Ative Primeiro, Sempre

Se você fosse implementar apenas uma técnica desta lista, seria essa. O ROI é o maior por esforço mínimo.

O mecanismo: quando você envia o mesmo prefixo de prompt repetidamente (system prompt, lista de ferramentas, documentos de contexto estático), o provider pode reutilizar o estado computado desse prefixo em vez de processar tudo do zero a cada request. Você paga menos pelos tokens que vieram do cache.

Os descontos são expressivos:

• Anthropic: 90% de desconto no custo de input para tokens cacheados (você paga 0,1x). Você define breakpoints explícitos com cache_control.
• OpenAI: 50% de desconto automático via longest-prefix caching para prompts acima de 1.024 tokens. Não precisa configurar nada.
• Gemini: até 90% dependendo do modelo, com custo adicional de storage por hora que pode reduzir o benefício líquido.

A redução real em produção varia, mas dados do LangChain com Deep Agents em evals mostram: claude-haiku-4-5 com caching ativo tem 77% de redução nos custos de input, gpt-5.4-mini tem 80%, gemini-3.5-flash tem 49% (puxado para baixo pelo custo de storage).

Como Maximizar o Cache Hit Rate

A regra mais importante: estático antes, dinâmico depois. O cache funciona por prefixo — tudo que muda invalida o cache a partir daquele ponto.

Estrutura ideal do prompt:

1. System prompt completo (estático)
2. Lista de ferramentas (raramente muda)
3. Documentos de contexto permanente (estáticos)
4. [Breakpoint de cache aqui]
5. Histórico de conversa (dinâmico)
6. Input do usuário (dinâmico)

O erro mais comum que destrói o hit rate: colocar timestamps, IDs de sessão, ou dados variáveis dentro do system prompt. Se o system prompt muda a cada request, você tem 0% de hit rate no componente mais caro do contexto.

A ProjectDiscovery saiu de 7% para 84% de KV cache hit rate fazendo exatamente essa mudança — tirar o estado dinâmico do agente do system prompt e colocá-lo no final da mensagem. Resultado: 59% de redução nos custos de operação.

Cache Prewarm

Se você sabe que vai ter um pico de uso (início do dia de trabalho, horário de pico de um produto), pode fazer uma request de aquecimento antes dos usuários chegarem. Especialmente útil no Anthropic depois de atualizar o system prompt — o cache de um novo prefixo começa frio.

---

2. Caveman — Para Sessões Multi-Turn de Agentes

Caveman é uma skill que instrui o modelo a comprimir o output usando abreviações e formatos concisos durante sessões de agente. O impacto em sessões multi-turn longas é de 40-45% de redução no output gerado.

O valor específico do Caveman está em agentes com muitos steps. Cada step gera output que vira input do próximo step — o output de um step ontem é o contexto de hoje. Se o modelo está gerando respostas verbose quando uma resposta curta teria o mesmo valor informacional, você está carregando esse custo em cascata ao longo de toda a sessão.

Quando Vale

Sessões multi-turn longas com agentes autônomos. O custo de ativar a skill é amortizado rapidamente quando a sessão tem dezenas de steps, cada um carregando o histórico anterior.

Quando Não Vale

Queries isoladas ou sessões curtas. O overhead de ativar a skill e o custo cognitivo do modelo manter o modo comprimido não se pagam em interações únicas. Também não vale quando o output precisa de formatação rica para exibição ao usuário final — Caveman vai comprimir exatamente o que o usuário deveria ver.

---

3. RTK — Para Pipelines com Saída de Terminal

RTK (Runtime Token Kompressor) é uma solução específica para um problema específico: agentes que executam comandos de terminal frequentemente recebem outputs enormes que entram no contexto — logs de build, resultados de test runners, outputs de linters, stacktraces completos.

Um único npm run build em um projeto grande pode gerar megabytes de output. Passar tudo isso pro contexto do LLM é desperdício puro na maioria dos casos — o agente precisa de alguns indicadores de sucesso ou falha e talvez as primeiras linhas de erro, não o log completo de cada arquivo processado.

RTK atua como proxy entre o terminal e o LLM, aplicando compressão inteligente: mantém o que importa (status, erros, warnings relevantes), descarta repetição e verbosidade desnecessária. O impacto em pipelines com output intensivo de terminal pode chegar a 90% de redução de tokens nessa categoria.

Quando Vale

Claude Code, OpenCode, qualquer agente de código que roda comandos de build, test, lint, ou deploy. Se o agente precisa de feedback de ferramentas de linha de comando, RTK é candidato.

Quando Não Vale

Agentes puramente de geração de texto ou de chamadas de API. Se o agente não roda comandos de terminal, RTK não tem onde agir.

---

4. Semantic Caching — Para Workloads com Queries Repetidas

Semantic caching é diferente do prompt caching em um ponto fundamental: prompt caching reduz o custo de processar o mesmo input. Semantic caching elimina a chamada inteira.

O mecanismo: quando uma query chega, você gera o embedding e compara com embeddings de queries anteriores. Se a similaridade semântica está acima de um threshold, você retorna a resposta cacheada sem tocar no LLM. Zero tokens, zero latência de LLM.

Para workloads com alta repetição de queries, a redução de custo pode ser de 60-73%. Mas esse número só aparece em contextos muito específicos: FAQs, chatbots de suporte onde múltiplos usuários fazem variações da mesma pergunta, pipelines batch onde os mesmos documentos são processados repetidamente.

O Que Não Aparece nos Números

Semantic caching tem problemas reais que não ficam evidentes nos benchmarks:

Respostas desatualizadas. Se o estado do sistema mudou desde a query original, você retorna uma resposta incorreta. Para agentes que operam sobre dados mutáveis, isso é um bug silencioso sério.

Calibração de threshold é difícil. Threshold alto demais: muito cache miss, você perdeu o benefício. Threshold baixo demais: retorna respostas de queries similares mas contextualmente diferentes. Encontrar o ponto certo exige experimentação por domínio.

Latência de embedding. Cada query precisa gerar um embedding antes de consultar o cache. Em queries simples e de baixa latência, o custo do embedding pode superar o ganho.

Quando Faz Sentido

Chatbots e produtos onde usuários fazem perguntas similares com frequência. Pipelines batch onde consistência de resposta não é crítica. Não faz sentido para agentes autônomos com tasks únicas ou workloads onde respostas desatualizadas são perigosas.

---

5. RAG em Vez de Full Context — Quando o Corpus Cresce

Esta técnica entra no playbook quando o corpus de contexto fica grande o suficiente para que injetá-lo inteiro no contexto de cada request deixa de ser viável economicamente.

A lógica é direta: se você tem 2 milhões de tokens de documentação e só 5% deles são relevantes para cada query, passar os 2M tokens inteiros no contexto de cada request é cara na proporção de 20:1 versus buscar os 100K tokens mais relevantes via RAG.

O ponto de virada geralmente está em torno de 200K tokens de corpus. Abaixo disso, prompt caching com full context pode ser mais simples e igualmente eficiente. Acima disso, RAG começa a fazer sentido puramente pela economia de tokens.

Quando Vale

Corpus grande (mais de 1M tokens), queries localizáveis (a resposta está num subconjunto específico do corpus), e corpus que muda com frequência (invalidando caches de contexto estático).

Quando Não Vale

Corpus pequeno onde caching é mais simples e igualmente eficiente. Queries que genuinamente precisam de contexto amplo do corpus inteiro — aqui, retrieval vai entregar respostas piores do que full context.

---

6. TokenSave — Para Agentes de Código em Repos Grandes

TokenSave é uma ferramenta específica para agentes que trabalham em codebases grandes. O problema que ela resolve: quando um agente precisa entender um repo, o processo natural é ler arquivos, explorar estrutura de diretórios, listar conteúdos — gerando uma quantidade enorme de tokens de overhead de descoberta.

TokenSave indexa o repo e serve como MCP server, permitindo que o agente consulte informações sobre o código de forma muito mais eficiente do que leitura direta de arquivos. O impacto em repos grandes (mais de 50K LOC) pode ser de 60-80% de redução no overhead de descoberta de codebase.

Quando Vale

Agentes de código trabalhando em repos grandes, especialmente quando as tasks envolvem descoberta e navegação (refatoração, análise de impacto, geração de código que depende de padrões existentes).

Quando Não Vale

Repos pequenos onde a leitura direta de arquivos é eficiente. Agentes com tasks muito localizadas onde o overhead de descoberta já é baixo.

---

Como Monitorar Antes de Virar Problema de FinOps

A melhor intervenção é preventiva. Esperar o budget acabar na quinta-feira para agir é a abordagem mais cara possível.

LangSmith é a ferramenta mais completa para monitoring de pipelines LLM. Exibe KV cache hit rate por camada, tokens de input versus cache read versus output, custo por trajectory de agente, e latência detalhada. Se você está rodando agentes em produção com qualquer volume, LangSmith deveria ser parte do stack.

Anthropic Console mostra uso por modelo, por API key, e por período. Útil para visão macro mas não tem granularidade de trajectory.

OpenAI Usage Dashboard é similar — bom para visão de custo agregado, menos útil para diagnóstico de onde o custo está vindo.

Métricas Para Acompanhar Semanalmente

• KV cache hit rate: objetivo acima de 70%. Se está abaixo de 50%, tem algo estruturalmente errado no seu prompt (conteúdo dinâmico no lugar errado).
• Custo por sessão de agente: identifica rapidamente se algum agente específico está descontrolado.
• Custo por request de API em produção: baseline para detectar regressões quando você mudar prompts.
• Tokens de output vs input por request: se a proporção de output está subindo, alguma coisa está gerando respostas mais longas que o necessário.

Alertas Simples que Funcionam

Configure alertas de custo diário no console do seu provider. Quando o custo diário excede X (calcule baseado no budget mensal dividido por dias úteis), você recebe um aviso antes de atingir o limite.

Simples e eficaz. A maioria dos times que tem problema de budget na quinta-feira não tem alertas configurados.

Separar API Keys por Ambiente

Para devs que usam Claude Code intensamente: configure API keys separadas para desenvolvimento versus produção. Isso serve dois propósitos: você tem visibilidade separada do consumo de cada ambiente, e um agente descontrolado em dev não compromete o budget de prod.

No Claude Code, configure via .env na raiz do projeto com ANTHROPIC_API_KEY apontando para a key de dev. Para produção, key diferente com budget separado.

---

A Hierarquia Resumida

Para facilitar a tomada de decisão, aqui está a sequência de implementação por ROI:

1. Prompt caching → sempre, custo mínimo, ganho máximo. Se você fizer apenas uma coisa desta lista, é essa.

2. Caveman → se você usa agentes multi-turn com muitos steps. O overhead se paga rapidamente em sessões longas.

3. RTK → se seu agente roda comandos de terminal. Redução massiva em output de build/test/lint.

4. Semantic caching → se seu workload tem queries genuinamente repetidas e tolerância a respostas eventualmente desatualizadas.

5. RAG → se seu corpus é grande (>200K tokens) e as queries são localizáveis.

6. TokenSave → se seu agente trabalha em código em repos grandes.

A ordem não é arbitrária. As primeiras técnicas têm o maior impacto com menor esforço de implementação e menores riscos. As últimas têm impacto alto mas em casos de uso mais específicos e com mais complexidade incremental.

---

Conclusão

Usar IA intensamente sem explodir o custo não é sobre usar menos — é sobre usar de forma estruturada. A diferença entre um time que gasta 10x mais do que precisa e um time que opera com eficiência está basicamente em três decisões: como estruturam o prompt (afeta KV cache hit rate), se ativaram prompt caching (afeta 77-80% do custo de input), e se têm monitoring em place para detectar problemas antes que virem crises de budget.

Comece pelo mais simples: estruture o prompt com estático antes de dinâmico, ative prompt caching, configure alertas de custo diário. Isso sozinho resolve a maioria dos problemas de budget que aparecem na quinta-feira.

O resto — Caveman, RTK, semantic caching, RAG, TokenSave — você adiciona conforme mede e identifica onde o custo ainda está alto. Não implemente tudo de uma vez. FinOps de LLM é iterativo, como qualquer engenharia de produção séria.

---

Fontes:

• SiliconAngle — FinOps AI Goes Beyond Token Economics as Agentic Costs Emerge
• Spheron — Context Engineering: Production AI Agents, KV Cache e Long Context
• TensorMesh — Agent Skills, Caching, CacheBlend e LLM Cache Hit Rates
• LangChain — Deep Agents Prompt Caching
• CallSphere — LLM Caching Strategies: Cost Optimization 2026
• Finout — How FinOps Must Evolve for the Agentic Era of AI