No meu primeiro mês rodando agentes em volume real, queimei $1.400 — e a maior parte foi desperdício. Não foi o modelo pensando intensamente em problemas difíceis — isso é dinheiro bem gasto. Foi o reenvio do mesmo prompt de sistema de 40K tokens sem cache em cada requisição, executando tudo no esforço máximo e usando Opus para buscar arquivos. Vazamento puro.
O objetivo não é tornar seu agente mais barato tornando-o mais burro. Qualquer um pode mudar para um modelo menor e chamar isso de controle de custos. O objetivo é cortar o desperdício e manter a inteligência onde ela importa. Veja onde o dinheiro realmente vai e como eu tampo cada vazamento.
Cache de prompt é a alavanca mais importante
Se você está rodando um agente com um grande prompt de sistema estável e conjunto de ferramentas, e seu cache_read_input_tokens é zero, você está jogando dinheiro fora. O cache é uma correspondência de prefixo — a API armazena em cache o prompt renderizado até um ponto de interrupção, e as leituras custam aproximadamente um décimo do preço de entrada total.
O problema: qualquer alteração de byte em qualquer lugar no prefixo invalida tudo depois dele. O assassino clássico é um timestamp no prompt de sistema.
system = f"You are an agent. Current time: {datetime.now()}" # cache dead on arrival
Esse datetime.now() faz com que cada requisição tenha um prefixo único. Nada é armazenado em cache. Mova o conteúdo volátil — timestamps, IDs de requisição, a pergunta real — para o final, após seu último ponto de interrupção de cache. Mantenha o prompt de sistema e a lista de ferramentas congelados e com bytes idênticos.
Como saber se está funcionando: verifique usage.cache_read_input_tokens em requisições repetidas. Se for um número grande, você está fazendo cache. Se for zero, compare dois prompts renderizados e encontre o byte que está mudando. É sempre algo bobo — um dump JSON não ordenado, um UUID, uma data. Em uma sessão longa de agente, esta é a diferença entre uma execução de $4 e uma de $0,40, e não muda nada na qualidade da saída. Dinheiro grátis.
Ajuste o esforço por rota, não maximize tudo
O parâmetro effort controla com que intensidade o modelo pensa. O instinto é cranear para max em todo lugar para que o agente seja o mais inteligente possível. Instinto errado. Nos modelos Opus atuais, high é o ponto ideal para a maioria dos trabalhos, e max frequentemente apenas queima tokens extras em excesso de reflexão com retornos decrescentes.
Mais importante: nem todo passo em um loop de agente precisa do mesmo poder cerebral. Um passo de classificação, uma decisão de "em qual arquivo devo olhar", um portão sim/não — esses funcionam bem em low ou medium. Reserve high e xhigh para o raciocínio realmente difícil e o planejamento de longo horizonte.
# cheap gate
client.messages.create(model="claude-opus-4-8", output_config={"effort": "low"}, ...)
# the real work
client.messages.create(model="claude-opus-4-8", output_config={"effort": "high"}, ...)
Executei uma varredura de esforço no meu próprio conjunto de avaliação — medium, high, xhigh — e descobri que high correspondeu a xhigh em qualidade para a maioria das minhas rotas com um gasto de tokens notavelmente menor. Você não saberá seus números até medir. Não defina o máximo por medo.
Subagentes para o trabalho barato
Aqui está um truque que é tanto uma jogada de custo quanto uma jogada de cache. Quando você precisa de uma subtarefa barata feita — explorar um diretório, resumir um arquivo, fazer grep em algo — não faça isso inline no seu loop principal caro. Crie um subagente em um modelo mais barato.
Por que também é uma vitória de cache: mudar de modelo no meio de uma conversa invalida seu cache, porque os caches têm escopo de modelo. Se você baixar seu loop principal de Opus para Haiku para um grep e voltar, você invalidou seu cache de prefixo duas vezes. Um subagente mantém o loop principal em um modelo e um cache, enquanto o trabalho barato acontece separadamente no Haiku. Claude Code faz exatamente isso — seus subagentes Explore rodam no Haiku precisamente por essa razão.
Edição de contexto e compactação para execuções longas
Sessões longas de agente acumulam resultados de ferramentas obsoletos e blocos de pensamento antigos. Em cada turno, você reenvia tudo isso ao preço de entrada completo. Duas ferramentas resolvem isso.
A edição de contexto limpa resultados antigos de ferramentas da transcrição antes que o modelo os veja. A compactação resume o histórico no lado do servidor quando você se aproxima da janela. São diferentes — a edição poda, a compactação condensa — e agentes longos frequentemente usam ambas. A economia se compõe: uma sessão de 40 turnos que reenviaria 200K tokens de saída de ferramenta morta em cada turno, em vez disso, envia um resumo compacto.
Um problema que morde todos com compactação: acrescente o response.content completo de volta em cada turno, não apenas o texto extraído. O estado de compactação vive nesses blocos de conteúdo. Extrair apenas para texto e você o perde silenciosamente, e seus custos voltam a subir enquanto você se pergunta por quê.
Observe o número certo
Última coisa. Ao depurar custos, não olhe apenas para input_tokens. O total real é input_tokens + cache_creation_input_tokens + cache_read_input_tokens. Já vi pessoas entrarem em pânico porque um agente de longa execução mostra apenas 4K input_tokens e assumir que algo está quebrado — não, o restante foi servido do cache. Esses 4K são o restante não armazenado em cache. Some os três ou você está lendo o medidor errado.
Nada disso torna seu agente mais burro. Cache é gratuito. O ajuste de esforço mantém o poder cerebral onde conta. Subagentes colocam trabalho barato em modelos baratos. A jogada burra é a que parece inteligente: mudar para um modelo mais fraco em todo lugar e assistir a qualidade afundar para economizar alguns dólares. Corte o desperdício primeiro. O desperdício é enorme, e está escondido em um timestamp que você esqueceu.