La lotería del ID del modelo: misma solicitud, sorteo diferente

Detrás de una puerta de enlace de múltiples proveedores, un ID de modelo no especifica qué servicio atiende tu solicitud. Nombra un conjunto de implementaciones con diferentes configuraciones de servicio, y a menos que fijes una, cada solicitud es un sorteo de ese conjunto. Lo medimos de la manera más difícil: en nuestra evaluación de moonshotai/kimi-k2.5 a través de OpenRouter (186 llamadas, iniciadas el 2026-04-22, rondas finales en los días posteriores), la misma configuración de solicitud, mismo ID de modelo, misma pista provider: { sort: "latency" }, mismo conjunto de diez prompts, produjo una mediana de tiempo hasta el primer token de 312 ms con cero caracteres de razonamiento transmitidos en una ronda, 10 de 10 llamadas, y 3,073 ms con una mediana de 2,627 caracteres de razonamiento en una ronda posterior, nuevamente 10 de 10. Un proveedor diferente atendió el mismo ID con un comportamiento materialmente distinto, sin ningún cambio en nuestro código. Los metadatos de la respuesta sí nombran al proveedor que atendió la solicitud, si piensas registrarlo; nada indica que el comportamiento cambió.

El hallazgo más contundente es que la bandera de enrutamiento que esperábamos que evitara exactamente esto no lo hizo en nuestras ejecuciones. Si tu producto depende de la profundidad del razonamiento, el ID de modelo en tu configuración no es lo que implementaste. Lo que implementaste es un boleto de lotería, y los controles de enrutamiento de la puerta de enlace son pistas para verificar, no contratos en los que confiar.

La misma solicitud, dos veces

Estábamos evaluando modelos candidatos para un asistente de cumplimiento, por lo que cada configuración ejecutó el mismo conjunto de prompts: diez prompts estándar de cumplimiento (explicar el Anexo A.5.1 de ISO 27001, el Artículo 32 del GDPR, el CC6.1 del SOC 2, etc.) y cinco prompts difíciles diseñados para la síntesis de múltiples marcos, el tipo de pregunta donde la profundidad del razonamiento realmente se hace evidente. Para cada llamada registramos el tiempo hasta el primer token, el tiempo total, los caracteres de razonamiento transmitidos, los caracteres de contenido transmitidos y el campo provider que OpenRouter devuelve en cada fragmento de transmisión.

Con sort: "latency", las primeras rondas enrutaron las diez llamadas del conjunto estándar a un proveedor anfitrión (BaseTen): mediana de 312 ms hasta el primer token, cero caracteres de razonamiento transmitidos en cada llamada. En una ronda posterior, días después, la misma configuración de solicitud enrutó las diez llamadas a un proveedor diferente (ModelRun): mediana de 3,073 ms, mediana de 2,627 caracteres de razonamiento. Una ronda aún posterior enrutó de vuelta al primer proveedor. Esto es lo que sort: "latency" hace por diseño. La documentación de enrutamiento de proveedores de OpenRouter (consultada el 2026-07-15) indica que con un sort explícito, "el equilibrio de carga se desactivará, y el enrutador intentará con los proveedores en orden", ordenados por latencia medida. La latencia medida cambia, por lo que el orden cambia, y con él, en nuestras ejecuciones, si aparece alguna salida de razonamiento.

Un cambio de latencia de 10x es molesto. Un comportamiento que se activa y desactiva bajo un ID de modelo estable es un problema de otra clase, porque nada te lo advierte. Cada respuesta fue un HTTP 200 con contenido fluido y un conteo de tokens plausible.

La bandera que esperábamos que lo detectara

No aceptamos el resultado de cero razonamiento al pie de la letra. Intentamos forzar el razonamiento en la ruta rápida con cada parámetro que ofrece la API: reasoning: { enabled: true }, reasoning: { effort: "high" }, reasoning: { max_tokens: 1024 }. Cero caracteres de razonamiento transmitidos, cada vez, siempre que la solicitud fuera atendida por ese proveedor.

Luego recurrimos al control de enrutamiento. La documentación de OpenRouter describe require_parameters de la siguiente manera: "Cuando estableces require_parameters en true, la solicitud ni siquiera se enrutará a ese proveedor", refiriéndose a proveedores que no admiten todos los parámetros en tu solicitud (documentación de enrutamiento de proveedores, consultada el 2026-07-15). Establecimos require_parameters: true junto a reasoning: { effort: "high" }. La solicitud se enrutó al mismo proveedor de todos modos, y la respuesta nuevamente no contenía texto de razonamiento.

