El problema de «usa GPT-4 y ya»
La mayoría de las plataformas de IA toman una decisión silenciosa por ti: eligen un modelo que les gusta, conectan todo a él y siguen adelante. Eso funciona hasta que deja de funcionar — hasta que el modelo se cae, hasta que un competidor saca algo mejor para una tarea concreta, hasta que quieres traer tu propia clave de API y mantener los costes en tu cuenta, hasta que necesitas generar imágenes y tu modelo por defecto no sabe hacerlo.
El remedio habitual es un desplegable. Elige un modelo, úsalo en todas partes, apáñate tú con las contrapartidas. Eso no es enrutado; es delegación. ToRun hace algo estructuralmente distinto.
La tubería de capacidades primero
Cada petición en ToRun pasa por cuatro etapas antes de tocar un modelo.
1. El modo identifica la superficie de producto. Cuando abres una sesión de Chat o lanzas una tarea de Investigación, estás eligiendo un Modo. El modo no es solo una etiqueta de interfaz: lleva un conjunto definido de capacidades requeridas y opcionales. Una tarea de Investigación necesita herramientas (búsqueda web), contexto largo y salida estructurada. Una sesión de chat básica solo necesita generación de texto por defecto.
2. El conjunto de capacidades se vuelve un filtro. ToRun mantiene un catálogo de modelos de muchos proveedores — OpenAI, Anthropic/Claude, Google/Gemini, DeepSeek, xAI/Grok, Mistral y otros. Cada entrada lleva la unión de capacidades que realmente soporta: visión, herramientas, ejecución de código, generación de imagen, audio de entrada, audio de salida, generación de vídeo, embeddings, reordenación, streaming en tiempo real, razonamiento y más. El conjunto del paso uno se contrasta con este catálogo. Los modelos que no satisfacen todas las capacidades requeridas se descartan.
3. La clasificación precio/calidad elige al ganador. Entre los modelos que pasan el filtro, ToRun ordena según lo que realmente es la petición. Una pregunta corta y sencilla se ordena por coste, así que obtienes una respuesta rápida y barata. Una más larga o más difícil se ordena por capacidad por unidad de coste, contra un suelo de calidad. Un turno que lleva una imagen se ordena por lo bien que ve un modelo, no por razonamiento por dólar. Los ejecutores de flujos cambian a calidad primero, porque una tubería automatizada que corre sin que la mires debería elegir el mejor resultado y no el atajo más barato. Los usuarios de BYOK entran en el precio de otra forma, porque la petición pasa por su propia cuenta de proveedor.
4. Las cadenas de reserva absorben los fallos del proveedor. Si el modelo elegido devuelve un error de servicio, la misma tubería se ejecuta de nuevo excluyendo ese modelo. Responde el segundo mejor modelo capaz. No te aparece ningún error salvo que todos los candidatos viables estén caídos.
Un ejemplo concreto: visión más herramientas
Supón que pegas una captura de pantalla y le pides a ToRun que busque en la web contexto sobre lo que muestra. Esa petición toca dos capacidades a la vez: visión (el modelo debe aceptar una imagen de entrada) y herramientas (el modelo debe poder invocar una función de búsqueda web).
Con un enfoque de modelo único te quedas atascado: tu plataforma soporta esa combinación o no. Con enrutado por capacidades, ToRun cruza ambos requisitos. Solo sobreviven al filtro los modelos con soporte confirmado de visión Y de llamada a herramientas. De esa lista corta, la clasificación por precio y calidad elige lo mejor para tu modo actual. Si el candidato principal está limitado o caído, el siguiente atiende la petición sin que hagas nada.
Esto importa en la práctica: el conjunto de modelos con visión ha cambiado mucho en el último año y seguirá cambiando. El enrutado por capacidades hace que ToRun considere automáticamente los modelos recién añadidos en cuanto se catalogan, sin ninguna actualización por tu parte.
Por qué esto gana al encierro
Una plataforma de modelo único tiene una sola estrategia de reserva: esperar a que el proveedor arregle su caída. Una plataforma de capacidades primero tiene un catálogo. Cuando OpenAI tiene un incidente, las peticiones que puedan servir Anthropic o Gemini se sirven allí. Cuando un nuevo modelo de Mistral ofrece mejor precio/calidad en salida estructurada, entra en la clasificación de los modos relevantes sin migración forzada.
La misma lógica aplica a BYOK. Cuando añades tu propia clave de API para un proveedor, esa credencial queda acotada dentro de la capa de enrutado. Las peticiones que encajen con los modelos capaces de ese proveedor pueden tirar de tu clave en lugar de la cuenta de ToRun, trasladando el coste a tu relación con el proveedor en el nivel de facturación adecuado. La tubería de enrutado no cambia: solo cambia qué credencial se usa en el momento de la ejecución.
La contrapartida es la honestidad: ToRun no puede garantizar que el modelo más barato sea el más inteligente para tu tarea. La clasificación es explícita — puedes ver qué se eligió y por qué, y puedes anularla. Esa transparencia es el objetivo. Cada petición escribe un registro de facturación con el modelo usado, la unidad de precio activa en la ejecución y el desglose del coste. Puedes auditar cualquier llamada meses después, incluso tras cambios de precio del proveedor, porque la instantánea queda congelada en el momento en que la petición corrió.
Un modelo que lo hace todo es una ficción cómoda. Lo que de verdad quieres es una plataforma que encuentre el modelo adecuado para cada tarea y haga esa elección legible.