Um Prompt, Um Modelo, 4x o Custo: Governar Gasto de Agente pela Variância

A Netlify rodou um único prompt idêntico em 11 modelos de código, três execuções cada, e publicou os números por execução. O Claude Opus 5 teve média de 519 créditos. As três execuções por trás dessa média foram 253, 249 e 1.055. Mesmo modelo, mesmo prompt, e uma dispersão de 4x dentro de uma única linha da tabela.

Esse número é o argumento. A maioria dos controles de custo de agente hoje em produção é um teto mensal e um alerta de limiar, e ambos descrevem a média. A média foi 519. Nada em um teto de gastos informa que uma execução em três custou quatro vezes o que custaram as outras duas, nem qual foi, nem por quê.

A leitura que a própria Netlify faz do padrão é incomumente direta para um blog de fornecedor: “o Opus tem uma tendência a disparar em consumo de créditos (comparado ao seu próprio patamar típico) mais do que outros modelos. Isso não garante um resultado melhor nem pior.” O custo explodiu. A qualidade não acompanhou. Esses dois fatos juntos transformam variância em objeto de governança, e não em curiosidade.

A Distribuição É Mais Larga que a Escolha do Modelo

Leia a tabela completa da Netlify e o debate sobre escolha de modelo encolhe. Médias entre os 11 modelos: Opus 5 com 519 créditos, Sonnet 5 com 143, GPT 5.6 Sol com 141, Gemini 3.6 Flash com 103, Kimi K3 com 102, Gemini 3.1 Pro com 53, GPT 5.6 Terra com 39, DeepSeek V4 Pro com 37, GLM 5.2 com 27, Kimi K2.7 Code com 19, e DeepSeek V4 Flash com 2,4. O campo se estende por cerca de 200x em um único prompt.

Duzentas vezes entre a opção mais barata e a mais cara, e 4x dentro da mais cara. Um time que se debruça sobre qual modelo padronizar e depois o roda sem instrumentação otimizou a menor das duas grandezas.

Trate as ressalvas com honestidade. É um único prompt, três execuções por modelo, publicado por um fornecedor que anuncia uma parceria com a OpenRouter no mesmo post. Três execuções não formam uma distribuição, apenas sugerem uma. Os valores específicos de crédito não deveriam entrar na previsão orçamentária de ninguém. O que sobrevive às ressalvas é o formato: custo por execução em trabalho de agente tem cauda pesada, e a cauda mora dentro do comportamento de um único modelo.

O Que um Teto de Fato Controla

Um teto mensal é um disjuntor. Dispara depois que o dinheiro foi gasto, dispara sobre o agregado, e sua única resposta disponível é parar tudo. Entre zero e o limite, ele é cego.

Três coisas que um teto não consegue fazer:

Avisar que uma revisão de PR rotineira consumiu muitas vezes o orçamento habitual, porque essa execução é invisível dentro de um total mensal.
Distinguir uma execução cara que entregou uma migração de uma execução cara que entrou em loop com um prompt malformado e não produziu nada.
Autorizar mais dinheiro na única tarefa em que gastar mais era a decisão correta.

A última é a omissão cara. A Databricks coloca isso de forma explícita no post sobre Smart Routing: “Valuemaxxing corta para os dois lados: pegue o modelo barato quando ele basta, e tenha confiança para gastar mais quando o valor justifica.” Um teto só sabe dizer não. Um controle de custo que só consegue reduzir gasto vai, ao longo de um ano, subfinanciar de forma sistemática o pequeno número de tarefas em que a capacidade de fronteira valia o preço.

Roteamento É a Superfície de Controle, Telemetria É o Instrumento

A Databricks relata que o Smart Routing no Unity AI Gateway superou qualquer modelo isolado a 65% do custo por tarefa de um modelo líder como o Opus 5. Citam 35% de economia em um benchmark interno e 56% em benchmarks públicos de código, com 30%+ como piso conservador declarado.

Esses três números vêm de experimentos diferentes e não devem ser somados, ter suas médias tiradas, nem ser citados como um resultado único. O benchmark interno é descrito como um ao qual nenhum laboratório teve acesso, o que significa que ninguém fora da Databricks consegue conferir. Leia como afirmação direcional de um fornecedor que vende o gateway.