Antes de sacar conclusiones, verificamos el formato de nuestros parámetros frente a implementaciones conocidas como buenas, porque "el modelo no razona" y "este punto final no expone razonamiento" parecen idénticos desde fuera. Fijado a DeepInfra, el mismo ID de modelo produjo 3,116 caracteres de razonamiento sin bandera y 3,807 con reasoning: { enabled: true }. Fijado a Novita: 3,460 caracteres. Estas ejecuciones resuelven la pregunta que importa: la familia de modelos razona, nuestra sintaxis de solicitud era válida, y el punto final de servicio, no el modelo, fue la variable.

Para ser precisos sobre lo que esto muestra y lo que no: require_parameters está documentado como un filtro de proveedores por soporte de parámetros, y a partir de las respuestas por sí solas no podemos saber si nuestros resultados de cero razonamiento reflejaron los metadatos de capacidad del punto final, el manejo de parámetros del lado del proveedor o una configuración de servicio que simplemente no expone texto de razonamiento. Un punto final que no expone razonamiento puede ser una elección de servicio deliberada y legítima; una mediana de 312 ms hasta el primer token es un producto real para ofrecer, y cero caracteres de razonamiento transmitidos prueba solo que no se expuso razonamiento a nosotros, no que no se realizó ningún cálculo. Lo que podemos decir es más estrecho y útil: en nuestras ejecuciones de abril de 2026, declarar el parámetro de razonamiento como requerido no nos enrutó a un punto final cuyas respuestas contenían salida de razonamiento. Cualquiera que sea el mecanismo, el contrato práctico que creíamos tener no se cumplió, y solo la medición de salida nos lo indicó.

Por qué un producto de cumplimiento lo nota, y por qué el tuyo podría no hacerlo

Aquí está la parte incómoda, expresada con claridad: en nuestros cinco prompts difíciles, la configuración de cero razonamiento aún parecía competente. Al pedirle que encontrara solapamientos de controles y un conflicto entre ISO 27001, el Artículo 32 del GDPR y el PCI DSS para una empresa SaaS de 50 personas, produjo un análisis estructurado con referencias específicas de cláusulas, como se registró en nuestras notas de ejecución: controles A.9.1 a A.9.4 del Anexo A de ISO 27001, Art. 32(1)(a) del GDPR, requisitos 3.4 y 4.1 del PCI DSS. Observa el detalle dentro de la fluidez: A.9.x es la numeración de la edición superada de ISO/IEC 27001:2013; la revisión de 2022 reorganizó el Anexo A. La respuesta se leyó como autorizada y llevó una obsolescencia a nivel de edición que nada en la respuesta indica; solo lo detectamos al verificar la numeración frente a la revisión de 2022. Esa es la forma de fallo en miniatura: fluida, estructurada, específica y silenciosamente no es el comportamiento que configuraste. Si nuestra evaluación hubiera sido "echar un vistazo a algunas respuestas por fallos obvios", la pérdida de salida de razonamiento habría pasado desapercibida. Surgió porque registramos caracteres de razonamiento por llamada como métrica de primer nivel, y la columna se fue a cero.

El resto del escaneo de la familia kimi reforzó lo diferente que es cada camino de fallo. La variante de pensamiento dedicada (moonshotai/kimi-k2-thinking) produjo salida de razonamiento en cada prompt difícil (mediana de 4,103 caracteres) pero alcanzó 178,618 ms hasta el primer token en un prompt de razonamiento profundo, tres minutos mirando un cargador. Fijar kimi-k2.5 a un proveedor capaz de razonamiento (Inceptron) produjo razonamiento real pero falló 2 de 5 prompts difíciles directamente: la respuesta consumió todo el presupuesto de 2,048 tokens en razonamiento y emitió cero contenido. Rápido sin salida de razonamiento, razonamiento sin latencia acotada, o razonamiento que agota la respuesta. Tres modos de fallo en una misma familia de modelos, y ninguno de ellos visible en los IDs. Nos alejamos de cada uno de estos caminos para producción.

