Essa semana tenho exercitado muito minha capacidade de começar algo do zero, utilizando o novo normal que é ter uma TUI aberta, determinar requisitos, testar e validar o output. No trabalho, o Claude chegou e tomou conta, ele pode gerar código, gerar teste, ajudar em investigação e criar runbook, tanto que se tornou normal gastar $300, $500 e até $600 dólares em um mês com um uso moderado.
Ao tentar reproduzir o padrão ao qual me acostumei, tive um primeiro choque, eu não tinha mais o mesmo orçamento, portanto precisaria fazer algumas alterações, utilizar o opencode e um modelo chinês era o passo mais óbvio. Lá vou eu, muita pesquisa sobre qual modelo chinês e acabei optando pelo MiMo-2.5 para execução de tasks e o MiMo-2.5 PRO para gerar specs.
Isso me permitia um fluxo de trabalho de um final de semana com uma assinatura de $10 dólares, porém passei a perceber um custo invisível nessa conta, o número de retrabalho sendo feito era altíssimo, a todo momento o trabalho parecia bom mas não chegava nem perto de ser algo tolerável.
Insatisfeito, me questionei se era necessário investir mais, ter o claude? me perguntei, fui atrás de alternativas, testei o Deepseek Flash com sua nova precificação, era lindo ver 120 tk/s mas o retrabalho permanecia e a sensação de não confiar no produto construído também. Logo então, passei a olhar para a OpenAI, que já havia usado no passado e era algo muito distante da eficiência do Claude, me surpreendi pois os modelos estão realmente muito eficientes e entregando um trabalho de qualidade, a essa altura eu mantinha duas assinaturas, $10 do Opencode Go e $20 do ChatGPT Plus, aconteceu que ao passar a utilizar o ChatGPT Plus no Opencode eu consegui consumir todo meu limite mesmo sem ter um produto relevante pronto, e isso me levou a refletir sobre alguns erros;
Tentar fazer tudo ao mesmo tempo
Parece muito óbvio né? Mas se atente ao fundamento disso, estamos plenamente acostumados a seguir um backlog, um OKR, atacar por épicos, quebrar as tarefas abaixo de 8 pontos etc. Mas quem é você quando quem está executando é um agente? Ora, se ele consegue fazer a modelagem do banco e entregar um backend one-shot por que raios eu iria particionar esse trabalho? Ou então, criamos uma conta no linear, pedimos pra um agente gerar o backlog, e em seguida atacar o backlog inteiro.
Nada disso deu certo para mim, e a razão disso é que pela maneira superficial como você acompanha esses resultados, nada está garantido até que TUDO seja feito, isso é o primeiro ralo de tokens e de dinheiro, quando estamos no nosso trabalho nos importamos em validar a task independente da origem do código ser gerado por um humano ou um agente, mas quando é um produto próprio usamos a muleta de que não tem ninguém usando para agir “proativamente” e “ver o resultado final” honestamente para mim isso foi burrice minha, eu só perdi tempo e dinheiro.
Pois então o que fazer? O que funcionou para mim foi usar checkpoints que partem do menor blast radius para o maior, checkpoints esses que irão servir de fundamento para a construção do que estou fazendo, alguns exemplos são
- Tese clara do produto e escopo do MVP fechado
- Modelagem de banco de dados
- Contrato openAPI
- Pleno funcionamento da API integrada ao banco de dados
O foco aqui está em produto, domínio, contrato, persistência, objetivos sólidos e que garantem não apenas uma progressão mas também não cairmos na armadilha de criar interfaces para um produto que sequer está validado.
E repare que eu não estou dizendo que o banco de dados ou o contrato jamais vão mudar, obviamente vão, mas existe uma diferença gigante entre mudar algo que você validou e descobrir depois de 300 mil tokens que banco, backend, frontend e testes foram todos construídos em cima de uma premissa errada.
O agente é extremamente eficiente em amplificar uma decisão. Inclusive uma decisão ruim.
Delegar quality gate exclusivamente para o modelo
É natural que como resposta a uma necessidade de estar fora do loop de desenvolvimento, nossos prompts se tornem recomendações como
- Escreva uma spec para toda mudança
- use TDD
- Rode a suíte de testes para garantir que está tudo funcionando
Somado a isso existem skills, clis e MCPs que vão rodar ferramentas como testcontainer ou playwright para ter a certeza de que tudo está funcionando de ponta a ponta.
Tudo isso pode fazer sentido quando você está rodando o Opus 5 com uma assinatura sob demanda, mas reveja o seu cenário, você realmente acredita que um modelo feito para ser eficiente consegue absorver o planejamento, execução e a validação sob o mesmo prompt? sob a mesma janela de contexto? Se você acredita nisso você está se enganando, o resultado serão testes que você não confia 100% e um modelo extremamente lento, verboso e no fim também medroso porque a cada iteração ele tem que cumprir (quando ele não esquece né) uma série de pre-requisitos que não são a tarefa em questão.
Existe ainda um detalhe que passei a considerar muito mais importante, o mesmo modelo que interpretou o requisito, tomou uma decisão errada, escreveu o código e agora escreve o teste pode simplesmente escrever um teste que valida a interpretação errada que ele teve no começo.
Ou seja, automatizar quality gate não é a mesma coisa que delegar o quality gate para quem gerou o artefato.
Como mitigar esse problema? Primeiro, revise quantas skills e mcp você tem que podem estar atrapalhando o seu agente, talvez a quantidade de instruções que você tem no AGENTS.md que sempre recomenda executar todo o pipeline por exemplo. Tome o controle, desacople geração de verificação, o maior super poder que você pode dar para um agente menor é deixar que ele execute o processo livremente. Para além disso, outra diferença importante, continuar uma conversa não é necessariamente a melhor maneira de transferir contexto. Se uma janela foi usada para discutir e refinar uma spec durante 100 mil tokens, o próximo agente não precisa saber tudo que eu e o modelo discutimos até chegar naquela spec, ele precisa da spec pronta.
Spec pronta, código pronto, contrato pronto, resultado de um teste, esses são artefatos. A conversa que levou até eles é descartável.
Rode os testes de integração você à mão, evite sobrecarregar a janela de contexto do seu agente e ter uma conversa contínua que mistura execução e investigação sobre um detalhe bobo no teste.
Esses passos podem parecer desacelerar mas muito pelo contrário, garantem que você esteja andando na direção correta e com baixo custo extraindo o máximo de eficiência.
Janelas de contexto grandes demais
O novo normal são modelos com janelas de 1 milhão de contexto, e os benchmarks mostrando que os modelos XHIGH, MAX, ULTRA etc. são muito acima de todos os outros, mas e se eu te disser que isso pode ser a armadilha mais perigosa?
Pois então, ter 1 milhão de tokens disponíveis não significa que você deveria manter 1 milhão de tokens como working set da sua task.
Isso parece uma distinção boba mas muda bastante a conta, porque uma janela grande por si só não é o problema, o problema é permitir que uma mesma sessão vá acumulando spec, implementação, logs, output de ferramenta, testes quebrados, tentativas que foram abandonadas e investigações que já acabaram. A cada novo turno você continua carregando uma quantidade cada vez maior de informação que já não necessariamente é útil para a próxima decisão.
Você pode pensar, mas e o tal do cache? Prompt caching ajuda muito nisso, mas ele não faz milagre.
No Claude Code por exemplo, a conversa é reenviada a cada vez que você aperta enter e o cache permite reutilizar o histórico já processado por uma fração do custo. Hoje um cache read custa aproximadamente 10% do input normal, então manter um histórico quente pode deixar uma sessão bem mais barata porém o problema começa quando você não sabe que está perdendo esse cache.
Eu, por exemplo, acreditava fielmente que trocar de modelo durante uma conversa me ajudaria a reduzir os custos escolhendo a ferramenta certa para o trabalho certo, porém essa troca causa perda de cache, e você paga caro toda vez que provoca uma invalidação de cache. Hoje a documentação do Claude Code é bastante clara: trocar de modelo invalida o cache, conectar ou desconectar MCPs, compactar a conversa e algumas mudanças no conjunto de ferramentas também podem quebrar aquele histórico. Embora o reasoning não esteja documentado eu já vi ferramental externo acusar isso.
E qual a conclusão disso? Ficar mexendo em tudo durante uma sessão longa tentando economizar pode custar mais do que simplesmente manter aquela sessão previsível.
Vamos fazer uma conta com o GPT-5.6 Sol porque aqui começa a ficar interessante.
Hoje o Sol custa $5 por milhão de tokens de input, $0.50 por milhão de tokens cacheados e $30 por milhão de output. Cache write no GPT-5.6 custa 1.25x o input normal. Existe ainda um detalhe importante, passou de 272k tokens de input, todo o request entra na precificação de long context e o input passa a custar 2x.
Então uma janela de 500k não é apenas “500k tokens”.
Combinando essas regras, 500k tokens em um cache write acima dos 272k ficam em aproximadamente $6.25 apenas de input, enquanto ler os mesmos 500k de um cache já quente fica em aproximadamente $0.50.
Agora imagine, para simplificar a conta, dez reconstruções completas daquele histórico de 500k:
10 cache writes de 500k ≈ $62.50 10 cache reads de 500k ≈ $5.00
Isso sem contar output, reasoning e tool calls.
A diferença é de aproximadamente 12.5x entre escrever novamente aquele mesmo histórico e reaproveitar o que já estava cacheado, nesse exemplo. E é justamente aqui que uma reconstrução de cache causada por uma otimização aparentemente inofensiva pode se tornar uma piada perto do custo de carregar uma sessão gigantesca de forma ineficiente.
Não utilizar reasoning baixo
Suponha que um modelo de $1 que precisa de 200 mil tokens, quatro tentativas e uma correção manual. Essa mesma tarefa poderia ter sido executada por um modelo de $5 que resolveu em 30 mil tokens de primeira, e saiu no fim mais barato que o modelo de $1.
A conta do reasoning low é quase sempre uma conta que parece não compensar mas ela pode compensar porque quando você usa um modelo melhor com reasoning low ele tende a ficar menos vislumbrado em uma tarefa que claramente não precisa de refino.
Se eu quero discutir arquitetura, investigar um problema muito ambíguo ou produzir uma spec complexa, perfeito, eu abro uma janela dedicada para isso e deixo o modelo pensar. Mas se a decisão já foi tomada, o contrato existe e eu estou pedindo para implementar um endpoint que está completamente especificado, talvez o OPUS PRO MAX rodando 45 minutos não esteja adicionando absolutamente nada além de tokens indo para o buraco.
Modelos com low reasoning me permitem ser muito mais agressivo com caps de contexto como 256k. E no caso específico do Sol existe até um incentivo financeiro para não atravessar os 272k sem necessidade, já que a partir dali entra a precificação de long context que é obviamente mais caro.
Usar uma ferramenta sem conhecer? O PI me salvou disso
Eu nunca fui muito fã de skills mágicas e plugins, mas frequentemente vem o FOMO de “será que eu estou perdendo algo?”
Isso é natural quando todos estão buscando engajamento, ser referência de algo completamente novo, mas o Pi ele vai na contra mão de tudo isso, ele sempre vai te perguntar “será que tudo isso é realmente necessário para executar essa task?”
A filosofia do Pi é quase ofensivamente simples, o system prompt junto das definições das ferramentas básicas foi desenhado para ficar abaixo de aproximadamente 1000 tokens em sua implementação minimalista original, com basicamente read, write, edit e bash. A ideia é que todo o resto apareça conforme existir necessidade, e não porque talvez algum dia o agente precise daquilo.
Em harnesses que carregam o schema completo de todas as ferramentas upfront, um MCP por exemplo, pode ser um devorador absurdo de tokens antes mesmo do agente começar a trabalhar. O próprio criador do Pi chegou a medir, em uma configuração da época, aproximadamente 13.7k tokens para 21 tools do Playwright MCP e 18k tokens para 26 tools do Chrome DevTools MCP. Em uma janela de 200k isso significava gastar algo entre 7% e 9% do contexto antes de escrever uma linha.
O mais importante de conhecer o Pi não foi solucionar todos os meus problemas e sim que capacidade disponível também tem custo.
E não é só filosofia, existem benchmarks que provam a eficiência
Um estudo de 2026 comparou Pi e Claude Code usando seis reasoning models, 24 coding tasks determinísticas e mais de 4.600 execuções válidas. No setup do estudo, o histórico fixo do Pi ficava entre aproximadamente 1.147 e 1.642 tokens, enquanto o Claude Code começava entre 15.983 e 20.330 tokens, uma diferença de aproximadamente 12x a 15x antes da task começar. Claro que existe uma ressalva, as tasks utilizadas no benchmark eram pequenas, limitadas a no máximo quatro arquivos, portanto isso não prova que o Pi será 15x mais eficiente em qualquer projeto ou tarefa real, mas deixa evidente o tamanho do custo fixo que um harness pode carregar.
Conclusão
No fim, o que eu estava fazendo de errado era achar que “estar no controle dos meus tokens” significava encontrar um modelo mais barato, quando na verdade o que eu precisava controlar não era o preço, e sim quando gastar tokens, com o que gastar tokens e por que aquele agente precisava ter acesso a tudo aquilo para fazer a tarefa que eu pedi.