Todo mundo discute se agente de IA vale a pena. Quase ninguém publica a conta.
Eu tenho uma. A fundação deste blog — requisitos, arquitetura, dez ADRs, os mockups e o contrato de conteúdo — foi construída por um ciclo multiagente com um comitê de sete revisores automáticos e nota de corte 9,5. Foram três rodadas e cerca de 6,67 milhões de tokens, com o consumo anotado por etapa no próprio repositório enquanto a coisa acontecia.
Este post abre essa planilha. Não é benchmark de modelo nem promessa de que o seu número vai ser esse: é uma medição de um caso, com o método declarado e os arquivos públicos para quem quiser conferir.
O número, e de onde ele vem
Os valores foram anotados ao fim de cada rodada nos placares que ficam versionados em docs/testes/ — os mesmos arquivos que registram as notas do comitê. São valores reportados pelos subagentes, não uma fatura extraída do painel de cobrança. Essa distinção importa e volta no fim do post.
O que os 6,67 milhões compraram: 21 artefatos de fundação (documento de requisitos, documento de arquitetura, dez ADRs, a especificação do pipeline, cinco mockups, o arquivo de design tokens e o componente de anúncio), revisados por sete lentes independentes — arquitetura de software, arquitetura de dados, desenvolvimento, design, QA, segurança e inovação — mais um auditor de processo, até todas passarem de 9,5.
Onde os tokens foram, rodada por rodada
| Rodada | Consumo | Resultado |
|---|---|---|
| R1 | ≈ 1,97M | reprovada |
| R2 | ≈ 2,04M | reprovada (média +1,55) |
| R3 | ≈ 2,66M | aprovada — todas as sete lentes ≥ 9,5 |
O detalhe por etapa é mais interessante que o total. Na R2:
- correções dos achados da rodada anterior: ≈ 785k
- gate de fumaça + correção barata: ≈ 236k
- as sete lentes em modo delta: ≈ 922k
- auditor de processo: ≈ 101k
Na R3:
- correções: ≈ 919k
- gate de fumaça + correções pré-revisão: ≈ 393k
- as sete lentes em verificação estrita: ≈ 652k
- re-verificações: ≈ 359k
- correções pós-revisão (quatro, em modelo pequeno): ≈ 186k
- auditor: ≈ 147k
Repare no que a tabela mostra: a revisão não é o item mais caro. Somando correções e re-verificações, o trabalho de arrumar o que foi apontado custou mais que apontar. Quem só olha o preço do revisor está olhando a metade barata da conta.
O gate barato pagou; o modo “delta” não
Duas mudanças de processo foram testadas com a intenção explícita de baratear. Uma funcionou, a outra não — e a que não funcionou é a mais instrutiva.
Funcionou: o gate de fumaça antes das lentes. Uma checagem rápida e mecânica (os arquivos declarados existem? o texto bate com o código? tem link morto?) rodando antes dos revisores caros. Na R1, sem esse gate, defeitos triviais foram redescobertos por três lentes diferentes, cada uma gastando contexto para chegar à mesma conclusão. Na R2, com o gate, uma correção fechou por 34 mil tokens em um modelo pequeno. O mesmo defeito, pelo caminho anterior, era pago três vezes em modelo grande.
Não funcionou: revisar só o diff. A ideia era óbvia — se a rodada anterior já leu tudo, a próxima só precisa olhar o que mudou. Na prática, as sete lentes em modo delta custaram 922k, praticamente o mesmo de uma avaliação cheia. Elas não usaram a economia para terminar mais cedo; usaram a folga para atacar o diff com mais profundidade. O resultado foi bom — só não foi barato. Uma economia que o modelo pode gastar em qualidade não é uma economia, é uma realocação.
O que realmente cortou o custo da revisão foi mudar a instrução, não o escopo: na R3, as lentes rodaram em modo de verificação estrita (confira estas pendências específicas, não reavalie o mundo) e custaram 652k — cerca de 30% menos que o modo delta.
E o item de maior retorno do ciclo inteiro: o par correção barata + re-verificação com o contexto preservado. Quatro pendências fecharam por ≈ 545k somados, o que evitou uma quarta rodada completa. Uma rodada custava mais de 2 milhões de tokens. Gastar 545 mil para não gastar 2 milhões é o tipo de decisão que só aparece se você estiver medindo.
O desperdício tem nome: 378 mil tokens
O item que eu mais gosto do registro é o que deu errado.
Dentro dos 919k de correções da R3 há ≈ 378 mil tokens em dois retries duplicados, disparados por um diagnóstico apressado: eu concluí que a internet tinha caído e mandei refazer. Não tinha caído. O trabalho já estava em andamento e foi refeito por cima de si mesmo, duas vezes.
Isso é 5,7% do ciclo inteiro queimado em um palpite errado sobre infraestrutura. Não foi o modelo que errou, não foi o prompt: foi o operador reagindo a um silêncio. Agente que demora não é agente travado, e a diferença entre as duas coisas custa dinheiro real.
A correção é chata e funciona: antes de mandar refazer, confirmar que a coisa parou de verdade.
E em dólar, quanto deu?
Aqui a resposta honesta é um intervalo, não um número — e o motivo é a lição mais útil deste post.
Aos preços de tabela publicados hoje pela Anthropic, o Claude Opus 5 custa US$ 5 por milhão de tokens de entrada e US$ 25 por milhão de saída. Aplicando isso aos 6,67 milhões:
- se tudo fosse entrada: ≈ US$ 33
- se tudo fosse saída: ≈ US$ 167
O número real está em algum lugar nesse intervalo de cinco vezes, e eu não consigo apontar onde. Porque eu anotei o total, não a divisão entre entrada e saída — nem quanto rodou em modelo pequeno. Parte do ciclo rodou em Haiku, que custa um quinto do Opus na entrada, então o piso verdadeiro é ainda mais baixo; e nada disso considera cache de prompt, que abate boa parte da leitura repetida.
Ou seja: eu instrumentei o suficiente para saber onde o esforço foi, e não o suficiente para saber quanto custou. Dá para decidir processo com o que eu tenho. Não dá para fechar orçamento.
Se você vai medir um agente, meça em dinheiro desde o primeiro dia: entrada e saída separadas, por modelo, por etapa. Token é unidade de esforço; dinheiro é unidade de decisão. Converter de um para o outro depois só funciona se você guardou a divisão — e eu não guardei.
O que eu mudaria antes do próximo ciclo
- Registrar entrada, saída e modelo por etapa. Três colunas a mais na mesma anotação que eu já fazia, e o intervalo de cinco vezes vira um número.
- Gate mecânico antes de revisor caro. O que um script consegue reprovar não deve chegar ao modelo grande.
- Instrução estreita em vez de escopo estreito. Dizer “verifique estas pendências” corta custo; dizer “olhe só o diff” não corta.
- Correção barata com re-verificação contextual. É mais barato consertar e reconferir do que abrir outra rodada inteira.
- Não reagir a silêncio. Confirmar que travou antes de mandar refazer — o retry duplicado foi o gasto mais caro e mais evitável do ciclo.
Nenhum desses itens é sobre escolher o modelo certo. Todos são sobre o processo em volta dele, que é onde a conta realmente se forma.
Fontes
- Consumo da R2 por etapa (785k correções · 236k gate + correção barata · 922k lentes em delta · 101k auditor; total ≈ 2,04M) e a lição registrada de que o modo delta não barateou as lentes — placar do comitê, rodada 2 (registro próprio do projeto, nível 1), verificado em 2026-08-10.
- Consumo da R3 por etapa (incluindo os ≈ 378k de retries duplicados), o acumulado do ciclo em ≈ 6,67M e as medições de −30% da verificação estrita e dos ≈ 545k que evitaram uma quarta rodada — placar do comitê, rodada 3 (registro próprio do projeto, nível 1), verificado em 2026-08-10.
- Preço por milhão de tokens de entrada e saída dos modelos atuais — visão geral dos modelos, Anthropic (documentação oficial, nível 1), verificado em 2026-08-10.
- Metodologia declarada: os números de tokens são valores reportados pelos subagentes e anotados ao fim de cada rodada, não uma extração do painel de cobrança. A conversão para dólar é um intervalo calculado por mim a partir dos preços de tabela acima, não uma fatura.
