O problema do «use o GPT-4 e pronto»
A maioria das plataformas de IA toma uma decisão silenciosa por si: escolhe um modelo de que gosta, liga tudo a ele e segue em frente. Isso funciona até deixar de funcionar — até o modelo cair, até um concorrente lançar algo melhor numa tarefa específica, até querer trazer a sua própria chave de API e manter os custos na sua conta, até precisar de gerar imagens e o modelo por omissão não saber fazê-lo.
O remédio habitual é uma lista pendente. Escolha um modelo, use-o em todo o lado, desenrasque-se com os compromissos. Isso não é encaminhamento; é delegação. O ToRun faz algo estruturalmente diferente.
O canal que põe as capacidades primeiro
Cada pedido no ToRun percorre quatro etapas antes de tocar num modelo.
1. O modo identifica a superfície de produto. Quando abre uma sessão de Conversa ou lança uma tarefa de Investigação, está a escolher um Modo. O modo não é apenas um rótulo de interface: carrega um conjunto definido de capacidades exigidas e opcionais. Uma tarefa de Investigação precisa de ferramentas (pesquisa web), contexto longo e saída estruturada. Uma sessão básica de conversa só precisa de geração de texto por omissão.
2. O conjunto de capacidades torna-se 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, transmissão em tempo real, raciocínio e mais. O conjunto do passo um é confrontado com este catálogo. Os modelos que não satisfazem todas as capacidades exigidas são descartados.
3. A ordenação preço-qualidade escolhe o vencedor. Entre os modelos que passam o filtro, o ToRun ordena conforme o que o pedido realmente é. Uma pergunta curta e simples é ordenada pelo custo, pelo que obtém uma resposta rápida e barata. Uma mais longa ou mais difícil é ordenada pela capacidade por unidade de custo, contra um patamar mínimo de qualidade. Um turno que leva uma imagem é ordenado pela qualidade da visão do modelo, não pelo raciocínio por euro. Os executores de fluxos passam a prioridade à qualidade, porque um canal automatizado que corre sem supervisão deve procurar o melhor resultado, não o atalho mais barato. Os utilizadores de BYOK entram no preço de outra forma, porque o pedido passa pela sua própria conta de fornecedor.
4. As cadeias de recurso absorvem as falhas do fornecedor. Se o modelo escolhido devolver um erro de serviço, o mesmo canal corre de novo excluindo esse modelo. Responde o segundo melhor modelo capaz. Não vê qualquer erro, a menos que todos os candidatos viáveis estejam em baixo.
Um exemplo concreto: visão mais ferramentas
Suponha que cola uma captura de ecrã e pede ao ToRun para procurar na web contexto sobre o que ela mostra. Esse pedido toca duas capacidades ao mesmo tempo: visão (o modelo tem de aceitar uma imagem de entrada) e ferramentas (o modelo tem de poder invocar uma função de pesquisa web).
Com uma abordagem de modelo único, fica preso: a sua plataforma suporta essa combinação ou não. Com encaminhamento por capacidades, o ToRun cruza ambos os requisitos. Só sobrevivem ao filtro os modelos com suporte confirmado de visão E de chamada de ferramentas. Dessa lista curta, a ordenação por preço e qualidade escolhe o melhor para o seu modo atual. Se o candidato principal estiver limitado ou em baixo, o seguinte trata do pedido sem que faça nada.
Isto importa na prática: o conjunto de modelos com visão mudou muito no último ano e continuará a mudar. O encaminhamento por capacidades faz com que o ToRun considere automaticamente os modelos recém-adicionados assim que são catalogados, sem qualquer atualização da sua parte.
Porque isto vence a dependência
Uma plataforma de modelo único tem uma única estratégia de recurso: esperar que o fornecedor repare a avaria. Uma plataforma que põe as capacidades primeiro tem um catálogo. Quando a OpenAI tem um incidente, os pedidos que a Anthropic ou o Gemini conseguem servir são servidos aí. Quando um novo modelo Mistral oferece melhor preço-qualidade em saída estruturada, entra na ordenação dos modos relevantes sem migração forçada.
A mesma lógica aplica-se ao BYOK. Quando adiciona a sua chave de API para um fornecedor, essa credencial fica confinada dentro da camada de encaminhamento. Os pedidos que correspondam aos modelos capazes desse fornecedor podem usar a sua chave em vez da conta ToRun, deslocando o custo para a sua relação com o fornecedor no escalão de faturação adequado. O canal de encaminhamento não muda: só muda que credencial é usada no momento da execução.
O compromisso é a honestidade: o ToRun não pode garantir que o modelo mais barato seja o mais inteligente para a sua tarefa. A ordenação é explícita — pode ver o que foi escolhido e porquê, e pode sobrepor-se. Essa transparência é o objetivo. Cada pedido escreve um registo de faturação com o modelo usado, a unidade de preço ativa na execução e a repartição do custo. 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 o pedido correu.
Um modelo que faz tudo é uma ficção confortável. O que quer de facto é uma plataforma que encontre o modelo certo para cada tarefa e torne essa escolha legível.