A armadilha do modelo único
Todo grande fornecedor de IA quer que você acredite que o modelo de topo dele é a resposta certa para qualquer pergunta. Essa crença é comercialmente conveniente para ele e tecnicamente falsa para você.
Um modelo que brilha em raciocínio jurídico de contexto longo não é o certo para produzir uma legenda de dez palavras. Um modelo com visão de ponta é exagero — e provavelmente caro demais — para um trabalho em lote que reformata JSON estruturado. Um modelo cujo preço é otimizado para vazão pode ser a pior escolha possível quando você precisa de uma resposta em dois segundos.
Quando você constrói sobre um único modelo, não está escolhendo a melhor ferramenta. Está escolhendo a melhor ferramenta disponível dentro de uma restrição artificial. Com o tempo essa restrição se acumula: você paga demais em tarefas simples, fica aquém nas complexas, e quando aquele fornecedor tem uma queda ou um aumento de preço, todo o seu produto para.
Capacidades, não nomes
A abstração útil não é «qual modelo», mas «de quais capacidades esta solicitação precisa». Essa pergunta tem resposta precisa.
Uma mensagem de chat com uma captura de tela anexada precisa de visão. Uma etapa de fluxo que chama uma API externa precisa de ferramentas. Um assistente de código que deve verificar a própria saída precisa de execução de código. Um pipeline noturno de resumo que não precisa ser rápido pode usar preços em lote; um assistente dentro do produto com alguém esperando, não.
Quando você enumera primeiro os requisitos de capacidade, a seleção de modelo vira um problema de filtrar e ordenar. Dado um conjunto exigido — digamos texto, visão e saída estruturada — você acha todos os modelos que suportam os três e então os ordena por qualidade e preço para o contexto atual da solicitação. Essa ordenação pode mudar de solicitação para solicitação conforme o que a pessoa está fazendo e como estão os fundos dela.
É exatamente isso que o pipeline de roteamento do ToRun faz. O modo (Chat, Código, Imagem, Pesquisa e outros) mapeia para um conjunto de capacidades. O conjunto filtra o catálogo de modelos. A classificação por preço e qualidade escolhe o vencedor. O resultado é que você pode usar DeepSeek para extração estruturada em grande volume, Claude ou modelos de classe GPT-4 para raciocínio matizado, Google Gemini para trabalho documental de contexto longo e um modelo de imagem especializado para geração — tudo a partir da mesma superfície de produto, sem escrever a lógica de despacho.
Fallback não é um extra simpático
Quedas de fornecedor não são casos raros. Elas acontecem várias vezes por mês no setor inteiro. Se o seu produto depende de um único fornecedor e a API dele degrada, o seu produto degrada junto.
Uma cadeia de fallback é o mínimo operacional: quando o modelo principal devolve um erro transitório para uma solicitação, a plataforma tenta de novo com o próximo melhor modelo apto. Isso pressupõe que a camada de roteamento já saiba quais modelos são aptos — que é precisamente o que o roteamento por capacidades fornece.
O fallback tem outro benefício menos óbvio: mantém previsível o seu comportamento de cobrança. Se o modelo de primeira escolha está temporariamente acima de um limite de uso, desviar para o próximo modelo apto mantém o custo na faixa sem mostrar um erro para quem usa o sistema.
A conclusão prática
Quando avaliar plataformas de IA, faça duas perguntas: como ela escolhe um modelo para cada solicitação, e o que acontece quando esse modelo fica indisponível ou caro demais?
Se a resposta a qualquer uma delas for «ela sempre usa o modelo X», isso é um cheiro arquitetural. Os modelos disponíveis hoje não são os melhores modelos que existirão daqui a seis meses. Novos fornecedores aparecem. Preços se mexem. Fronteiras de capacidade mudam. Uma arquitetura que trata a escolha de modelo como um problema de roteamento — e não como uma decisão de configuração — envelhece melhor, custa menos ao longo do tempo e degrada com mais elegância sob pressão.
Um modelo é um ponto de partida. Uma camada de roteamento é a fundação de verdade.