Aprenda 3 técnicas eficientes para reduzir o consumo de tokens no Claude Code e Codex. Otimize custos, melhore a latência e aumente a eficiência dos seus agentes de codificação com dicas práticas da AutoScout24.
Este artigo foi escrito por Slavik Shynkarenko – Construtor. Líder. Chefe de Engenharia de Plataforma na AutoScout24 🇪🇺 & TRADER Corp. 🇨🇦 – Conecte-se no Linkedin
No Grupo AutoScout24, Codex e Claude Code já fazem parte do trabalho de engenharia do dia a dia. Equipes, e cada vez mais colegas não-técnicos, usam agentes de codificação para exploração, programação e automação. Como Chefe de Engenharia de Plataforma, me preocupo com a conta que vem com esse ritmo: minha equipe precisa tornar o uso de LLMs transparente, padronizar as otimizações que funcionam e manter os agentes eficientes sem atrasar ninguém.
A parte surpreendente é de onde vem grande parte desse custo. Não do modelo pensando em um recurso difícil ou encontrando um bug sutil: essa é a parte útil. O desperdício é o log de teste npm test de mil linhas enviado ao modelo para que ele encontre uma única asserção com falha. Ou os cinco arquivos despejados no contexto porque ninguém tinha certeza de onde a função relevante estava. É um modelo de ponta escrevendo um docstring que um modelo muito mais barato teria tratado igualmente bem.
Tokens são a unidade de custo, latência e capacidade de contexto. Cada token desnecessário na janela de contexto é um token que o modelo não pode gastar no problema real. Reduzir o uso de tokens não é sobre economizar centavos. É sobre preservar contexto para o trabalho que realmente importa: mais barato de executar, resposta mais rápida e mais fácil de manter na tarefa. Em dezenas de equipes, descobrimos que três técnicas capturam a maior parte do valor, e cada uma é pequena o suficiente para um engenheiro adotar sem mudar todo o seu fluxo de trabalho.
Técnica 1: Pare de alimentar o modelo com ruído
A primeira regra da economia de tokens: você paga por tudo que o modelo lê e escreve de volta. Um primeiro passo útil é separar o sinal real do ruído rotineiro do desenvolvimento.
Veja uma única interação do agente em um loop de desenvolvimento normal. O agente executa git status e recebe 80 linhas de arquivos não rastreados. Ele executa a suíte de testes e obtém uma parede de testes bem-sucedidos em torno de uma única asserção com falha. Ele executa uma build e lê cada aviso de dependência emitido desde 2021. O modelo processará tudo isso, a custo total de token, para extrair um ou dois fatos.
Você pode reduzir esse tráfego em ambos os lados.
Apare a saída da ferramenta: RTK
O RTK fica entre seu agente e os comandos que ele executa. Ele envolve comandos ruidosos como git status, npm test e cargo build, então reduz a saída para o que realmente importa antes que ela atinja o modelo. O teste com falha sobrevive. As 200 linhas da estrutura de teste bem-sucedida ao redor não.
A parte útil é o quão pouca disciplina isso exige do agente. No Claude Code, rtk init --global instala um hook PreToolUse que reescreve comandos Bash de forma transparente. O agente digita git status, o hook o transforma em rtk git status, e o modelo nunca precisa saber.
Enquanto escrevo isso, o Codex funciona de forma diferente na configuração atual do RTK. O RTK documenta o Codex como uma integração baseada em instrução: rtk init --codex cria ou corrige AGENTS.md para que o Codex aprenda a preferir rtk <comando> para saída de shell ruidosa. Portanto, você não precisa escrever manualmente a configuração do hook do Codex para o caminho normal do RTK; execute o instalador para o agente que você usa, reinicie-o e continue trabalhando. O ponto é o mesmo: menos texto entrando na janela de contexto com muito pouca mudança no fluxo de trabalho. Na prática, vemos uma redução de 60% a 90% na saída do loop de desenvolvimento, exatamente o tráfego de alta frequência e baixo valor que vale a pena comprimir.
O RTK também mantém a pontuação. rtk gain mostra o total acumulado de tokens salvos, e rtk discover examina transcrições em busca de comandos ruidosos que você ainda não envolveu. Essa medição é importante, porque a otimização de tokens fica muito mais fácil quando você pode ver quais mudanças realmente movem os números.
Apare a própria prosa do modelo: Caveman
Tokens de saída são fáceis de ignorar porque parecem “apenas a resposta”, mas são caros e adicionam latência. Deixado sozinho, um modelo falante irá prefixar o trabalho com “Ótima pergunta”, reafirmar seu diff de volta para você e encerrar com um resumo do que acabou de fazer. Isso pode ser agradável em um tutorial. Em um loop de codificação, é frequentemente um preenchimento pago.
O modo Caveman é a versão deliberadamente direta da correção. É uma habilidade que comprime o estilo de comunicação do modelo, eliminando artigos, cortesias e preenchimentos, preservando o conteúdo técnico. Em vez de:
O bug que você está vendo é provavelmente causado pela verificação de expiração do token, que parece estar usando uma comparação estrita de menor que.
você obtém:
Bug no middleware de auth. Expiração de token usa `<`, deveria ser `<=`. Correção:
Os usuários relatam reduções significativas no uso de tokens de saída, particularmente em sessões de codificação iterativas onde os agentes tendem a produzir explicações detalhadas. O estilo não é para todos, mas o princípio subjacente é útil mesmo se você preferir um tom mais suave.
Você não precisa de uma ferramenta dedicada para a versão mais suave. Algumas linhas em CLAUDE.md ou AGENTS.md vão longe:
## Estilo de saída
- Responda em forma de diff unificado. Sem reescritas de arquivo completo, a menos que seja solicitado.
- Sem preâmbulo, sem resumo final do que você acabou de fazer.
- Para perguntas de pesquisa, responda em 10 linhas ou menos, a menos que eu peça profundidade.Também vale a pena definir controles de saída explícitos. No Claude Code, CLAUDE_CODE_MAX_OUTPUT_TOKENS limita a maior parte da saída de resposta. No Codex, model_verbosity = "low" instrui os modelos da família GPT-5 a serem concisos. Não é um limite rígido, mas reduz a prosa padrão. Se você usa ferramentas MCP, seus próprios limites de saída também importam, porque uma resposta de ferramenta excessivamente generosa pode inundar o contexto antes que o agente tenha tomado uma única decisão.
Ponto chave desta técnica: pare de pagar por palavras que não carregam informações valiosas.
Técnica 2: Dê ao agente um mapa, não uma lista telefônica
A segunda fonte de desperdício é mais sutil. Ela aparece quando o agente não sabe onde algo está, então ele vai procurar. Para um LLM, “procurar” geralmente significa ler.
Imagine pedir a um agente para mudar como a autenticação funciona. Ele não tem seu modelo mental do código-fonte. Ele busca por auth, abre seis arquivos para ver qual importa, lê cada arquivo de cima a baixo, segue uma importação para um sétimo arquivo, e só então começa a entender a forma da mudança. Cada leitura é entrada a preço total, e grande parte dela é irrelevante.
O que o agente precisava era de um mapa, não de uma caça ao tesouro.
A abordagem do grafo
Uma ferramenta de grafo de código analisa seu repositório uma vez, geralmente com Tree-sitter, e constrói um modelo estrutural dele: quais funções chamam quais, o que depende do quê, onde os testes estão e quão amplo é o raio de impacto de uma mudança. Ela então expõe esse modelo ao agente, geralmente através de MCP. Em vez de ler dez arquivos para descobrir que validateToken é chamado de três lugares e testado em um, o agente pergunta ao grafo e recebe a resposta em algumas centenas de tokens.
Essa é a troca: consultas estruturadas em vez de leituras por força bruta. Um “quem chama isso?” direcionado substitui uma dispersão de despejos de arquivos. A economia escala com o tamanho do repositório. Quanto maior e mais emaranhado o código-fonte, mais um agente cego teria que ler, e mais o grafo economiza.
Na AutoScout24, experimentamos várias ferramentas. Uma que uso diariamente é o code-review-graph, um servidor MCP que mantém um grafo persistente e incremental, e se reconstrói automaticamente ao salvar o arquivo. O hábito que faz valer a pena é uma regra simples em CLAUDE.md ou AGENTS.md:
## Exploração de código
Antes de qualquer Grep/Glob/Read, chame as ferramentas do grafo de código:
- semantic_search_nodes para encontrar funções/classes por intenção
- get_impact_radius antes de edições com um amplo raio de impacto
- detect_changes + get_review_context para revisão de código
Volte para Grep/Read apenas quando o grafo não puder responder.Sem esse empurrão, os agentes tendem a recorrer aos hábitos de grep-e-leitura. Com ele, o contexto estrutural torna-se o primeiro movimento e a leitura de arquivos torna-se o plano de fundo. Essa ordenação é de onde vem a maior parte do benefício.
Escolha a versão que se adapta ao seu repositório
code-review-graph é o que eu uso, mas é uma opção em um campo em rápida evolução. A escolha certa depende de que tipo de “compreensão” seu agente precisa.
- Ferramentas estruturais / de grafo de chamada respondem “como este código se conecta?”: chamadores, chamados, dependências, impacto. Serena usa servidores de linguagem (LSP) para dar ao agente ir-para-definição e encontrar-referências precisos. O mapa de repositório do Aider constrói um resumo estrutural classificado para que o agente veja o esqueleto de um grande projeto sem carregar cada arquivo. O Glean do Meta é a opção pesada para quando você opera em escala séria.
- Ferramentas de busca semântica respondem “onde está o código que significa isso?” usando embeddings em vez de estrutura. O Claude Context é uma opção popular de código aberto aqui. Ele relata reduções significativas de tokens ao recuperar fatias relevantes em vez de arquivos inteiros. Isso é útil quando a intenção importa mais do que grafos de chamada.
- Ferramentas de empacotamento de repositório respondem “me dê o projeto inteiro, mas bem empacotado”. O Repomix achata um repositório em um único arquivo otimizado para IA, respeitando
.gitignoree contando tokens enquanto processa. É menos cirúrgico que um grafo, mas é uma maneira de um comando para entregar ao modelo uma visão deduplicada do projeto.
Você não precisa se preocupar com a escolha perfeita. O ponto prático é válido para todas as ferramentas: qualquer índice estruturado supera as leituras cegas de arquivos. Comece com a categoria que corresponde à sua dor, seja confusão com grafos de chamada, buscas semânticas “onde está?” ou a necessidade ocasional de empacotar um repositório inteiro no contexto. Conecte uma ferramenta primeiro. Adicionar uma segunda raramente compensa até que a primeira faça parte do fluxo de trabalho.
Técnica 3: Use o modelo certo para o trabalho
Usar o modelo mais forte para cada tarefa parece seguro, mas muitas vezes é a versão cara da preguiça. Um modelo de ponta vale a pena para trabalhos ambíguos e de alto risco. É desperdício para edições mecânicas, classificação de logs ou uma limpeza de documentação de arquivo único.
Modelos maiores são mais caros por token e o argumento de desempenho é igualmente importante. Um modelo menor e mais rápido geralmente retorna uma resposta simples mais cedo, com menos deliberação que você não precisava em primeiro lugar.
Portanto, a jogada é direcionar tarefas para o modelo que se adequa a elas.
O mapa de roteamento
Os nomes específicos dos modelos mudarão. O princípio não: use modelos pequenos para trabalhos de alto volume e baixa ambiguidade, e reserve modelos de ponta para tarefas onde erros são caros.
Na prática, a divisão se parece com isso:
- Modelos pequenos/rápidos (Claude Haiku, GPT mini) -> triagem, testes simples, edições de documentação, classificação de logs, refatorações de arquivo único. Alto volume, baixa ambiguidade.
- Modelos de ponta ou especializados em codificação (Claude Sonnet/Opus, GPT-5) -> mudanças em múltiplos arquivos, revisões difíceis, migrações, qualquer coisa onde uma decisão errada seja cara. Baixo volume, alto risco.
A orientação do Codex no momento da escrita recomenda um modelo de ponta como gpt-5.5 para codificação complexa e pesquisa, e uma variante *-mini mais rápida para tarefas mais leves e subagentes. Esses nomes envelhecerão. O hábito de roteamento é a parte que deve permanecer.
Use subagentes e perfis deliberadamente
O Claude Code tem um fluxo de trabalho de subagente maduro: mantenha um modelo capaz como orquestrador, depois delegue trabalho delimitado a especialistas mais baratos. Um subagente triage fixado no Haiku pode classificar uma falha e devolver o próximo passo. Um subagente review-diff pode inspecionar um patch e retornar apenas descobertas concretas. Cada especialista executa no menor modelo que pode fazer o trabalho, com um orçamento de saída restrito:
name: triage
description: Classifique um problema ou falha de teste em um bucket conhecido
model: haiku
tools: Read, Grep
Você faz a triagem. Responda em 120 tokens ou menos com: bucket, confiança, próximo passo.O Codex suporta o mesmo padrão através de subagentes também. Agentes personalizados vivem como arquivos TOML em ~/.codex/agents/ ou .codex/agents/, e eles podem substituir as mesmas configurações de uma sessão normal do Codex: modelo, esforço de raciocínio, modo sandbox, ferramentas, servidores MCP e instruções. Um especialista em documentação pode parecer com isso:
name = "docs_researcher"
description = "Verifique APIs, opções e comportamento específico de versão antes de edições de documentação."
model = "gpt-5.4-mini"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"
developer_instructions = """
Use documentação e evidências locais antes de fazer afirmações.
Retorne respostas concisas com links ou referências a arquivos.
Não edite código da aplicação.
"""Perfis são úteis para roteamento manual no Codex. Nas versões atuais da CLI do Codex, os perfis são sobreposições de configuração separadas, como ~/.codex/cheap.config.toml e ~/.codex/frontier.config.toml, selecionados com --profile.
~/.codex/cheap.config.toml:
model = "gpt-5.4-mini"
model_reasoning_effort = "low"
model_verbosity = "low"~/.codex/frontier.config.toml:
model = "gpt-5.5"
model_reasoning_effort = "high"
model_verbosity = "medium"Então escolha o perfil no limite da tarefa:
codex --profile cheap "regenerate o changelog"
codex --profile frontier "planeje a migração da autenticação"O botão importante não é apenas o modelo. O esforço de raciocínio também importa. Mesmo dentro de uma família de modelos, tarefas simples não precisam de raciocínio profundo. Reduzir o raciocínio para trabalhos diretos economiza tokens; aumentá-lo para trabalhos difíceis gasta-os onde eles são mais propensos a valer a pena.
A mudança de mentalidade é parar de escolher um modelo para uma sessão inteira. Uma sessão é uma mistura de tarefas com risco e dificuldade muito diferentes. Pague de acordo.
Conclusão
As técnicas que mencionei são fáceis de implementar. Nenhuma plataforma de recuperação, nenhum projeto de ajuste fino, nenhuma grande reescrita do seu fluxo de trabalho de desenvolvedor. Três movimentos práticos cobrem a maior parte do desperdício:
- Apare o ruído. Envolva a saída da ferramenta com RTK, comprima a prosa do modelo e defina controles de saída sensatos.
- Dê ao agente um mapa. Use um grafo de código ou outro índice estruturado para que consultas direcionadas substituam leituras de arquivo por força bruta.
- Direcione para o modelo certo. Use modelos de ponta para decisões difíceis, especialistas mais baratos para trabalho delimitado e esforço de raciocínio que corresponda à tarefa.
O tema comum por trás de todos os três é simples: o raciocínio geralmente não é a parte cara. O movimento de informação é. Cada linha de log desnecessária, leitura de arquivo e resposta prolixa compete com o problema real que você está tentando resolver. Reduza o ruído, melhore a navegação e ajuste o modelo à tarefa. O resultado é menor custo, menor latência e, muitas vezes, melhores resultados.
Se você levar um hábito, que seja a medição. Observe sua taxa de acerto de cache e seu custo por PR assistido por IA mesclado mês a mês. Se ambos tenderem na direção certa, amplie o que funciona. A eficiência de tokens não deve ser uma limpeza única, mas uma disciplina fácil de seguir.
Sobre o autor
Slavik Shynkarenko
Construtor. Líder. Chefe de Engenharia de Plataforma na AutoScout24 🇪🇺 & TRADER Corp. 🇨🇦
Conecte-se no Linkedin
