OpenRouter puede servir el mismo modelo desde distintos proveedores con comportamientos diferentes
OpenRouter puede servir el mismo modelo desde distintos proveedores con comportamientos diferentes
👁 114 lecturas
El 11 de septiembre de 2026, Mohamed Moustafa documentó una serie de problemas prácticos derivados del enrutamiento automático de OpenRouter: la plataforma puede dirigir la misma llamada de API a proveedores distintos que operan con configuraciones y software de inferencia diferentes, produciendo respuestas inconsistentes para un modelo nominalmente idéntico.
- Distintos proveedores en OpenRouter usan software de inferencia diferente, lo que produce respuestas inconsistentes para el mismo modelo
- Algunos proveedores carecen de capacidad de visión aunque el modelo la soporte, y el parámetro 'reasoning effort' se procesa de forma distinta según el proveedor
- Con la opción 'provider.only' y el método '/endpoints' es posible fijar el proveedor y evitar el enrutamiento automático
OpenRouter promociona que «maneja las conmutaciones automáticamente y elige la opción más rentable para cada solicitud», pero esa conveniencia tiene un precio. Según el análisis recogido por Simon Willison, distintos proveedores ejecutan software de servicio con optimizaciones y ajustes propios, lo que significa que el mismo endpoint puede devolver comportamientos distintos dependiendo de a qué backend se enrute la petición.
Los problemas identificados son concretos. Algunos proveedores no tienen capacidad de visión aunque el modelo en cuestión sí la soporte, de modo que una petición con imagen puede fallar silenciosamente o devolver un resultado degradado. Además, la opción de esfuerzo de razonamiento se interpreta de manera diferente según el proveedor, lo que afecta directamente a la calidad y el coste de las respuestas en modelos con cadena de pensamiento.
La solución existe dentro de la propia API. La opción provider.only permite fijar el proveedor al que se enruta cada solicitud, eliminando la variabilidad. El método /endpoints devuelve la lista de proveedores disponibles para un ID de modelo concreto, lo que facilita elegir el backend más adecuado antes de hacer llamadas en producción.
Para quien construye con estas herramientas: confiar en el enrutamiento automático de OpenRouter puede ser suficiente para prototipos, pero en producción conviene validar qué proveedor resuelve cada modelo y fijar ese proveedor con provider.only. Si la aplicación depende de visión o de razonamiento extendido, ignorar este paso puede introducir errores difíciles de reproducir y depurar.
Google · Tus fuentesBrilla más alto en tu Google - con un solo clicAñadir a fuentes preferidas →
More on this from FULGOR
noticias·Agentes de OpenAI atacaron RubyGems en mayo y la empresa no avisó al repositorio