O mecanismo é mais útil que os percentuais, e o mecanismo tem um ponto fraco declarado. Databricks: “Prompts de abertura raramente são precisos, já que o que um desenvolvedor digita primeiro é um sintoma ou uma intenção aproximada em vez de uma especificação, e nosso roteador lê essa primeira mensagem e se compromete.” Um roteador que classifica pela mensagem de abertura herda a imprecisão dessa mensagem. Por isso eles recomendam começar o deploy onde o enunciado da tarefa é escrito por máquina: revisões de PR, disparos de subagentes, migrações em lote, jobs agendados. Nesses caminhos o escopo já está explícito, então classificar sai quase de graça.

Essa ordem de implantação é a parte que vale copiar. É também a parte que a maioria dos times pula, porque o chat é a superfície visível e o trabalho disparado por máquina não é.

Para monitoramento, a Databricks nomeia três métricas: distribuição de sessões por modelo, número de sessões concluídas de ponta a ponta pelo modelo roteado, e economia em dólares vinda do roteamento. A segunda carrega o peso. Um roteador que corta a conta de modelo mandando trabalho para um modelo barato que devolve a tarefa pela metade apenas empurrou custo para o tempo humano, onde ninguém está medindo.

Quatro Números para Instrumentar

Custo por tarefa concluída é o denominador certo, e já defendemos esse caso em separado. Roteamento como controle em tempo de execução tem tratamento próprio aqui. O que nenhum dos dois cobre é a distribuição em torno desse denominador. Instrumente isto:

Custo por execução, retido. Nada de total mensal ou consolidado diário. Uma linha por execução de agente, com a classe da tarefa, o modelo, o custo e o desfecho. Sem essa linha, nada do resto desta lista é calculável.
P50 e P95 por classe de tarefa. A mediana diz quanto o trabalho custa. O percentil 95 diz como são suas piores semanas. Se o P95 fica em 4x o P50 numa classe que você roda de hora em hora, sua previsão está errada de um jeito que média nenhuma revela.
Correlação entre custo e desfecho. Pegue o decil mais caro de execuções. Que fração entregou? O achado da Netlify foi que crédito em excesso não garantiu resultado melhor. Se sua cauda cara tem a mesma taxa de conclusão da mediana, a cauda é desperdício e pode ser cortada. Se tem taxa maior, a cauda é seu trabalho mais difícil, e limitá-la é o erro.
Batidas no teto por classe de tarefa. Toda vez que uma execução termina por limite em vez de por conclusão, registre a classe. Uma classe que bate no teto repetidamente está mal roteada ou genuinamente subfinanciada, e essas duas situações pedem correções opostas.

Faça Isto na Semana que Vem

Puxe os últimos 30 dias de execuções de agente e ordene por custo, do maior para o menor. Olhe as 20 primeiras. Para cada uma, responda se entregou. É uma tarde de trabalho e vai dizer se sua cauda cara é seu melhor ou seu pior trabalho, o que determina se o controle correto é uma rota mais barata ou uma alçada maior.

Depois pegue o caminho de maior volume disparado por máquina que você opera, provavelmente revisão de PR ou um job agendado, e roteie por classe de tarefa em vez de por um modelo padrão global. Definir escopo ali sai de graça, porque o enunciado da tarefa já é escrito por um sistema. Acompanhe a taxa de conclusão de ponta a ponta por duas semanas antes de mexer em qualquer coisa que um humano digita numa caixa de chat.

Uma razão para manter a camada de roteamento em vez de cravar um modelo: 33 modelos novos foram lançados só em 2026. Qualquer escolha estática é uma decisão com prazo de validade curto. A camada que reclassifica e reroteia é o ativo. O modelo por trás dela é a peça substituível.

O orçamento de agente que sobrevive ao próximo ano se parece com um livro-razão por execução, com uma política acoplada, e essa política precisa de permissão para gastar mais além de gastar menos. Quem detém essa permissão é uma questão própria, e vale resolver antes que o livro-razão exista.

Fontes

Netlify. “More models, more choice: comparing 11 different AI models.” Agosto de 2026.
Databricks. “Smart Routing in Unity AI Gateway: match frontier quality with 30%+ lower cost per task.” Agosto de 2026.

As duas fontes são publicações de fornecedores com interesse comercial na conclusão, e seus números de benchmark vêm de experimentos que não podem ser verificados de forma independente.

A Victorino ajuda organizações de engenharia a instrumentar custo de agente por execução e a construir políticas de roteamento que autorizam gasto nas duas direções: contato@victorino.com.br | www.victorino.com.br