AIREITEREl 28 de octubre de 2026, OpenRouter reconstruyó su sistema de routing predeterminado: el tiempo hasta el primer token bajó un 16,9 %, los eventos 429 totales se redujeron un 67 % y las solicitudes pasaron a costar aproximadamente un 6 % más. El routing automático todavía puede enviarte silenciosamente a un proveedor más caro, así que conviene entender bien el intercambio.
El nuevo router de OpenRouter ya no elige al proveedor con el precio más bajo por token de entrada. Estima cuánto cuesta obtener una respuesta útil —precio, espera y reintentos— y envía cada solicitud al proveedor con el menor Routing Cost.
La conclusión en 30 segundos, con datos
El routing de proveedores de OpenRouter ahora optimiza el Routing Cost en lugar del precio de los tokens del prompt. El cambio se aplica automáticamente cuando la solicitud no define explícitamente provider.sort, provider.order, provider.only o provider.ignore. Abarca aproximadamente el 77 % del tráfico dirigido a modelos ofrecidos por más de un proveedor, según el anuncio de OpenRouter.
Los resultados proceden de una prueba switchback de una semana con 24 millones de solicitudes y 103.000 millones de tokens de entrada, repartidas a partes iguales entre el router antiguo y el nuevo.
| Métrica | Router antiguo | Router nuevo | Cambio* |
|---|---|---|---|
| TTFT p50 | 1.007 ms | 837 ms | 16,9 % menos |
| Rendimiento p50 | 62,4 tok/s | 72,6 tok/s | 16,3 % más |
| Solicitudes con al menos un 429 | 7,1 % | 3,8 % | 3,3 puntos menos; un 67 % menos de eventos 429 en total |
| Solicitudes que necesitaron un reintento | 10,4 % | 6,9 % | 3,5 puntos menos; un 47 % menos de reintentos en total |
| Coste por 1.000 solicitudes | $1.25 | $1.32 | 6,0 % más |
| Coste por millón de tokens | $0.301 | $0.324 | 7,3 % más |
\* Tanto las cifras sobre proporción de solicitudes como las reducciones en el número de eventos aparecen en el anuncio: el 67 % y el 47 % se refieren al total de eventos 429 y al total de reintentos, no a la proporción entre tasas, ya que una misma solicitud puede sufrir varios errores.
Según el anuncio, el TTFT p95 medido por el cliente bajó de 6.032 ms a 4.504 ms, el p50 de la solicitud completa pasó de 4,00 s a 3,24 s y el tiempo desperdiciado en intentos fallidos se redujo de 349 ms a 242 ms por solicitud.
En resumen: mantén el nuevo valor predeterminado para chat interactivo o agentes si puedes asumir un coste aproximadamente un 6 % mayor; vuelve al routing basado solo en precio para trabajos por lotes grandes en los que cada céntimo cuenta.
Routing Cost explicado sin jerga
Routing Cost responde a dos preguntas para cada proveedor: cuánto cuesta cada intento y con qué frecuencia funciona. El ejemplo de OpenRouter es el siguiente: un intento de $0.40 más $0.60 de espera equivalen a $1.00; al dividirlo entre una probabilidad de éxito del 80 %, el coste es de $1.25 por respuesta válida. El proveedor con el coste más bajo recibe más tráfico.
Ese cálculo utiliza tres factores:
- Precio efectivo, no el de catálogo. OpenRouter estima los tokens de entrada y salida a partir del tráfico reciente y aplica la tasa real de aciertos de caché y los precios por token de cada proveedor. El ejemplo del anuncio: 40.000 entradas sin caché a $2.00/M ($0.080), más 60.000 entradas en caché a $0.50/M ($0.030), más unos 4.000 tokens de salida a $8.00/M ($0.032), dan un total de $0.142. Un proveedor con entradas baratas pero tokens en caché o de salida caros pierde aquí su ventaja.
- El tiempo de espera convertido en dinero. El rendimiento se calcula como tokens de salida por segundo de extremo a extremo, incluido el tiempo hasta el primer token (por ejemplo: 5 segundos hasta el primer token más 500 tokens en 5 segundos = 50 tok/s). El router convierte la espera utilizando una tarifa por modelo basada en los precios y velocidades habituales de los proveedores. El tiempo hasta el primer token tiene un peso adicional porque las cadenas de llamadas a herramientas de los agentes dependen de él en cada paso.
- Coste de los fallos. Un 429 significa que el proveedor ha rechazado la solicitud: hay que esperar a la respuesta de rechazo y reenviarla a otro sitio (por ejemplo, una espera de 2,50 más una penalización multiplicada por una tasa del 0,4 % añade 0,01). Los errores de fiabilidad tienen una penalización mayor, de aproximadamente 8 veces (una tasa de error del 1 % eleva el coste alrededor de un 8 %), y los proveedores muy por debajo de sus competidores dejan de recibir tráfico hasta recuperarse. La calidad comprueba actualmente que las llamadas a herramientas estén bien formadas (un 95 % de llamadas correctas eleva el coste aproximadamente un 5 %); los proveedores señalados quedan limitados a tráfico de prueba, según el anuncio.
Dos mecanismos evitan que todo el tráfico acabe concentrado en un único ganador, según el anuncio: cada proveedor conserva una pequeña cantidad de tráfico para que su recuperación pueda detectarse, y el router reduce el tráfico de los proveedores que fallan mientras aprende los límites de capacidad de cada uno y desvía el exceso a otros.
Por qué el routing predeterminado todavía puede romper una app en producción
Los informes de usuarios muestran cuatro fallos recurrentes que el precio por token no refleja.
Los saltos entre llamadas rompen los esquemas
Lo que realmente rompió las llamadas a herramientas fue el salto a mitad de la solicitud, no el precio anunciado de un proveedor concreto.
— u/Michael_Jeffords, hilo de r/openrouter sobre proveedores que conviene evitar
Hoy, la puntuación de calidad se basa sobre todo en llamadas a herramientas bien formadas y en indicadores de precisión de benchmarks, según el anuncio. Un cambio de proveedor en mitad de la conversación todavía puede modificar la cuantización o el comportamiento ante rechazos, ya que la calidad varía entre proveedores y algunos sirven variantes con una cuantización más agresiva.
Romper la caché dispara la factura
Un hilo documenta contextos de unos 700.000 tokens en los que solicitudes que debían costar $0.20 con caché se facturaron cerca de $2.00 después de cambiar de proveedor: el patrón que está detrás de «pagar entre 10 y 32 veces más por una caché rota». El nuevo router mantiene una conversación en su proveedor original mientras la caché está caliente y selecciona algorítmicamente solo la primera solicitud, según el routing consciente de la caché de OpenRouter, pero esa permanencia se rompe si hay un fallback a otro proveedor. Los usuarios que resolvieron el problema fijaron un único proveedor mediante sesiones persistentes.
Creo que es un fallo bastante fundamental de OR que tengas que configurarlo manualmente de antemano.
— u/welcome_to_milliways, hilo de r/openrouter sobre la caché rota
Fallback silencioso y caro
Un informe de producción señaló que parte del tráfico pasó silenciosamente de Sonnet a Opus, con un precio anunciado aproximadamente 5 veces mayor. Aunque el tiempo de actividad seguía en verde, el gasto total por hora subió de $184/hr a $412/hr, según @CarbonOnX. El nuevo router hace explícito este intercambio: un proveedor más rápido y fiable puede superar legítimamente al más barato.
429 incluso con una cuenta de pago
Tener saldo pagado en OpenRouter no aumenta la capacidad del proveedor ascendente, como señalan los usuarios de este hilo sobre errores 429. Un 429 refleja el límite del grupo compartido de ese proveedor para el modelo en cuestión. La reconstrucción redujo los eventos 429 un 67 % en las pruebas, pero fijar o ignorar el proveedor que está limitando la tasa sigue siendo la solución en producción. Empieza por cómo solucionar los errores 429 de OpenRouter y consulta la guía de OpenRouter Auto Router para conocer el antiguo valor predeterminado basado en el precio.
Tres configuraciones de routing que sí funcionan en la práctica
La configuración adecuada depende de si priorizas velocidad sin intervención, límites estrictos de coste o un comportamiento determinista. Todas utilizan el mismo objeto provider: provider.order omite la nueva lógica y prueba los proveedores en el orden exacto indicado; provider.only y provider.ignore filtran los candidatos y después el nuevo algoritmo elige entre los restantes; y cualquier provider.sort explícito (price, throughput, latency) lo sustituye.
1. Mantener el nuevo valor predeterminado (chat interactivo y agentes)
No necesitas cambiar el código. Es una buena opción para chat orientado al usuario y agentes con varios pasos, donde cada llamada a una herramienta espera al primer token: asume un coste aproximadamente un 6 % mayor a cambio de reducir la latencia y los reintentos. Durante una semana, registra el proveedor que atiende cada solicitud (aparece en la respuesta de la API y en la página de actividad), junto con el TTFT p50 y la tasa de 429. Si la proporción de 429 se mantiene cerca de la nueva referencia de aproximadamente un 4 % y la tasa de aciertos de caché no cae, sigue así; si un proveedor concentra los fallos o los aciertos de caché se desploman, pasa a la configuración 3.
2. Fijar la ruta más barata (trabajos por lotes y tareas con límite de coste)
Hay tres formas de priorizar el routing basado en precio cuando el coste importa más que la velocidad:
{ "provider": { "sort": "price" } }También puedes añadir :floor al identificador del modelo (meta-llama/llama-4-maverick:floor) o establecer el orden predeterminado en precio desde la configuración de la cuenta, según las preguntas frecuentes del anuncio. Ten en cuenta que :floor también admite endpoints de nivel flex, mientras que sort sin más no lo hace, según la guía de routing de OpenRouter.
Añade un límite máximo:
{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }Es una configuración adecuada para prompts grandes, respuestas cortas y reintentos baratos.
3. Fijar un proveedor estable (producción con caché o llamadas a herramientas)
Fija un proveedor cuando la corrección, los aciertos de caché o el cumplimiento normativo sean más importantes que optimizar cada solicitud:
{
"provider": {
"order": ["deepinfra", "together"],
"allow_fallbacks": true,
"require_parameters": true
}
}require_parameters solo evita endpoints que no admiten los parámetros necesarios de la solicitud; no garantiza que el comportamiento de las llamadas a herramientas o de los esquemas sea idéntico entre proveedores. Reserva order con allow_fallbacks: false para casos de cumplimiento o BYOK en los que una caída sea preferible a utilizar un proveedor no aprobado. En la mayoría de las aplicaciones, permite los fallbacks, restringe los candidatos con only/ignore y envía un session_id estable para reutilizar la caché caliente (sticky routing). Si un proveedor da problemas, bloquéalo mediante las reglas de protección y compara las API del proveedor directo: varios usuarios cuentan que al conectarse directamente desaparecieron la lentitud y los problemas de caché una vez elegido el modelo (hilo de ejemplo).
| Si estás… | Usa | Por qué |
|---|---|---|
| Prototipando o manejando tráfico mixto | Nuevo valor predeterminado, sin configuración | Menos reintentos en las pruebas |
| Creando un agente orientado al usuario | Nuevo valor predeterminado + require_parameters | Mantiene las mejoras de TTFT y evita endpoints incompatibles |
| Ejecutando un batch nocturno de más de 100 millones de tokens | sort: price o :floor + max_price | Recupera la prima del 6-7 % |
| Trabajando con contexto largo y caché | order fijado + session_id | Evita que un fallo de caché cambie el precio |
El routing automático ha mejorado. Aun así, no sustituye a fijar un proveedor cuando un salto problemático cuesta más que asumir durante una semana un precio ligeramente mayor por token.
Preguntas frecuentes
¿Tengo que cambiar el código para usar el nuevo routing?
No. Las solicitudes sin un sort, order, only o ignore de proveedor explícito utilizan automáticamente el nuevo router.
¿Cómo mantengo el routing basado solo en precio?
Establece provider.sort en "price", añade :floor o configura el orden predeterminado de la cuenta en precio.
¿El nuevo routing sobrescribe mi orden de proveedores?
No. order lo omite; only/ignore filtran primero y después el nuevo algoritmo elige entre los candidatos restantes.
¿El nuevo routing costará más?
Consulta la tabla de conclusiones: un 6,0 % más por cada 1.000 solicitudes y un 7,3 % más por millón de tokens en las pruebas.
¿Cómo puedo saber qué proveedor atendió realmente mi solicitud?
Comprueba el campo provider de la respuesta de la API y la página de actividad, según la documentación de OpenRouter.
¿Por qué sigo recibiendo 429 con una cuenta de pago?
Se debe a los límites del grupo compartido del proveedor ascendente, no a tu saldo. Fija o ignora el proveedor que está limitando la tasa.