Um time de produto decide testar o MiniMax M2.7 no dia em que o modelo sai. Não é curiosidade: o modelo promete latência menor numa tarefa que já roda em produção. Só que testar significa abrir o arquivo de integração daquele provedor, ajustar o formato de resposta, ajustar como as chamadas de ferramenta são declaradas, rodar a bateria de testes de novo, revisar, subir pra produção. Isso leva uma hora, às vezes mais. E a maior parte desse tempo não vai pra decidir se o modelo é bom: vai pra fazer o código de adaptação aceitar mais um provedor.
De 7,5% para 0,34%
A Zo Computer, startup que constrói um assistente pessoal de IA, media a saúde do próprio sistema pela taxa de retry: quantas mensagens precisavam de uma nova tentativa porque a chamada ao modelo falhou ou voltou num formato que o código não esperava. Antes da mudança, essa taxa rodava em 7,5%, uma em cada treze mensagens. Depois de trocar o código de adapter feito à mão, provedor por provedor, pelo AI Gateway e o AI SDK da Vercel, a taxa caiu para 0,34%. Vinte vezes menos. O número médio de tentativas por mensagem, que ficava acima de 1, foi para 1,00: quase toda chamada funciona de primeira agora. A empresa documentou o caso no blog da Vercel, em junho de 2026, junto com o lançamento da versão 7 do SDK.
O detalhe que separa esse caso de marketing de fornecedor é o que causava o retry. Não era o modelo errando a resposta. Era o adapter da Zo, escrito à mão pra cada provedor, engasgando com diferença de formato: um jeito de declarar ferramenta aqui, outro ali, um jeito de normalizar imagem que funcionava pra um modelo e quebrava pro outro. Trocar de fornecedor de infraestrutura de IA não resolveu um problema de modelo. Resolveu um problema de código de cola.
O que a abstração compra, e o que ela custa
Isso muda o critério de decisão de quem mantém agente ou produto de IA em produção. A pergunta certa não é "gateway é melhor que chamar a API direto". É outra: quanto do seu código hoje existe só pra tratar a diferença entre provedores, e com que frequência você precisa trocar de modelo.
| Adapter próprio por provedor | Gateway único | |
|---|---|---|
| Trocar de modelo | Editar código, testar, redeployar | Mudar uma string de configuração |
| Onde mora o bug de formato | Espalhado pelo seu código | Centralizado no gateway |
| Ponto único de falha | Não tem | Tem, e é do fornecedor do gateway |
| Custo extra | Zero de infraestrutura, alto de manutenção | Taxa do gateway, baixo de manutenção |
Na Zo, o resultado citado pesa porque o time media a métrica errada antes: retry não é falha de qualidade de resposta, é falha de integração. Time que nunca separou isso não sabe quanto do próprio retry é o modelo e quanto é o código dele. Vale medir antes de decidir qualquer coisa.
O outro lado da tabela importa tanto quanto o primeiro. Gateway compartilhado é mais um fornecedor na cadeia, mais uma dependência entre o produto e o modelo, mais um lugar onde uma instabilidade de terceiro vira indisponibilidade sua. Pra time que usa um modelo só e troca uma vez por ano, o adapter próprio, por mais feio que seja, é código que dá pra entender e depurar sem outra empresa no meio do caminho. A conta só fecha a favor do gateway quando trocar de modelo é rotina, não exceção.
Quando compensa trocar
A gente aplica um teste simples antes de decidir isso num projeto: conta quantos provedores diferentes de modelo o agente chama hoje, e quantas vezes no último ano alguém editou o código de adapter por causa de um modelo novo ou uma mudança de formato de resposta. Duas trocas por ano, cada uma levando uma tarde, não justificam trazer mais uma camada pro sistema. Seis trocas, cada uma levando um dia inteiro e um deploy de emergência porque alguém queria testar um modelo que saiu naquela semana, já justificam.
Tem uma segunda pergunta que pesa tanto quanto a primeira: o retry alto que você tem hoje é do modelo ou do seu código? Dá pra medir sem trocar nada. Separa os logs de erro por tipo: falha de formato de resposta, falha de chamada de ferramenta, timeout, erro de conteúdo. Se a maioria for formato e tool calling, o problema é estrutural, e um gateway ataca ele direto. Se a maioria for timeout ou o modelo respondendo errado, trocar de camada de abstração não resolve nada, porque o problema não está aí.
Pra segunda de manhã
Antes de decidir se vale trazer um gateway de modelos pro seu stack, separa os logs de retry dos últimos 30 dias por categoria de erro. Se a fatia de formato e tool calling for grande, você tem o mesmo problema que a Zo tinha, e o caso delas é argumento pra testar a mudança num serviço não crítico antes de levar pro principal. Se for pequena, o problema que você tem é outro, e essa não é a solução.
A gente ajuda times a desenhar essa camada de agente sem prender o cliente num fornecedor só. Tem mais sobre como fazemos isso em /ai.
Fontes
- How Zo Computer improved AI reliability 20x on Vercel (Vercel, 2026)
- AI SDK 7 is now available (Vercel, 2026)
