Elegir un único modelo de inteligencia artificial para una aplicación empieza a tener menos sentido a medida que aumenta el número de LLM disponibles. Auto Router de OpenRouter propone cambiar ese planteamiento: la aplicación envía la petición y el sistema decide dinámicamente qué modelo resulta más adecuado para resolverla, teniendo en cuenta el tipo de tarea, el nivel de coste seleccionado y las restricciones establecidas por el desarrollador. Es una capa de infraestructura que gana interés justo cuando Stripe ha acordado adquirir OpenRouter.
Las claves de Auto Router de OpenRouter en 20 segundos
- Auto Router permite utilizar
openrouter/autoen lugar de seleccionar manualmente un LLM. - Clasifica la petición y utiliza datos agregados de gasto de los últimos siete días para escoger modelos.
- El desarrollador puede establecer distintos niveles de coste y restricciones de privacidad o proveedores.
- Puede formar parte de arquitecturas que combinen modelos locales y cloud.
- Stripe ha acordado adquirir OpenRouter, reforzando el interés por esta nueva capa de infraestructura de IA.
La idea parece sencilla, pero puede cambiar bastante la arquitectura de muchas aplicaciones de inteligencia artificial.
Hasta ahora lo habitual ha sido escoger primero el modelo. Una empresa decide utilizar GPT, Claude, Gemini, DeepSeek, Qwen o cualquier otra familia y construye buena parte de su aplicación alrededor de esa elección.
Después intenta reducir costes mediante prompts más pequeños, caché, límites de contexto o modelos secundarios.
Auto Router plantea la decisión desde el otro extremo.
Primero llega el trabajo.
Después se decide qué modelo debería hacerlo.
Cómo funciona Auto Router de OpenRouter
OpenRouter proporciona una API común desde la que pueden utilizarse centenares de modelos y proveedores. Auto Router añade una capa encargada de decidir cuál utilizar sin que la aplicación tenga que especificarlo previamente.
En lugar de indicar el identificador de GPT, Claude, Gemini o DeepSeek, el desarrollador puede utilizar:
openrouter/auto
La petición entra entonces en el sistema de routing.
OpenRouter explica que Auto Router clasifica los prompts por el tipo de trabajo que representan y utiliza el comportamiento agregado de su propia comunidad para determinar qué modelos están siendo utilizados para tareas similares.
Y aquí aparece uno de los detalles más interesantes.
La decisión se apoya en el gasto observado durante una ventana móvil de siete días. Si aparece un modelo nuevo y los desarrolladores comienzan a utilizarlo intensamente para programación, razonamiento o cualquier otra categoría, esa actividad puede influir posteriormente en el routing.
La compañía lo define como aprovechar la “sabiduría del mercado”.
No significa que Auto Router pregunte a los usuarios qué modelo consideran mejor. Observa dónde están gastando realmente su dinero para resolver cada clase de tarea.
La documentación oficial explica además que las conversaciones de varios turnos mantienen el mismo modelo mientras continúe siendo una de las opciones principales para ese trabajo. Esto ayuda a evitar cambios constantes de LLM dentro de una misma conversación.
El sistema permite también establecer el parámetro cost_tier.
| Nivel | Prioridad aproximada |
|---|---|
low | Mayor atención a la eficiencia económica |
medium | Escalón intermedio de coste |
high | Permite acceder a opciones más caras |
xhigh | Amplía todavía más el presupuesto |
max | Máxima flexibilidad de coste |
El nivel predeterminado es low, por lo que Auto Router parte de una configuración orientada a contener el coste. La petición se factura finalmente al precio del modelo seleccionado, según explica OpenRouter.
También respeta las restricciones establecidas por el usuario o la organización, incluidas políticas de privacidad y Zero Data Retention (ZDR), así como limitaciones sobre determinados modelos.
Esto último es importante para producción.
Un router que simplemente eligiera el modelo más barato podría terminar enviando información a proveedores que una empresa no quiere utilizar. La selección necesita convivir con las políticas técnicas, económicas y de privacidad de cada organización.
La combinación más interesante puede ser local + Auto Router
Auto Router resulta todavía más atractivo cuando se piensa más allá de OpenRouter.
Una empresa no tiene por qué enviar todas sus peticiones a servicios externos.
Los modelos pequeños están mejorando rápidamente y algunos pueden ejecutarse sobre infraestructura propia con costes relativamente contenidos. Familias como Qwen están demostrando que muchas tareas cotidianas no requieren necesariamente recurrir a un modelo de frontera.
Un modelo local como Qwen3.5-9B, por ejemplo, puede encargarse de una parte del trabajo dependiendo de la aplicación y del hardware disponible.
Clasificar información, resumir documentos sencillos, extraer determinados campos, transformar formatos o ejecutar algunas tareas internas pueden ser candidatos para procesamiento local.
Ahí aparece una arquitectura especialmente interesante.
La aplicación puede disponer de una función de delegación que primero determine si el trabajo puede resolverse localmente. Cuando la dificultad, el contexto o las capacidades necesarias superen determinado umbral, la tarea puede enviarse a un servicio externo.
Y tampoco sería necesario decidir siempre qué servicio.
Auto Router puede ocuparse de la siguiente selección.
Así, una tarea sencilla podría resolverse localmente prácticamente sin coste variable por token. Otra podría terminar en un modelo cloud económico y rápido. Un problema de programación podría dirigirse hacia un modelo especialmente utilizado para código. Y una petición que requiera mayor capacidad de razonamiento podría justificar temporalmente un modelo considerablemente más caro.
El usuario únicamente ve el resultado.
Esta separación entre aplicación, router y modelo puede terminar siendo mucho más importante de lo que parece.
El mejor modelo puede cambiar cada semana
Hay una razón bastante evidente para adoptar este planteamiento: el mercado de los LLM se mueve demasiado rápido.
Durante una etapa inicial de la IA generativa resultaba relativamente razonable seleccionar uno de los pocos grandes modelos disponibles y construir alrededor de él.
Ahora la situación es diferente.
OpenAI, Anthropic y Google compiten con modelos diferentes para distintos niveles de rendimiento y coste. Meta mantiene su familia Llama. Mistral desarrolla alternativas propias. Y fabricantes chinos como DeepSeek o Qwen están presionando especialmente la relación entre precio y capacidad.
El resultado es que el mejor modelo para una tarea concreta en agosto puede no serlo en octubre.
Incluso dentro del mismo día pueden existir motivos para utilizar modelos distintos.
Un chatbot de atención al cliente puede recibir miles de preguntas sencillas y unas pocas consultas realmente complejas. Ejecutarlas todas sobre el modelo más potente disponible desperdicia recursos.
El extremo contrario tampoco funciona.
Utilizar siempre el modelo más barato puede reducir la calidad precisamente en aquellas peticiones donde una respuesta incorrecta resulta más costosa.
El routing intenta encontrar el espacio intermedio.
La pregunta deja de ser:
“¿Qué LLM debería utilizar esta aplicación?”
Y pasa a ser:
“¿Qué LLM debería resolver esta petición concreta?”
Ese cambio parece pequeño, pero afecta directamente a los costes de inferencia.
El precio por token deja de ser la única métrica
La industria de la IA suele comparar modelos mediante precios por millón de tokens.
Es una métrica necesaria, pero incompleta.
Supongamos que un modelo cuesta la mitad que otro pero necesita generar respuestas mucho más largas, repetir llamadas o utilizar herramientas adicionales para completar una tarea. El ahorro teórico puede desaparecer.
También importa la velocidad.
Una aplicación interactiva puede preferir pagar ligeramente más por reducir la latencia. Una tarea nocturna de procesamiento documental probablemente pueda esperar.
Después está el throughput: cuántas peticiones o tokens puede procesar realmente la infraestructura.
Y aparecen otros criterios: tamaño de contexto, soporte multimodal, tool calling, salidas estructuradas, privacidad, disponibilidad regional o compatibilidad con determinadas herramientas.
Por eso el futuro del routing probablemente irá bastante más allá de buscar simplemente “el modelo más barato”.
Cada aplicación podrá definir su propia función de decisión.
Coste + calidad + latencia + disponibilidad + privacidad + capacidades.
El peso de cada variable dependerá del trabajo.
Auto Router representa una de las primeras implementaciones comerciales de esta idea a gran escala, aunque su mecanismo concreto no debe confundirse con un optimizador universal de todas esas variables. La versión actual utiliza principalmente clasificación de tareas, gasto reciente de la comunidad, niveles de coste y las restricciones definidas por el usuario.
Stripe puede estar comprando una pieza mucho más importante de lo que parece
La adquisición acordada de OpenRouter por Stripe resulta especialmente interesante vista desde esta perspectiva.
OpenRouter no es un fabricante de modelos.
Tampoco necesita ganar la carrera para construir el LLM más potente.
Su posición está entre las aplicaciones y los modelos.
La compañía afirma procesar más de 10 billones de tokens diarios y proporciona acceso a cientos de modelos. Cada una de esas peticiones contiene información sobre qué modelos están utilizando realmente los desarrolladores, para qué trabajos y a qué precios.
Ese lugar dentro de la cadena puede tener mucho valor.
Stripe hizo algo conceptualmente parecido con los pagos.
Una tienda online no quiere negociar individualmente cada transacción con bancos, tarjetas y métodos de pago. Quiere enviar una operación a una infraestructura que se encargue de gestionar buena parte de esa complejidad.
La IA empieza a necesitar su propia capa de intermediación.
Una aplicación tampoco debería tener que reescribirse cada vez que aparece un modelo mejor.
Podría enviar la tarea a una infraestructura que decida dónde ejecutarla.
La similitud no significa que pagos e inferencia sean técnicamente equivalentes, pero ayuda a entender por qué una empresa como Stripe puede encontrar interesante OpenRouter.
Especialmente si la inteligencia artificial evoluciona hacia un mercado donde las aplicaciones consumen modelos de múltiples proveedores simultáneamente.
La competencia china hace todavía más útil el routing
La llegada de modelos chinos competitivos añade otra variable.
DeepSeek y Qwen han demostrado que la frontera entre modelos occidentales y chinos puede cambiar rápidamente, especialmente cuando se compara rendimiento por dólar.
Para una empresa que haya construido toda su plataforma alrededor de un único proveedor, aprovechar esas mejoras implica evaluar el nuevo modelo, integrarlo y modificar parte de su infraestructura.
Con una capa intermedia la situación cambia.
Un modelo nuevo puede incorporarse al catálogo y empezar a recibir determinadas tareas sin alterar el funcionamiento general de la aplicación.
OpenRouter lleva esta idea todavía más lejos con su ventana móvil de siete días: si la comunidad comienza a gastar más en un nuevo modelo para una categoría concreta, Auto Router puede reflejar progresivamente ese comportamiento.
Eso convierte la competencia entre fabricantes en una ventaja potencial para quien consume IA.
Cuantos más modelos buenos existan, más posibilidades tiene el router de encontrar una combinación favorable.
Y cuanto mejores sean los modelos pequeños ejecutados localmente, menor será además la proporción de tareas que necesitará llegar a la nube.
Puede terminar apareciendo una arquitectura bastante habitual: modelos locales para volumen, modelos cloud económicos para tareas intermedias y modelos de frontera para el porcentaje realmente difícil.
En ese escenario la empresa no compra “un LLM”.
Compra capacidad de inteligencia bajo demanda.
Auto Router anticipa una IA donde el modelo será casi invisible
Hay una analogía con la infraestructura cloud que resulta difícil evitar.
Cuando una aplicación se ejecuta en una plataforma moderna, el usuario normalmente no sabe qué servidor físico está atendiendo cada petición. Puede cambiar de máquina, región o incluso infraestructura sin que eso modifique su experiencia.
Con los modelos puede ocurrir algo parecido.
Hoy todavía preguntamos constantemente qué LLM hay detrás de cada producto.
Puede que dentro de unos años esa pregunta tenga mucha menos importancia.
Una aplicación podría utilizar cinco, diez o veinte modelos diferentes durante una jornada. Algunos locales. Otros comerciales. Algunos especializados en código. Otros en visión, razonamiento o velocidad.
El router se encargaría de decidir.
Eso también cambiaría la competencia entre los propios fabricantes. Ser el modelo más famoso dejaría de ser suficiente si otro ofrece mejor relación entre calidad y coste para una categoría concreta y los routers comienzan a enviarle automáticamente millones de peticiones.
Los modelos competirían petición a petición.
Por eso Auto Router puede terminar siendo bastante más importante que otra función dentro del catálogo de OpenRouter.
Representa una idea que probablemente veremos repetirse en muchas plataformas: separar la aplicación del modelo que ejecuta cada trabajo.
Con LLM locales cada vez mejores, modelos chinos presionando los precios y una oferta cloud que cambia prácticamente cada semana, comprometer toda una aplicación con un único modelo empieza a parecer una decisión menos evidente.
La carrera ya no consiste únicamente en fabricar el mejor LLM.
También empieza otra para decidir qué LLM utilizar, para qué tarea y en qué momento.
Y ahí Auto Router acaba de colocarse en una posición especialmente interesante.
Preguntas frecuentes
¿Qué es Auto Router de OpenRouter?
Auto Router permite enviar peticiones utilizando openrouter/auto sin seleccionar previamente un modelo concreto. El sistema clasifica el tipo de tarea y selecciona automáticamente un LLM dentro de las restricciones y el nivel de coste establecidos.
¿Auto Router selecciona siempre el modelo más barato?
No. Dispone de diferentes niveles mediante cost_tier y utiliza información sobre el tipo de tarea y el comportamiento reciente de la comunidad. La petición se factura al precio del modelo finalmente seleccionado.
¿Puede Auto Router combinarse con un LLM local?
Sí, aunque la decisión entre ejecución local y OpenRouter debe realizarla la propia aplicación o su capa de orquestación. Esto permite reservar los modelos cloud para tareas que realmente necesiten mayor capacidad.
¿Por qué puede ser importante Auto Router para Stripe?
Stripe ha acordado adquirir OpenRouter, una plataforma situada entre las aplicaciones y cientos de modelos y proveedores de IA. Si el mercado evoluciona hacia aplicaciones multimodelo, el routing y la gestión económica de ese consumo pueden convertirse en una capa relevante de infraestructura.
