La carrera por tener “el mejor modelo de inteligencia artificial” empieza a quedarse pequeña frente a una idea bastante más práctica: utilizar un modelo diferente para cada trabajo y decidirlo automáticamente en el momento de ejecutar la tarea. OpenRouter está llevando este enfoque un paso más allá con Auto Router, justo cuando Stripe ha acordado adquirir la compañía para reforzar su posición en la infraestructura que gestiona el consumo de modelos de IA.
Las claves del enrutamiento automático de modelos en 30 segundos
- OpenRouter Auto Router clasifica cada petición y selecciona un modelo según el tipo de tarea y el nivel de coste elegido.
- La decisión se actualiza con datos agregados de uso de los últimos siete días.
- Una arquitectura puede combinar modelos locales baratos con modelos cloud más capaces solo cuando hacen falta.
- OpenRouter procesa ya más de 10 billones de tokens diarios entre más de 400 modelos.
- Stripe ha acordado adquirir OpenRouter, señal de que el enrutamiento de tokens empieza a convertirse en una capa propia de infraestructura.
Hasta ahora muchas aplicaciones de IA se han construido con una decisión tomada casi al principio del proyecto: escoger un gran modelo de lenguaje (LLM) y enviarle prácticamente todo. Puede ser GPT, Claude, Gemini, DeepSeek, Qwen o cualquier otro. Después se intenta controlar la factura ajustando prompts, cachés, número de tokens o tamaño del contexto.
Hay otra posibilidad cada vez más interesante: dejar de tratar el modelo como una elección permanente.
Una aplicación puede utilizar un modelo local pequeño para clasificar mensajes, resumir textos sencillos, extraer campos o ejecutar tareas rutinarias. Cuando llega un problema más complejo puede delegarlo en un modelo cloud especializado en programación, razonamiento, investigación o agentes. Y para una petición especialmente difícil puede escalar temporalmente a un modelo de mayor coste.
El usuario no tiene por qué saber qué ha ocurrido detrás.
Pide una tarea. La plataforma decide quién debería resolverla.
Auto Router convierte el modelo en una decisión dinámica
OpenRouter funciona como una capa intermedia que permite acceder mediante una API común a centenares de modelos de distintos fabricantes y proveedores.
Su nuevo Auto Router introduce una idea sencilla de explicar, aunque bastante más complicada de ejecutar: el desarrollador puede dejar de especificar qué LLM quiere utilizar y enviar la petición a openrouter/auto.
A partir de ahí, OpenRouter elige.
La documentación actual explica que el sistema analiza cada prompt mediante un clasificador ligero y lo asigna a aproximadamente 30 tipos de tareas diferentes. Puede identificar, por ejemplo, depuración de código, planificación de agentes, preguntas de conocimiento, matemáticas, soporte al cliente o elaboración de informes de investigación.
Después observa qué modelos está utilizando realmente la comunidad de OpenRouter para ese tipo de trabajo.
Y aquí aparece una de las peculiaridades del sistema.
No depende únicamente de un benchmark elaborado meses atrás. Auto Router estudia el gasto agregado realizado en los modelos durante los siete días anteriores, de manera que las preferencias pueden cambiar cuando aparece una opción nueva que los desarrolladores comienzan a utilizar.
OpenRouter describe este mecanismo como una forma de aprovechar la “sabiduría del mercado”.
El usuario puede introducir además un nivel de coste mediante cost_tier, con las opciones low, medium, high, xhigh y max. El nivel predeterminado es low. La plataforma selecciona después candidatos dentro de esa franja y mantiene modelos alternativos por si el principal no está disponible.
| Decisión | Qué puede tener en cuenta la capa de routing |
|---|---|
| Tipo de trabajo | Código, investigación, agentes, preguntas, soporte… |
| Presupuesto | Diferentes niveles de coste |
| Modelo disponible | Cambia a medida que aparecen nuevas opciones |
| Restricciones | Modelos o proveedores permitidos |
| Privacidad | Políticas como Zero Data Retention |
| Conversación | Puede mantener el mismo modelo entre turnos |
| Fallos | Utiliza modelos alternativos cuando es necesario |
Conviene precisar un detalle. El Auto Router oficial no se documenta simplemente como un algoritmo que puntúa directamente precio, latencia y throughput en cada petición. Su mecanismo actual se apoya principalmente en clasificación de tarea, cuota de gasto reciente, nivel de coste y las restricciones definidas por el usuario. OpenRouter dispone además de otras funciones de routing y elección de proveedores que permiten controlar características operativas.
Es una diferencia técnica, pero también ayuda a entender hacia dónde está evolucionando esta industria.
El modelo empieza a parecerse menos a “la aplicación” y más a un recurso de computación que puede asignarse dinámicamente.
Un Qwen local para lo cotidiano y la nube para lo difícil
Este planteamiento se vuelve todavía más interesante cuando se combina con modelos locales.
Qwen3.5-9B es un buen ejemplo. Se trata de un modelo de 9.000 millones de parámetros publicado con licencia Apache 2.0 y compatible con herramientas como Transformers, vLLM, SGLang y KTransformers. Su versión actual admite además entrada multimodal y un contexto nativo de 262.144 tokens.
Un modelo de este tamaño puede ejecutarse sobre infraestructura propia razonable, especialmente utilizando cuantización.
Eso cambia la economía de un agente.
No todas sus operaciones necesitan atravesar una API comercial.
Un flujo de trabajo podría utilizar el modelo local para resolver una parte sustancial de las tareas: clasificar solicitudes, transformar formatos, resumir pequeños documentos, decidir qué herramienta llamar o procesar información que no necesita un modelo de frontera.
Cuando el trabajo exceda sus capacidades, aparece la delegación.
Una función como delegate_task, por ejemplo, puede actuar como abstracción dentro de un agente: la aplicación describe qué necesita resolver y una capa intermedia decide si debe utilizar el modelo local o enviar esa tarea a otro LLM.
La arquitectura conceptual empieza a parecerse a esto: local por defecto cuando es suficiente, cloud cuando aporta valor y modelos más caros únicamente para los problemas que realmente los necesitan.
No existe una única combinación correcta.
Un equipo podría preferir que toda la información sensible se procese localmente. Otro podría priorizar latencia. Un tercero puede permitir varios proveedores cloud pero fijar un coste máximo. Una aplicación de programación puede enviar código complejo a un modelo especializado mientras reserva traducciones y resúmenes para modelos mucho más económicos.
Y las decisiones pueden cambiar sin modificar el resto de la aplicación.
Este último punto es probablemente uno de los más importantes.
Durante los últimos dos años hemos visto aparecer nuevos modelos capaces de alterar la relación entre precio y rendimiento en cuestión de semanas. DeepSeek, Qwen y otros desarrolladores chinos han aumentado además la presión competitiva sobre los proveedores estadounidenses.
Si una aplicación está completamente acoplada a un único modelo, beneficiarse de esa competencia requiere trabajo.
Si existe una capa de routing, el cambio puede producirse mucho más arriba en la arquitectura.
Stripe no está comprando otro chatbot
La decisión de Stripe ayuda a entender el valor potencial de esta capa.
El 19 de agosto Stripe anunció un acuerdo para adquirir OpenRouter. Es importante utilizar esa formulación: la adquisición ha sido acordada, no debe darse por cerrada mientras no se complete formalmente la operación.
OpenRouter afirma gestionar actualmente más de 10 billones de tokens diarios, dar acceso a más de 400 modelos y trabajar con una comunidad superior a los 10 millones de desarrolladores y empresas. Según la propia compañía, su volumen de inferencia ha crecido al menos diez veces cada año desde su creación.
Esas cifras ayudan a explicar el interés de Stripe.
Stripe lleva años resolviendo un problema parecido en otro sector.
Cuando alguien paga en una tienda online, detrás puede existir una cadena de decisiones sobre método de pago, banco, autorización, prevención del fraude, divisa o ruta de procesamiento. El comercio no quiere gestionar manualmente cada elemento de esa complejidad.
Con la IA está apareciendo algo parecido.
Una empresa puede terminar consumiendo miles de millones de tokens repartidos entre diferentes proveedores, precios, contextos, modelos, regiones y niveles de rendimiento.
El problema ya no consiste únicamente en llamar a una API.
Consiste en decidir dónde enviar cada token.
Stripe ya había comenzado a trabajar sobre esta parte del mercado mediante productos relacionados con facturación por tokens. En el anuncio de la adquisición explica expresamente que la optimización no consiste únicamente en reducir el coste, sino también en enrutar adecuadamente ese consumo.
Visto desde ahí, OpenRouter encaja bastante mejor dentro de Stripe de lo que podría parecer inicialmente.
Una compañía se especializó en mover dinero entre múltiples piezas del sistema financiero.
La otra está construyendo infraestructura para mover peticiones entre múltiples sistemas de inteligencia artificial.
La guerra de modelos puede acabar beneficiando al router
Hay además una consecuencia bastante curiosa.
Cuantos más modelos buenos existan, más útil puede resultar una plataforma que sepa escoger entre ellos.
Si solo hubiera un proveedor claramente superior en prácticamente todo, el routing tendría menos sentido.
Pero el mercado está evolucionando justo en la dirección contraria.
Un modelo puede ser extraordinario programando pero demasiado caro para clasificar correos. Otro puede responder muy rápido y resultar perfecto para una aplicación interactiva. Un tercero puede ofrecer una relación coste/rendimiento difícil de igualar para millones de peticiones sencillas. Un modelo local puede tener calidad suficiente para resolver el 60 % o el 80 % de un flujo concreto sin coste variable por token.
Incluso puede ocurrir que el ganador cambie un martes.
El nuevo Auto Router de OpenRouter intenta precisamente adaptarse a ese movimiento utilizando una ventana de siete días. Cuando los desarrolladores trasladan cargas hacia un nuevo modelo, sus datos de gasto empiezan a reflejarlo y el routing puede reaccionar.
La propia OpenRouter publicó resultados en los que su nuevo mecanismo consigue reducir considerablemente el coste respecto a su router anterior en algunos benchmarks, aunque no en todos. En determinadas pruebas de investigación, por ejemplo, el modelo anterior resultó más barato. Son pruebas de la propia compañía y no deberían interpretarse como una garantía de ahorro para cualquier aplicación.
Ese matiz importa.
El routing automático tampoco hace desaparecer los problemas.
Cambiar de modelo puede invalidar cachés de contexto. Dos LLM pueden responder de forma distinta al mismo prompt. No todos soportan las mismas herramientas, formatos estructurados, ventanas de contexto o capacidades multimodales. Una aplicación regulada puede necesitar excluir determinados proveedores. Y la latencia puede variar considerablemente.
Por eso Auto Router mantiene cierta “adherencia” entre turnos de una misma conversación y respeta restricciones de modelos, proveedores y políticas de privacidad.
Pero la tendencia resulta difícil de ignorar.
Durante la primera etapa de la IA generativa la gran pregunta era qué modelo utilizar.
La siguiente puede ser muy diferente:
¿por qué debería una aplicación utilizar siempre el mismo?
Con modelos locales cada vez más capaces, LLM chinos presionando los precios, proveedores cloud compitiendo en rendimiento y plataformas capaces de decidir dinámicamente dónde ejecutar cada tarea, el objetivo puede dejar de ser encontrar un ganador absoluto.
El objetivo será conseguir que cada token termine en el modelo que tenga más sentido en ese momento.
Y quizá esa sea precisamente la parte de OpenRouter que Stripe está viendo con mayor claridad.
Preguntas frecuentes
¿Qué es Auto Router de OpenRouter?
Auto Router es un sistema que permite enviar una petición sin especificar previamente un LLM concreto. OpenRouter clasifica la tarea y selecciona un modelo utilizando datos recientes de utilización, el nivel de coste elegido y las restricciones configuradas.
¿Auto Router utiliza siempre el modelo más barato?
No. El usuario puede definir diferentes niveles mediante cost_tier, desde low hasta max. El sistema busca modelos adecuados dentro de la franja elegida y tiene en cuenta además las restricciones definidas para la petición o la cuenta.
¿Se pueden combinar modelos locales con OpenRouter?
Sí, pero esa lógica híbrida debe construirse en la propia aplicación o mediante una capa de orquestación. Un agente puede resolver determinadas tareas con un modelo local y delegar otras en modelos accesibles mediante OpenRouter.
¿Stripe ya ha comprado OpenRouter?
Stripe anunció el 19 de agosto de 2026 que ha acordado adquirir OpenRouter. Mientras la operación no se complete formalmente, es más preciso hablar de un acuerdo de adquisición que de una compra ya cerrada.
