Fixar um modelo de IA no código já é dívida técnica

Times que rodam mais de um bilhão de tokens por mês no AI Gateway da Vercel usaram em média 42 modelos diferentes em setembro de 2026, e quase metade de todos os times trocou o modelo mais usado naquele mês. É esse o número que merece reação — não a manchete de que modelos open-weight ficaram com 71,5% dos tokens e 23% do gasto. Escolher modelo deixou de ser decisão de arquitetura e virou decisão de runtime, o que significa que um id de modelo fixo no código do seu produto já é dívida técnica.

O que o dado de produção realmente diz

Não são resultados de benchmark. São números agregados e anonimizados de tráfego que rodou de verdade, publicados no índice de produção do AI Gateway da Vercel referente a setembro de 2026.

A cobertura do The New Stack enquadra a outra metade do mesmo fato: open weight fica com o volume, enquanto a Anthropic sozinha ainda leva 64% do dinheiro.

"Open weight" não é uma coisa só

O agregado esconde uma dispersão grande o suficiente pra invalidar a categoria. Dentro desses mesmos 71,5%:

• DeepSeek: 58% dos tokens por 6,6% do gasto.
• Z.ai (GLM): 7,2% dos tokens por 4,5% do gasto.
• Moonshot (Kimi): 3,6% dos tokens por 13,2% do gasto — a razão inverte completamente.

Ou seja, um modelo open-weight custa cerca de uma ordem de grandeza mais por token que outro. "Migramos pra open weight pra cortar custo" não é estratégia; é uma frase que pode ser verdadeira ou falsa dependendo de qual modelo open-weight você escolheu e pra qual tarefa. A diferença entre modelos abertos hoje é maior que o abismo que as pessoas imaginam entre aberto e fechado.

Token mais barato gerou conta maior

Os dois números mais contraintuitivos do índice estão lado a lado: o preço médio por token caiu 47% e o gasto no gateway cresceu 13x na mesma janela.

É o paradoxo de Jevons chegando na inferência. A queda do custo unitário não reduziu a linha do orçamento — removeu a restrição que segurava o uso. Toda funcionalidade que era cara demais pra existir nos preços do ano passado virou viável, e os times entregaram.

A consequência de planejamento é específica: não orce inferência como um custo que cai. O preço do modelo cai e a sua conta cresce, porque o que governa o que você constrói é capacidade por dólar. Um founder projetando gasto de IA estável porque os preços estão caindo está projetando a variável errada.

O acoplamento que vai doer

Junte os dois achados — metade dos times troca de modelo principal todo mês, e a dispersão de custo dentro de uma categoria é de 10x — e a conclusão de arquitetura se escreve sozinha. Qualquer coisa que torne cara a troca de modelo passou a ser a coisa cara.

Como isso aparece no código, pelo que a gente vê levando software feito com IA pra produção:

1. Id de modelo inline no ponto de chamada. Um literal espalhado em doze arquivos é migração, não mudança de config. Um lugar, um nome, injetado.
2. Prompt escrito pras manias de um modelo. Truque de formatação afinado numa família específica para de funcionar silenciosamente na próxima. Mantenha o prompt especificado por comportamento e teste contra pelo menos dois modelos.
3. Sem mapa tarefa→modelo. Classificação, extração, sumarização em massa e raciocínio difícil têm perfis de custo que diferem em 10x ou mais. Rotear por classe de tarefa é onde a economia está de fato — não em escolher um default mais barato pra tudo.
4. Sem suíte de eval. Sem ela, trocar de modelo é ato de fé, então o time não troca, então paga caro nas tarefas que nunca precisaram do modelo caro. A suíte de eval é o que converte queda de preço em corte de orçamento.
5. SDK do provedor espalhado pela camada de domínio. O padrão de gateway existe por um motivo: um adaptador, um lugar pra colocar fallback, um lugar pra enxergar gasto.

Nada disso é exótico. É a disciplina comum pra qualquer dependência que muda mais rápido que o seu ciclo de release — e no momento essa dependência muda todo mês.

O que a gente faria primeiro

Se já existe funcionalidade de IA em produção e nada disso está no lugar, a ordem que a gente seguiria: extrair o id do modelo pra configuração, escrever eval pras três tarefas de maior volume e rotear essas três por classe de tarefa. Essa sequência captura a maior parte do ganho de custo antes de qualquer reescrita, e transforma a próxima troca de modelo numa mudança de configuração em vez de um projeto.

É essa a camada sem glamour entre uma funcionalidade que faz demo e um sistema cuja economia sobrevive um ano — o trabalho que a gente faz com software feito com IA indo pra produção. E rima com algo que já escrevemos: geração virou abundante, julgamento virou escasso. Roteamento de modelo é julgamento, codificado.

Principais conclusões

• Times acima de 1B de tokens usaram 42 modelos em média em setembro de 2026, e cerca de metade de todos os times trocou o modelo mais usado no mês. Escolha de modelo virou decisão de runtime.
• Modelos open-weight ficaram com 71,5% dos tokens e só 23% do gasto; a Anthropic sozinha ainda levou 64% do dinheiro.
• "Open weight" não é um preço só: DeepSeek rodou 58% dos tokens por 6,6% do gasto, enquanto a Moonshot rodou 3,6% dos tokens por 13,2%.
• O preço por token caiu 47% enquanto o gasto total cresceu 13x — inferência mais barata expande o uso em vez de encolher orçamento.
• O acoplamento caro é tudo que dificulta a troca: id de modelo inline, prompt preso a um modelo, ausência de eval, ausência de roteamento por tarefa.

FAQ

Devemos migrar pra modelos open-weight pra cortar custo?

Só com mapa tarefa→modelo e eval. Open weight ficou com 71,5% dos tokens por 23% do gasto no agregado, mas dentro dessa categoria um modelo rodou 58% dos tokens por 6,6% do gasto enquanto outro rodou 3,6% por 13,2%. A categoria não diz nada; o que determina custo é o par tarefa-modelo.

Por que o gasto cresceu se o preço caiu?

Porque o preço era a restrição do uso. O preço médio por token caiu 47% entre dezembro de 2026 e setembro de 2026 enquanto o gasto no gateway cresceu 13x. Inferência mais barata torna viável o que antes não fechava a conta, e os times entregam isso.

Com que frequência os times trocam de modelo de verdade?

Em setembro de 2026, quase metade dos times trocou o modelo mais usado e um em cada três trocou de laboratório inteiro — recorde do índice. É essa a taxa que a sua arquitetura precisa absorver.

Qual a primeira coisa a corrigir num código que já existe?

Tirar o id do modelo dos pontos de chamada e levar pra configuração. É uma mudança pequena que converte toda troca futura de migração de código em deploy, e custa quase nada fazer agora.

Precisamos de um produto de gateway pra isso?

De um produto, não necessariamente — mas do padrão, sim: um adaptador entre o código de domínio e qualquer SDK de provedor, pra que roteamento, fallback e visibilidade de gasto tenham onde morar.

Fontes: Índice de produção do AI Gateway da Vercel, outubro de 2026 · The New Stack