Como gastar muito menos tokens com IA e otimizar o contexto dos seus agentes

Se você usa agente de IA no dia a dia, seja pra código ou pra operação, tem uma conta silenciosa subindo todo mês. E quando as ferramentas começaram a repassar o custo do uso intensivo de agentes, a reação de quase todo mundo foi a mesma, cancelar na hora e sair procurando alternativa mais barata.

Eu fui por esse caminho e não achei nada que resolvesse de verdade, porque o problema não estava na ferramenta. A conta do uso pesado de agentes chegou pra ficar, e quem paga somos nós. A boa notícia é que dá pra cortar esse gasto quase pela metade sem trocar de modelo, só mudando a forma como o agente trabalha. É disso que eu quero falar aqui.

O agente não é burro, você que não deu estrutura pra ele

Quando um agente começa a mexer num projeto, ele precisa se orientar. Se você não der estrutura, ele explora à vontade: abre um arquivo, lê inteiro, abre outro, lê inteiro. Cada arquivo que entra no contexto é um arquivo que ele reprocessa em toda chamada seguinte. O custo não é só o de agora, ele é cumulativo.

O maior vilão está em deixar o agente puxar conteúdo desnecessário pro contexto. O modelo raramente é o problema, o desperdício é. E a regra pra resolver isso é simples, filtrar antes de ler.

A regra que corta a conta: filtrar antes de ler

Pra entender na prática, vale conhecer dois comandos que parecem iguais e são bem diferentes.

O glob acha arquivo pelo nome, com aquela sintaxe de asterisco e interrogação que você já usa no terminal. Ele devolve só uma lista de caminhos, custo quase zero de token. Já o grep procura conteúdo dentro dos arquivos, linha a linha, e devolve apenas o que casa com o padrão, nunca o arquivo inteiro.

A diferença no bolso é brutal. Ler um arquivo de oitocentas linhas custa por volta de seiscentos tokens. Um grep no mesmo arquivo pra achar uma função específica custa uns vinte. Quem trabalha com Windows Forms sente isso na pele, um arquivo de formulário passa de mil linhas fácil, e eu já peguei um com mais de seis mil. Jogar isso inteiro no contexto sem precisar é dinheiro pela janela, seja qual for o modelo.

A hierarquia que economiza

Pensa como quem procura um endereço, primeiro o mapa, depois a rua, depois a casa:

• Ache os arquivos pelo nome, com glob ou find.
• Descubra quais deles têm o termo, com grep -l.
• Localize a linha exata, com grep -n.
• Leia o arquivo inteiro só se realmente precisar da estrutura completa.

Eles já fazem isso, só que pra eles, não pra você

Vale ser honesto, os agentes já usam glob, grep e leitura de arquivo hoje. Isso não é novidade pra eles. O detalhe é que fazem de um jeito eficiente pro objetivo deles, que é entender o projeto, sem filtro, sem critério de quando parar de explorar. O agente resolve o problema dele e quem paga a conta é você.

E é aí que entra a virada.

A virada: gere a ferramenta uma vez, use pra sempre

A ideia central é usar a IA pra gerar a ferramenta uma única vez, salvar, e nas próximas você executa sem gastar token nenhum. Em vez de pedir pra IA resolver a mesma tarefa repetitiva toda vez, você pede pra ela criar um script que resolve, e depois é só chamar. A IA fica com a parte criativa, e a lógica pesada (busca, processamento, varredura do projeto) acontece fora do contexto. Você entrega pra IA o resultado já pronto, e não o problema cru.

Na prática isso vira uma pasta tools/ no projeto, com scripts feitos sob medida pro seu contexto, que o agente usa em vez de explorar às cegas. E tem um detalhe que rende ainda mais que os scripts: um CLAUDE.md bem escrito. É o esforço de maior retorno de todos, porque orienta o agente antes dele dar o primeiro passo.

As quatro ferramentas que cortam o gasto

Cada script resolve um problema específico de consumo de contexto:

• search_symbol: é o grep já configurado pro seu projeto, sabendo o que ignorar (node_modules, bin, obj, dist, migrations). Você chama com um termo e ele devolve só o que importa, com o número da linha e duas linhas de contexto. O agente não precisa adivinhar onde buscar.
• find_usages: parecida, mas busca a palavra inteira, pra não trazer falso positivo. Buscar “Order” sem isso traz “OrderStatus”, “OrderController” e “OrderService” junto. Existe uma opção tecnicamente melhor, o LSP, que entende o código de forma semântica como o compilador, mas hoje os agentes não têm integração nativa com ele na maioria dos fluxos, e a saída dele é cara em token, então o grep resolve bem por agora.
• list_changed_files: roda um git diff, filtra as pastas de build e diz na hora onde o código mudou, em vez de o agente varrer o projeto todo pra descobrir.
• summarize_file: devolve as primeiras quarenta e as últimas vinte linhas de um arquivo. Pra maioria dos casos isso já entrega os imports, a declaração da classe e os principais métodos, e você decide se vale ler o resto antes de gastar token lendo tudo.

A evidência, com número na mesa

Pra não ficar na teoria, rodei os dois cenários no mesmo projeto, com a mesma tarefa, mapear todos os lugares onde um método é chamado.

Quase sessenta por cento menos token, com oitenta e um por cento menos chamadas. Agora vem a parte honesta, porque é ela que dá credibilidade. A análise sem ferramentas foi mais profunda, ela achou que existiam vários métodos com o mesmo nome resolvendo pra tipos diferentes, e mapeou exatamente quais pontos seriam afetados. A versão com ferramentas mapeou os arquivos certos, mas não chegou nesse nível semântico.

Isso tem nome, é o trade-off entre eficiência e profundidade. E a solução não é abandonar as ferramentas. Use elas como primeiro filtro, deixa o find_usages mapear, roda o summarize_file em cada resultado, e só então abre por completo os que realmente precisam. Você troca trinta e oito chamadas por umas doze, não por sete, mas com muito menos ruído no contexto.

O que isso ensina pro seu negócio

Aqui está o ponto que vai além do código. O gargalo nunca esteve na inteligência do modelo, esteve na falta de arquitetura em volta dele. A pessoa troca de ferramenta achando que resolve, e o desperdício continua, porque o agente segue trabalhando no braço.

É a mesma lógica de sempre, primeiro o trilho, depois o trem. Você monta as ferramentas certas pro seu contexto uma vez, e o agente passa a andar nesse trilho gastando uma fração do que gastava. Sem plugin genérico, sem instalar algo pensado pra uma realidade que não é a sua, só arquitetura sob medida. A ferramenta é sempre o exemplo, a arquitetura é o que faz a conta fechar.

Conclusão

Economizar token é pura inteligência de sistema. Quando você entrega ao agente o resultado já filtrado, o custo cai, a resposta melhora e a sua operação para de depender de sorte. Isso é o que separa quem paga caro pra brincar de IA de quem construiu uma máquina que escala barato.

Se você quer montar uma arquitetura de IA que gera resultado sem queimar dinheiro à toa, agende seu diagnóstico gratuito de Raio-X de Autonomia.

Este artigo foi adaptado do texto “Menos tokens, mais código: como otimizar o contexto dos seus agentes”, de Mr Paiva, publicado no Medium. Veja também outros guias no nosso Cérebro Digital.