Como evitar o desperdício e preservar os tokens

Se você já estourou a cota de API no dia 4 do mês e ficou olhando pra tela sem entender como queimou crédito antes da primeira semana acabar, este post é pra você.

Não estou falando de "usar IA demais". Estou falando de arquitetura. De como cada "oi" que você dá pro agente carrega um lastro invisível de contexto acumulado e te cobra em silêncio. O problema quase nunca é só o modelo ser caro. O problema é você pagar para reenviar as mesmas instruções, os mesmos arquivos e as mesmas regras dezenas de vezes no mesmo dia, como se cada turno fosse a primeira conversa do zero.

A faísca veio de uma discussão em uma das comunidades de AI que participo, onde um dev que orquestra vários agentes em paralelo, abriu a pergunta que muita gente sente e poucos formulam direito: como preservar tokens (a unidade de texto que o modelo processa e pela qual você é cobrado) e evitar saída genérica, o tal slop (aquela resposta inflada que o modelo cospe quando não tem direção clara)? As respostas de vários outros membros vieram e formaram, juntas, um manual não escrito de operação de agentes. Peguei esses princípios, digeri com a dor de quem já queimou crédito em loop de debugging, e montei o que vem a seguir. No meio do caminho, ainda cruzei com o pack de skills do Hermes que instalei recentemente. Algumas peças dali encaixam direto nesse problema de custo e qualidade.

Mas antes das dicas, uma analogia que ajuda a enxergar o custo real.

O custo escondido não é o modelo caro. É o replay de contexto.

Pensa num restaurante onde, a cada novo prato que o cliente pede, o chef tem que ouvir de novo o cardápio inteiro, as restrições alimentares, o histórico de pedidos da mesa, quantas pessoas estão sentadas e o estilo da casa. O cliente pede uma água. O chef ouve tudo de novo. O cliente pede a sobremesa. Tudo de novo.

É exatamente assim que a maioria dos agentes funciona. Cada turno reenvia o contexto acumulado inteiro: system prompt, ferramentas registradas, regras de identidade, histórico de mensagens. Tudo. O token não é só a sua pergunta. É a pergunta mais o lastro.

Uma conversa com 50 mensagens não custa 50 vezes o preço de uma pergunta isolada. Custa muito mais, porque a mensagem 50 carrega as 49 anteriores junto. E o pior: boa parte desse contexto repetido nem é relevante para a tarefa atual.

É aqui que entra o primeiro princípio.

Fatie no planejamento, não no desespero

A prática mais comum quando o chat "fica grande demais" é criar um chat novo e jogar um resumo mal-acabado das decisões anteriores. Um membro deu o melhor enquadramento que eu já vi sobre isso: divida por workstream durável (linha de trabalho estável), não porque o chat encheu.

Traduzindo: em vez de um chatão único que vai de "bora fazer o projeto" até "commita aí", você tem:

• um chat só de arquitetura
• um chat por feature
• um chat de testes
• um chat de review

Cada chat recebe só os arquivos, critérios de aceite e restrições relevantes para aquela fatia. Nada de carregar o código inteiro do projeto para revisar um controller de 40 linhas. No fim de cada sessão, um handoff curto (a passagem de bastão entre etapas): decisões tomadas, arquivos alterados, riscos abertos, próxima tarefa.

A spec do projeto (ou game plan, como é chamado na comunidade) é o documento único que todos os chats consultam. É estável. Não muda a cada sessão. O chat, ao contrário, é descartável. Quando a fatia termina, ele morre. O que sobrevive são as decisões e os artefatos.

Isso exige disciplina no começo: travar contratos e arquitetura antes de abrir o primeiro chat de feature. Se a fatia que você definiu precisa puxar arquivos ou decisões demais, ela ainda não está pronta. Corte de novo.

O ganho real: cada chat nasce enxuto. Sem arrastar a história de features anteriores que já foram mergeadas. Sem repetir decisões que estão na spec.

Modelo caro no julgamento. Modelo barato no grosso.

Outro ponto que apareceu na discussão e que eu aplico direto: use o modelo mais caro só onde o julgamento realmente importa. Outro membro resumiu bem o setup dele: Codex como orquestrador (quem decide o que fazer) e um modelo mais barato e eficaz no uso dele, tipo GPT-5.6 Terra com raciocínio alto, como motor principal. O dono da comunidade, por outro lado, gosta do Grok 4.5 para review de código, enquanto o grosso do trabalho pesado vai para outros modelos.

O padrão é o mesmo: o modelo premium não precisa escrever boilerplate. Ele precisa estar lá para decidir se a abordagem faz sentido, se o contrato da API está coerente, se o teste cobre o cenário de falha certo. O resto (gerar struct, escrever mock, formatar resposta) vai para o modelo barato ou local.

No Hermes, por exemplo, faz sentido rodar modelos mais baratos (ou locais) para extração e triagem, e deixar o modelo mais caro para crítica, validação e síntese final. O custo cai. A qualidade do julgamento não precisa descer junto.

