Custo com inteligência artificial: por que contar tokens é um erro

Quando um desenvolvedor confia uma tarefa de programação a um agente de inteligência artificial, o sistema realiza muito mais do que uma resposta única. Ele planeja, produz código, executa testes e repete o ciclo para corrigir falhas. Uma única demanda pode consumir de 10 a 50 vezes mais tokens do que um comando básico de chat. Conforme a utilidade do agente cresce, o volume de chamadas aumenta proporcionalmente. Com a cobrança baseada em tokens, os fluxos de trabalho que geram mais valor também podem se tornar os mais onerosos.

A pressão financeira já se faz notar no mercado. O Uber teria esgotado todo o seu orçamento de inteligência artificial para 2026 até o mês de abril, após ampliar a adoção do Claude Code. O GitHub Copilot abandonou o modelo de preço fixo para adotar créditos metrificados. A consultoria Gartner prevê que os gastos com tokens em programação por IA vão superar os salários médios de desenvolvedores até 2028.

A reação natural costuma ser o racionamento por meio de limites de uso, restrições de licenças e aprovações prévias antes que os desenvolvedores acionem os agentes. No entanto, restrições generalizadas podem frear fluxos de trabalho que agregam valor e acabam otimizando a métrica errada. O custo por token mede consumo, e não resultados. Parte dos gastos reflete desperdício, como novas tentativas e loops contínuos, enquanto outra parte representa software efetivamente entregue. Um medidor simples não consegue diferenciá-los, assim como um teto de gastos.

Meça o software entregue

Uma alternativa mais eficiente é calcular o custo por pull request mesclado: o gasto total com desenvolvimento auxiliado por inteligência artificial dividido pela quantidade de alterações que passam por revisão e são integradas. O ideal é monitorar o retrabalho e os defeitos em paralelo, garantindo que alterações mais baratas não escondam uma queda na qualidade.

Se esse custo diminui à medida que o uso de inteligência artificial cresce, sem comprometer o padrão, significa que os desenvolvedores estão convertendo mais consumo em software útil. A questão central não é a quantidade de tokens consumida, mas sim o volume de trabalho concluído gerado pelo investimento.

Aprimorar essa equação exige duas mudanças fundamentais: reservar a inferência cara para tarefas que realmente demandam alto nível e reduzir o custo das atividades rotineiras.

Adeque o modelo à tarefa

A programação orientada por agentes não exige o modelo mais avançado em todas as etapas. O ideal é empregar um modelo de ponta — ou uma opção local principal quando as políticas exigirem — para o planejamento complexo e raciocínio inédito. Atividades adequadas, como geração de código, criação de testes e refatorações repetitivas, devem ser direcionadas a modelos de pesos abertos operados internamente.

Um gateway pode gerenciar as solicitações com base na complexidade da tarefa, sensibilidade dos dados, custo e latência. Dessa forma, a inferência premium fica reservada para os momentos que justificam o gasto, em vez de aplicar preços elevados a todo o fluxo de trabalho. O correto é metrificar a exceção, e não a carga de trabalho inteira.

Os modelos de pesos abertos tornam essa divisão cada vez mais viável. Análises de engenharia de software mostram que os principais modelos de pesos abertos podem se aproximar do desempenho de ponta em determinadas tarefas. Contudo, isso não garante equivalência em todos os repositórios ou fluxos. É preciso avaliar os candidatos com base no próprio código, testes e critérios de aceitação antes de destiná-los à produção.

Transforme a economia do uso repetido

Em seguida, é preciso definir quem gerencia a capacidade. Com a inferência alugada, cada chamada aumenta o valor da fatura. Com a capacidade própria, a maior parte do custo é fixada antecipadamente, tornando cada chamada adicional mais barata à medida que a utilização cresce.

A lógica financeira é simples: a cobrança por token encarece o uso intenso, enquanto a infraestrutura própria ganha eficiência com o aumento da demanda das equipes. Vale lembrar que a propriedade não é gratuita, envolvendo custos de energia, operações, manutenção e depreciação. O número que realmente importa é o custo total por pull request mesclado.

A capacidade própria também traz uma vantagem que não aparece nas faturas: o controle sobre códigos confidenciais. Quando a geração de códigos e os testes rodam localmente, a propriedade intelectual permanece dentro da empresa. Apenas comandos de planejamento aprovados e exceções controladas são enviados a modelos externos por meio de um gateway seguro. Isso viabiliza o acesso a repositórios sensíveis, onde a segurança costuma retardar a adoção da tecnologia e onde estão os maiores ganhos potenciais.

Teste o modelo operacional

Na HPE, uma plataforma de inteligência artificial híbrida direciona cargas de rotina de mais de 150 aplicações internas para modelos de pesos abertos executados localmente, inclusive na infraestrutura do HPE Private Cloud AI. O resultado obtido foi uma redução de 30% a 50% nos custos com tokens.

Essa é a grande vantagem do modelo híbrido. Com o HPE Private Cloud AI, ter capacidade própria não significa abrir mão de modelos avançados. É possível processar o volume principal em recursos próprios e contar com um gateway para direcionar as demandas mais complexas.

Os dados também mostram que o volume de uso, e não o número de licenças, impulsiona os gastos. Os 5% maiores usuários geram a maior parte do consumo, sendo que os mais intensivos utilizam cerca de 450 vezes mais do que os mais leves sob a mesma licença. Se os principais usuários passarem de uma pequena minoria para metade da força de trabalho, o gasto mensal pode subir cerca de 4,4 vezes com o mesmo quadro de colaboradores. Como a realidade de cada organização varia, a medição constante é indispensável.

A HPE acompanha duas métricas principais e recomenda que o mercado faça o mesmo. A primeira é o custo por desenvolvedor ativo, já que a média geral oculta os usuários intensivos que elevam os gastos. A segunda é o custo por pull request mesclado, que conecta diretamente o investimento em inteligência artificial ao software entregue.

É fundamental estabelecer uma base para ambos os custos antes de modificar a infraestrutura. Em seguida, deve-se executar um ciclo completo de desenvolvimento com capacidade própria. Se os dois indicadores não melhorarem com o aumento do uso, o modelo atual talvez continue sendo a escolha mais adequada.

Construa focado na adoção, e não no racionamento

A capacidade própria não é viável para todos os cenários. Demandas baixas ou imprevisíveis favorecem o uso de APIs, evitando capital imobilizado em infraestrutura ociosa. A aquisição de recursos compensa quando a demanda constante mantém os sistemas ocupados. A maioria das empresas tenderá a operar no formato híbrido: APIs de ponta para trabalhos exigentes ou intermitentes, e capacidade própria para volumes repetitivos. Um gateway governado decide o que sai da empresa, garantindo modelos avançados sem abrir mão da soberania sobre o código.

À medida que os desenvolvedores dependerem mais de agentes de programação, o uso continuará crescendo. O verdadeiro dilema é se esse crescimento se traduzirá em faturas de custos variáveis mais altas ou em mais software entregue por meio de infraestrutura própria. As empresas que liderarem o desenvolvimento auxiliado por inteligência artificial não vão racionar a adoção para controlar despesas; elas construirão um modelo operacional onde o uso intensivo melhora a economia em vez de prejudicá-la.