Para un asistente de cumplimiento, las apuestas son específicas: la respuesta alimenta una evaluación de riesgos o una respuesta de auditoría, y una respuesta puede leerse como autorizada mientras lleva exactamente la obsolescencia que un auditor investiga. "Fluida, pero no el comportamiento que configuraste" es la peor forma de fallo en este dominio, porque nada en la respuesta la marca como un fallo. El propio blog de ingeniería de OpenRouter reconoce el lado de calidad de esta varianza: "Algunos proveedores sirven variantes de modelos más cuantizados que tienen un rendimiento inferior al mismo modelo alojado en otro lugar" (Cómo funciona el enrutamiento de modelos de OpenRouter, publicado el 2026-06-12). Nuestros datos añaden una dimensión conductual a ese panorama: no solo el mismo modelo servido peor, sino salida de razonamiento presente o ausente detrás de un ID estable.

La lotería del ID del modelo

Esa es la idea nombrada, y el modelo mental que ahora aplicamos a cada integración de puerta de enlace: cuando un ID de modelo equilibra la carga entre proveedores con diferentes configuraciones de servicio, cada solicitud es un sorteo de lotería, y el nombre impreso en el boleto es lo menos informativo sobre ello. El ID de modelo te dice la familia de pesos. No te dice la cuantización, la distribución de latencia, si aparecerá salida de razonamiento o si los parámetros que marcaste como requeridos se reflejarán en lo que recibes. Esas son propiedades de la tripleta (modelo, proveedor, día), y dos de las tres variables están fuera de tu archivo de configuración.

La lista de verificación portátil

Si enrutas tráfico de modelos de lenguaje a través de cualquier puerta de enlace de múltiples proveedores, no solo OpenRouter:

• Registra salidas conductuales como métricas de primer nivel. Caracteres o tokens de razonamiento por llamada, junto a la latencia, vinculados al proveedor de servicio que informa la respuesta. Un comportamiento que no se mide por respuesta puede desaparecer sin que nadie lo note. Activa alertas por colapso en producción, no solo en evaluaciones.
• Trata las banderas de enrutamiento y parámetros como pistas hasta que las hayas confirmado frente a la salida. Envía una solicitud que requiera una capacidad, luego verifica qué proveedor la atendió y si la capacidad realmente apareció en la respuesta.
• Antes de concluir "este modelo no puede X", fija un proveedor conocido como bueno y haz A/B con la bandera. Nuestra solicitud fue válida todo el tiempo; el punto final de servicio fue la variable. Sin la verificación fijada habríamos culpado al modelo.
• Re-muestra el enrutamiento a lo largo de horas y días, no dentro de una sola sesión. Diez de diez a un proveedor el martes es una muestra, no una propiedad. Nuestra oscilación solo apareció en rondas días después.
• Discrimina con prompts difíciles y reporta distribuciones. Nuestros diez prompts fáciles produjeron respuestas que no podíamos clasificar de manera significativa; solo los cinco prompts difíciles separaron la calidad de las respuestas entre configuraciones, y las medianas ocultaron la cola de 178 segundos. La columna de máximo es donde viven las configuraciones no enviables.
• Si el comportamiento determinista importa, fija el proveedor y re-verifica en un calendario. Fijar sacrifica la conmutación por error y, a veces, la latencia. Para un dominio regulado, suele ser el intercambio correcto.

Límites

Esta es una evaluación: 186 llamadas, 5 a 10 prompts por configuración, en nuestro conjunto de prompts de cumplimiento, iniciadas el 2026-04-22 con rondas finales en los días siguientes (registramos la fecha de evaluación, no los timestamps por ronda). Cada número aquí es nuestra propia medición en nuestras propias tareas en esa ventana, no una afirmación sobre el comportamiento, configuración o intención actual de ningún proveedor. Los identificadores de modelos son los IDs públicos de la puerta de enlace solicitados en ese momento; no registramos revisiones subyacentes de modelos de forma independiente. Las implementaciones de proveedores, la lógica de enrutamiento de OpenRouter y la documentación que citamos (consultada el 2026-07-15) pueden haber cambiado desde entonces. La observación de require_parameters es para un modelo en un par de proveedores; no lo hemos barrido en todo el catálogo. Cero caracteres de razonamiento transmitidos significa que no se expuso razonamiento en la respuesta, nada más. Y los tamaños de muestra son decisivos para nuestra decisión de implementación, orientativos para la tuya. En lo que estamos seguros es en el mecanismo: cuando el comportamiento de servicio varía por proveedor detrás de un ID estable, la única capacidad que realmente tienes es la que mides a la salida.

El ID de modelo en tu configuración es un nombre para una distribución. Mide los sorteos.