Pensa de novo no restaurante: você não põe o chef com estrela Michelin para picar cebola. Ele prova o molho, ajusta o tempero, decide o ponto da carne. O resto a brigada resolve.

Wiki estável, chat descartável

Um membro bateu nisso com força: wiki e sistema de memória são a chave. Fatos estáveis (identidade do projeto, estilo de código, decisões arquiteturais, documentação de APIs) vivem na wiki. O chat é um contêiner transitório. Quando a sessão acaba, o raciocínio intermediário morre. Só as conclusões viram fato estável.

Isso evita duas dores: o agente redescobrir a roda a cada sessão, e "aprender" com lixo de sessões passadas. Na prática, depois de uma sessão produtiva, gaste dois minutos salvando decisões na wiki. O Greg cita um brand.md para identidade e tom. O Robert usa build wiki com game plan. Formatos diferentes, mesma função: permanente vs descartável.

Anti-slop: referência real, escopo estreito, identidade clara

Slop é o termo que a comunidade usa para a saída genérica e inflada que o modelo produz quando não tem direção suficiente. O anti-slop opera em três camadas:

Referência real. O autor mencionou algo que parece óbvio mas quase ninguém faz: dar referência visual concreta para o modelo. Se você quer um design, mostre um design de verdade, não descreva com texto. "Faça um site moderno e limpo" produz slop. "Aqui está o layout de referência, use essa paleta, esse espaçamento, essa hierarquia" produz resultado.

Escopo estreito. Um chat, uma responsabilidade. Quando o modelo tem dúvida sobre o que fazer, ele preenche a lacuna com slop. Quando o escopo é cristalino (só o callback de auth, mais testes, mais nada), ele não tem espaço para inventar.

Identidade clara. O brand.md de um deles é o equivalente para agentes do que um style guide é para um time de design. Se o agente sabe exatamente qual é a voz, a paleta, o nível de abstração e as restrições do projeto, ele não desvia. Slop é, no fundo, o modelo tentando agradar quando não sabe o que você quer de verdade.

Skills que protegem o bolso (e a cabeça)

Além da thread de tokens, o pack de skills do Hermes que circulou na mesma comunidade traz três peças que eu olharia com carinho se você opera agente de verdade:

Bouncer. Audita skill antes de instalar. Procura alternativa melhor, caça instrução escondida, roubo de credencial e overlap de trigger. Para quem tem dezenas de skills (eu incluso), isso é higiene barata. Skill ruim não só arrisca segurança: ela engorda o contexto e compete com as boas no momento errado.

Context Doctor. Pesa o que o agente carrega a cada turno e sugere cortes com recibo. A inspiração explícita é o corte agressivo de system prompt que a Anthropic fez no Claude Code: menos lastro, mesmo resultado. Se a dor é "por que cada oi custa uma fortuna?", esse tipo de ferramenta ataca a causa, não o sintoma.

writing-great-skills (no ecossistema Matt Pocock / writing-for-agents). Não é uma skill que você "roda" o tempo todo. É a regra que o agente lê quando escreve skill nova. Skill bem escrita é curta, acionável e sem teatro. Skill mal escrita é slop permanente no prompt.

No meu stack, as três fazem sentido em ordens diferentes. Bouncer entra cedo (governança de instalação). writing-great-skills entra no fluxo de criação de skill. Context Doctor entra quando a conta dói ou o agente começa a "viajar" com contexto inchado. Não precisa instalar o mundo inteiro no dia um. Precisa saber o que cada uma corta: risco, ruído ou custo.

Quando dar um passo atrás

Tem situações em que essas otimizações atrapalham mais do que ajudam:

Protótipo rápido. Se você só quer validar uma ideia em 30 minutos, não monte uma arquitetura de 5 chats, spec, wiki e handoff. Um chat único com escopo solto resolve. O custo de setup come o ganho.

Projeto solo pequeno. Se você é o único dev e o projeto tem 3 endpoints, a sobrecarga de gerenciar múltiplos chats é pior que o custo de tokens de um chat único.

Quando a sessão é curta por natureza. Se seu agente resolve cada tarefa em 3 a 5 turnos, o replay de contexto mal aparece na conta. Essas técnicas brilham em sessões longas, com múltiplas features, onde o acúmulo de contexto é o verdadeiro vilão.

A regra: se a conta de API não está doendo, não complique. Mas se está, provavelmente não é só o modelo caro o culpado. É o replay de contexto que você não está vendo.

Trombei com essa discussão num momento em que eu mesmo estava revendo como orquestrar agentes sem torrar crédito em loop. Virou checklist antes de abrir chat novo: a fatia é independente? O handoff está claro? O modelo caro só está aqui para julgar? A wiki tem o que é estável? A skill nova passou por algum bouncer?

Links da thread e do pack de skills nas notas de rodapé.

E você? Como está lidando com o custo de tokens nos seus agentes? Tem alguma técnica de handoff ou fatiamento que funciona melhor no seu stack? Me conta. Estou genuinamente curioso para saber o que mais a comunidade está testando.