O problema do «use GPT-4 e pronto»
A maioria das plataformas de IA toma uma decisão silenciosa por você: escolhe um modelo de que gosta, liga tudo nele e segue em frente. Isso funciona até deixar de funcionar — até o modelo cair, até um concorrente lançar algo melhor em uma tarefa específica, até você querer trazer sua própria chave de API e manter os custos na sua conta, até precisar gerar imagens e o modelo padrão não saber fazer isso.
O remédio de sempre é uma lista suspensa. Escolha um modelo, use em todo lugar, se vire com as contrapartidas. Isso não é roteamento; é delegação. O ToRun faz algo estruturalmente diferente.
O pipeline que coloca as capacidades em primeiro lugar
Cada solicitação no ToRun passa por quatro etapas antes de tocar em um modelo.
1. O modo identifica a superfície de produto. Quando você abre uma sessão de Chat ou dispara uma tarefa de Pesquisa, está escolhendo um Modo. O modo não é só um rótulo de interface: ele carrega um conjunto definido de capacidades exigidas e opcionais. Uma tarefa de Pesquisa precisa de ferramentas (busca na web), contexto longo e saída estruturada. Uma sessão básica de chat só precisa de geração de texto por padrão.
2. O conjunto de capacidades vira um filtro. O ToRun mantém um catálogo de modelos de muitos fornecedores — OpenAI, Anthropic/Claude, Google/Gemini, DeepSeek, xAI/Grok, Mistral e outros. Cada entrada carrega a união das capacidades que realmente suporta: visão, ferramentas, execução de código, geração de imagem, áudio de entrada, áudio de saída, geração de vídeo, embeddings, reordenação, streaming em tempo real, raciocínio e mais. O conjunto da etapa um é confrontado com esse catálogo. Os modelos que não atendem a todas as capacidades exigidas são descartados.
3. A classificação preço-qualidade escolhe o vencedor. Entre os modelos que passam pelo filtro, o ToRun ordena conforme o que a solicitação realmente é. Uma pergunta curta e simples é ordenada pelo custo, então você recebe uma resposta rápida e barata. Uma mais longa ou mais difícil é ordenada pela capacidade por unidade de custo, contra um piso de qualidade. Um turno que carrega uma imagem é ordenado por quão bem um modelo enxerga, não por raciocínio por real. Os executores de fluxo mudam para qualidade em primeiro lugar, porque um pipeline automatizado que roda sem supervisão deve buscar o melhor resultado, não o atalho mais barato. Usuários de BYOK entram no preço de outro jeito, porque a solicitação passa pela conta de fornecedor deles.
4. As cadeias de fallback absorvem falhas do fornecedor. Se o modelo escolhido devolve um erro de serviço, o mesmo pipeline roda de novo excluindo esse modelo. O segundo melhor modelo capaz responde. Você não vê erro nenhum, a menos que todos os candidatos viáveis estejam fora do ar.
Um exemplo concreto: visão mais ferramentas
Suponha que você cole uma captura de tela e peça ao ToRun para buscar na web contexto sobre o que ela mostra. Essa solicitação toca duas capacidades ao mesmo tempo: visão (o modelo precisa aceitar uma imagem de entrada) e ferramentas (o modelo precisa poder invocar uma função de busca na web).
Com uma abordagem de modelo único você fica travado: sua plataforma suporta essa combinação ou não. Com roteamento por capacidades, o ToRun cruza os dois requisitos. Só sobrevivem ao filtro os modelos com suporte confirmado a visão E a chamada de ferramentas. Dessa lista curta, a classificação por preço e qualidade escolhe o melhor para o seu modo atual. Se o candidato principal estiver limitado ou fora do ar, o seguinte atende a solicitação sem que você faça nada.
Isso importa na prática: o conjunto de modelos com visão mudou muito no último ano e vai continuar mudando. O roteamento por capacidades faz o ToRun considerar automaticamente os modelos recém-adicionados assim que são catalogados, sem nenhuma atualização da sua parte.
Por que isso vence a dependência
Uma plataforma de modelo único tem uma única estratégia de fallback: esperar o fornecedor consertar a queda. Uma plataforma que coloca capacidades em primeiro lugar tem um catálogo. Quando a OpenAI tem um incidente, as solicitações que a Anthropic ou o Gemini conseguem atender são atendidas lá. Quando um novo modelo da Mistral oferece melhor preço-qualidade em saída estruturada, ele entra na classificação dos modos relevantes sem migração forçada.
A mesma lógica vale para BYOK. Quando você adiciona sua própria chave de API para um fornecedor, essa credencial fica restrita dentro da camada de roteamento. As solicitações que combinam com os modelos capazes daquele fornecedor podem usar sua chave em vez da conta do ToRun, deslocando o custo para a sua relação com o fornecedor na faixa de cobrança adequada. O pipeline de roteamento não muda: só muda qual credencial é usada no momento da execução.
A contrapartida é a honestidade: o ToRun não pode garantir que o modelo mais barato seja o mais inteligente para a sua tarefa. A classificação é explícita — você pode ver o que foi escolhido e por quê, e pode sobrescrever. Essa transparência é o objetivo. Cada solicitação grava um registro de cobrança com o modelo usado, a unidade de preço ativa na execução e o detalhamento do custo. Você pode auditar qualquer chamada meses depois, mesmo após mudanças de tarifa do fornecedor, porque o instantâneo fica congelado no momento em que a solicitação rodou.
Um modelo que faz tudo é uma ficção confortável. O que você quer de verdade é uma plataforma que encontre o modelo certo para cada tarefa e torne essa escolha legível.