Custo por token é a métrica errada para avaliar agentes de IA no código

Um agente de codificação não responde uma vez e pronto. Ele planeja, gera código, roda teste, falha, tenta de novo. Uma única tarefa pode consumir de 10 a 50 vezes mais tokens do que um prompt de chat simples. Quanto mais útil o agente fica, mais chamadas ele faz, e com preço por token isso significa que o fluxo que mais gera valor também é o que mais pesa na fatura.

Esse não é um problema hipotético. A Uber teria esgotado todo o orçamento de IA↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → de 2026 já em abril, depois de expandir o uso do Claude Code. O GitHub Copilot abandonou o preço fixo por assento e migrou para créditos medidos por consumo. E o Gartner projeta que o custo de tokens de codificação com IA vai ultrapassar o salário médio de um desenvolvedor até 2028.

Os números estão em um conteúdo patrocinado pela HPE na MIT Technology Review, publicado em 2 de novembro de 2026, e é importante dizer isso de cara: é material pago por um fornecedor que vende infraestrutura de IA on-premises. Isso não invalida o argumento central, mas muda o peso que devo dar ao case que ele conta sobre si mesmo.

A métrica que todo mundo está usando está errada

A reação mais comum a essa pressão de custo é a mais simples: cota de uso, limite por assento, aprovação prévia antes de rodar o agente. O problema é que isso otimiza o número errado. Custo por token mede consumo, não resultado. Parte do gasto é desperdício (retry, loop que não converge), parte é o próprio trabalho de entregar software, e um medidor de consumo não distingue as duas coisas. Um teto de gasto também não distingue.

Concordo com o diagnóstico. Já vi esse mesmo erro em outros ciclos de tecnologia: quando a métrica de controle é a de custo bruto, o time aprende a economizar no que é fácil de medir (chamadas de API) e não necessariamente no que realmente drena orçamento (retrabalho, PR que não passa em review, agente que itera demais numa tarefa mal especificada).

A proposta: custo por pull request mergeado

A métrica alternativa que o texto defende é custo total de desenvolvimento assistido por IA dividido pelo número de mudanças que passam em review e são mergeadas, acompanhada de perto por retrabalho e taxa de defeito, para que um PR mais barato não esconda uma qualidade pior. Se esse custo cai conforme o uso de IA sobe, sem comprometer qualidade, o time está convertendo consumo em software útil de verdade.

Como métrica de gestão de engenharia, isso é um avanço real sobre contar token. Ela desloca a conversa de "quanto gastamos" para "quanto entregamos por real gasto", que é exatamente a pergunta que um board de produto deveria estar fazendo há um ano.

O ponto cego que o relatório não enfrenta

Mas nenhuma métrica de produtividade de engenharia sobrevive intacta ao primeiro incentivo perverso, e é aqui que preciso discordar da leitura otimista do texto. Custo por PR mergeado pode ser gamificado de formas óbvias: quebrar uma mudança grande em vários PRs pequenos infla o denominador sem aumentar o valor entregue; reviewer sob pressão de métrica aprova mais rápido e mais raso; e retrabalho que aparece só dois sprints depois, como dívida técnica, não entra na conta do mês em que o PR foi mergeado.

O próprio relatório tenta se proteger disso ao recomendar acompanhar retrabalho e defeito junto, o que é certo, mas é a parte que exige disciplina de engenharia, não de dashboard financeiro. Se o time de produto que aprova orçamento só olha o número principal (custo por PR caindo), a pressão para gamificar a métrica some em uma linha de relatório e some do radar de quem assina o cheque.

Roteamento de modelo: a decisão que fica para o CTO

A parte mais concreta e mais interessante do texto é a divisão de trabalho entre modelos. A recomendação é reservar modelo de fronteira (ou flagship on-premises, quando a política exigir) para planejamento difícil e raciocínio novo, e rotear trabalho repetitivo (geração de código, criação de teste, refatoração recorrente) para modelos abertos operados pela própria empresa.

Um gateway decide a rota com base em complexidade da tarefa, sensibilidade do dado, custo e latência: taxar a exceção, não o fluxo inteiro. Isso é um critério de decisão de arquitetura, não um pacote pronto, e cabe a cada time validar o modelo aberto candidato contra o próprio código, os próprios testes e os próprios critérios de aceitação antes de colocá-lo em produção, porque benchmark de terceiro não garante equivalência em repositório específico.

Infraestrutura alugada x própria: a tabela que falta no relatório

O relatório é honesto num ponto: capacidade própria não é de graça, e o número que importa continua sendo o custo totalmente carregado por PR mergeado, não o preço da placa.

O case da HPE merece ceticismo, não descarte

A HPE diz que sua plataforma híbrida roteia cargas de rotina de mais de 150 aplicações internas para modelos abertos rodando no HPE Private Cloud AI, com custo de token caindo de 30% a 50%. Também afirma que os 5% de usuários mais intensos geram a maior parte do consumo, e que o usuário mais pesado consome cerca de 450 vezes mais que o mais leve na mesma licença: se o perfil de uso pesado for de minoria pequena para metade do time, o gasto mensal pode subir cerca de 4,4 vezes com o mesmo número de assentos.

São números do próprio fornecedor, sem auditoria independente visível na fonte, e isso pesa na minha leitura: tratam-se de dados que servem ao argumento de venda da empresa que os publicou. Dito isso, a lógica por trás (usuário pesado, não cabeça de licença, é quem dita o gasto) é consistente com o que qualquer time que opera FinOps de IA generativa já deveria estar rastreando, independente de qual fornecedor de infraestrutura escolher.

O que muda para quem constrói

Para quem lidera um time de engenharia, a pergunta prática não é se vai adotar custo por PR mergeado amanhã, é se o pipeline de CI já consegue atribuir custo de inferência a cada PR individual, hoje. Sem esse dado granular, a métrica é promessa, não ferramenta.

E antes de qualquer decisão de comprar capacidade própria, o critério deveria ser simples: rode um ciclo completo de desenvolvimento em capacidade própria e compare custo por desenvolvedor ativo e custo por PR mergeado contra o modelo atual. Se nenhum dos dois melhora com o aumento de uso, o modelo atual ainda é a escolha certa, e trocar de fornecedor de infraestrutura não resolve um problema de métrica mal desenhada.

Fonte: MIT Technology Review