> ## Documentation Index > Fetch the complete documentation index at: https://docs.aihubmix.com/llms.txt > Use this file to discover all available pages before exploring further. # LLM Router (enrutamiento inteligente de modelos) > LLM Router de AIHubMix: pon model en auto y la pasarela elige el mejor modelo por solicitud — coste / calidad / latencia, facturado por el modelo usado. > Un solo `model=auto` y dejas en manos de la pasarela "qué modelo elegir". El **LLM Router (enrutamiento inteligente)** elige **en tiempo real** el modelo más adecuado de entre los **cientos de modelos de la plataforma**, según el contenido de la solicitud. Solo tienes que poner `model` en `auto`: sin elegir modelo, sin comparar precios, sin seguir las iteraciones de los modelos. Se factura según el **modelo realmente usado**, sin recargos y sin cambios en el código del cliente. El modelo que se usó queda registrado en la cabecera y el cuerpo de la respuesta (consulta [Cómo confirmar el modelo realmente usado](#cómo-confirmar-el-modelo-realmente-usado)), totalmente trazable. ## Casos de uso * **Distribución automática por contexto**: asigna automáticamente el modelo más adecuado según el contexto actual del usuario — especialmente útil para agents / apps que llaman a modelos muchas veces y no pueden fijar de antemano la elección de modelo en cada paso. * **Optimización de costes**: deja que las tareas sencillas vayan automáticamente a modelos más baratos y rápidos (`auto` prioriza el coste por defecto). * **Optimización de calidad**: asegura que las solicitudes complejas se enruten a modelos más capaces (`auto:quality_first`). * **Escenarios de baja latencia**: bucles de agent multironda, chat interactivo en tiempo real y otros escenarios sensibles a la latencia prefieren el modelo de respuesta más rápida (`auto:latency_critical`). * **Entrada única, sin selección de modelo**: distintos tipos de solicitudes se distribuyen automáticamente a su modelo óptimo, sin tener que mantener una tabla "tarea → modelo" ni seguir continuamente las iteraciones de los modelos, comparar precios y cambiar nombres a mano. *** ## Inicio rápido Pon `model` en `auto`; el resto del cuerpo de la solicitud es idéntico a una llamada normal. La base\_url es `https://aihubmix.com/v1`. ```bash curl theme={null} curl https://aihubmix.com/v1/chat/completions \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "model": "auto", "messages": [ { "role": "user", "content": "What is the meaning of life?" } ] }' ``` ```python Python (openai SDK) theme={null} from openai import OpenAI client = OpenAI( api_key="", base_url="https://aihubmix.com/v1", ) resp = client.chat.completions.create( model="auto", # deja que la pasarela elija el modelo automáticamente messages=[ {"role": "user", "content": "What is the meaning of life?"}, ], ) print(resp.choices[0].message.content) print("Modelo realmente usado:", resp.model) # no es "auto", sino el nombre real del modelo ``` ```javascript Node.js (openai SDK) theme={null} import OpenAI from "openai"; const client = new OpenAI({ apiKey: "", baseURL: "https://aihubmix.com/v1", }); const resp = await client.chat.completions.create({ model: "auto", // deja que la pasarela elija el modelo automáticamente messages: [ { role: "user", content: "What is the meaning of life?" }, ], }); console.log(resp.choices[0].message.content); console.log("Modelo realmente usado:", resp.model); // nombre real del modelo ``` El enrutamiento inteligente resuelve el análisis **antes** de que la solicitud llegue al upstream, tratando por igual las solicitudes en streaming (`stream: true`) y no streaming, sin parámetros adicionales; toda la decisión **añade solo alrededor de 1 ms de sobrecarga**, prácticamente imperceptible en la latencia de extremo a extremo. *** ## Cómo confirmar el modelo realmente usado Este es el ancla de confianza del enrutamiento inteligente: **siempre sabes qué modelo se usó finalmente en esta solicitud.** **Método 1 · Consola de AIHubMix "Registros"**: en [console.aihubmix.com/logs](https://console.aihubmix.com/logs), cada solicitud muestra directamente el nombre real del modelo realmente acertado y facturado — sin código, verificable a simple vista. **Método 2 · Campos de la respuesta** (práctico para lectura programática): * **El campo `model` del cuerpo de la respuesta** se rellena con el modelo realmente usado (p. ej. `mimo-v2.5-pro`), no con `auto`. * **Las cabeceras de respuesta** ofrecen la información completa de la decisión: | Cabecera de respuesta | Significado | Valor de ejemplo | | ---------------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------ | | `X-Aihubmix-Router-Resolved-Model` | Modelo realmente usado y según el cual se factura | `xiaomi-mimo-v2.5-pro` | | `X-Aihubmix-Router-Policy` | Política usada en esta solicitud | `cost_optimized` | | `X-Aihubmix-Router-Dimension` | Dimensión de tarea identificada | `text.overall` | | `X-Aihubmix-Router-Decision-Id` | ID único de esta decisión, útil para diagnóstico | `05dbad09-33c5-42de-…` | | `X-Aihubmix-Router-Reason` | Resumen de la decisión (política / dimensión / puntuación máxima / nº de candidatos) | `policy=cost_optimized dim=text.overall top=0.182 survivors=20/33` | | `X-Aihubmix-Router-Fallback` | Aparece **solo** cuando se activa el respaldo por falta de candidatos | `true` | > Las cabeceras HTTP no distinguen mayúsculas y minúsculas: la tabla anterior usa mayúscula inicial por convención, pero en HTTP/2 se devuelven en minúsculas `x-aihubmix-router-*`; ambas formas son equivalentes. Leer la decisión de enrutamiento (con curl, mira las cabeceras de respuesta; con el SDK, usa el objeto de respuesta sin procesar para obtener la cabecera): ```bash curl theme={null} curl -i https://aihubmix.com/v1/chat/completions \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "model": "auto", "messages": [ { "role": "user", "content": "What is the meaning of life?" } ] }' | grep -i "^x-aihubmix-router" ``` ```python Python (openai SDK) theme={null} # Reutiliza el client creado arriba; with_raw_response permite obtener las cabeceras raw = client.chat.completions.with_raw_response.create( model="auto", messages=[ {"role": "user", "content": "What is the meaning of life?"}, ], ) print("Modelo usado:", raw.headers.get("x-aihubmix-router-resolved-model")) print("Política:", raw.headers.get("x-aihubmix-router-policy")) print("Dimensión:", raw.headers.get("x-aihubmix-router-dimension")) completion = raw.parse() # parsea al objeto completion normal print("body.model:", completion.model) ``` ```javascript Node.js (openai SDK) theme={null} // Reutiliza el client creado arriba; .withResponse() permite obtener las cabeceras de respuesta sin procesar const { data: completion, response } = await client.chat.completions .create({ model: "auto", messages: [ { role: "user", content: "What is the meaning of life?" }, ], }) .withResponse(); console.log("Modelo usado:", response.headers.get("x-aihubmix-router-resolved-model")); console.log("Política:", response.headers.get("x-aihubmix-router-policy")); console.log("Dimensión:", response.headers.get("x-aihubmix-router-dimension")); console.log("body.model:", completion.model); ``` Salida real de curl (entorno de producción; el modelo usado varía según el catálogo en vivo): ```text theme={null} x-aihubmix-router-decision-id: 05dbad09-33c5-42de-85b5-559fdb73eb4c x-aihubmix-router-dimension: text.overall x-aihubmix-router-policy: cost_optimized x-aihubmix-router-reason: policy=cost_optimized dim=text.overall top=0.182 survivors=20/33 x-aihubmix-router-resolved-model: xiaomi-mimo-v2.5-pro ``` Cómo leer `reason`: `survivors=20/33` indica que de 33 candidatos, 20 superaron el filtro estricto y pasaron a la puntuación; `top=0.182` es la puntuación global normalizada del modelo ganador dentro del grupo de candidatos (capacidad / coste / latencia ponderados según la política). El `Resolved-Model` del ejemplo depende de los candidatos y precios actuales del catálogo en vivo, y cambiará a medida que se incorporen o retiren modelos de la plataforma; esto es precisamente el valor del enrutamiento inteligente: no tienes que seguir esos cambios. Para que la decisión sea reproducible, guíate por el nombre real del modelo en la cabecera / cuerpo de la respuesta, en lugar de suponer que es fijo. *** ## Políticas de enrutamiento El `auto` sin sufijo usa la política por defecto `cost_optimized`. Puedes usar `auto:` para especificar explícitamente el énfasis: | Sintaxis de política | Énfasis | Casos de uso | | -------------------------------- | -------------------------------------------------------------- | ------------------------------------------------ | | `auto` (= `auto:cost_optimized`) | **Coste primero**: si cumple la capacidad, elige el más barato | Tareas masivas, sensibles al coste | | `auto:balanced` | **Equilibrado**: tiene en cuenta capacidad / coste / latencia | Genérico, opción segura cuando no estás seguro | | `auto:quality_first` | **Calidad primero**: prioriza el modelo más capaz | Razonamiento complejo, salidas críticas | | `auto:latency_critical` | **Baja latencia primero**: prioriza la respuesta más rápida | Bucles de agent, chat interactivo en tiempo real | Una política no es una "lista fija de modelos", sino una ponderación distinta de **capacidad / coste / latencia**. `auto` primero acota la dimensión de la tarea según el contenido de tu solicitud y luego elige en tiempo real el mejor modelo del grupo de candidatos de **cientos de modelos en la plataforma** según la política elegida — así que una misma política acierta modelos distintos según el contenido. Los modelos actualmente en el pool y las puntuaciones por dimensión pueden consultarse mediante el endpoint [Alcance de modelos de la estrategia de LLM Router](/es/api/RouterEndpoints/leaderboard). La tabla "misma solicitud, distintas políticas → distintos resultados" de abajo ilustra justo esto; qué modelo gana cada vez se determina por el nombre real del modelo en las cabeceras de respuesta / los registros de consola. Para especificar una política, basta con añadir el sufijo a `model`: ```bash curl theme={null} # calidad primero + tarea de código curl -i https://aihubmix.com/v1/chat/completions \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{ "model": "auto:quality_first", "messages": [ { "role": "user", "content": "Write a Python function to reverse a linked list." } ] }' | grep -i "^x-aihubmix-router" ``` ```python Python (openai SDK) theme={null} raw = client.chat.completions.with_raw_response.create( model="auto:quality_first", # calidad primero messages=[ {"role": "user", "content": "Write a Python function to reverse a linked list."}, ], ) print(raw.headers.get("x-aihubmix-router-resolved-model")) print(raw.headers.get("x-aihubmix-router-dimension")) ``` ```javascript Node.js (openai SDK) theme={null} const { response } = await client.chat.completions .create({ model: "auto:quality_first", // calidad primero messages: [ { role: "user", content: "Write a Python function to reverse a linked list." }, ], }) .withResponse(); console.log(response.headers.get("x-aihubmix-router-resolved-model")); console.log(response.headers.get("x-aihubmix-router-dimension")); ``` **Misma solicitud, distinta política → distinto modelo** (medido en producción, con la misma frase `What is the meaning of life?`, todas en la dimensión `text.overall`): | Política | Modelo usado | Puntuación top | | --------------------------- | ----------------------- | :------------: | | `auto` (= `cost_optimized`) | `xiaomi-mimo-v2.5-pro` | 0.182 | | `auto:balanced` | `claude-opus-4-6-think` | 0.488 | | `auto:latency_critical` | `claude-opus-4-6` | 0.646 | | `auto:quality_first` | `claude-opus-4-6-think` | 0.758 | > `latency_critical` eligió la **versión sin `-think`**: las variantes thinking tienen mayor latencia de razonamiento, y la política de baja latencia las evita activamente. Se ve que los pesos de la política actúan de verdad sobre el equilibrio "capacidad / coste / latencia", y no solo sobre la capacidad. > **El contenido también cambia el resultado**: aplicando la misma `auto:quality_first` a una **tarea de código** (la solicitud del ejemplo anterior), la dimensión pasa de `text.overall` a `text.coding` y, en pruebas reales, se usa `claude-opus-4-6-think`; la política y el contenido de la solicitud determinan juntos el modelo final. Un sufijo de política desconocido (como `auto:fast`) **recae en la política por defecto `cost_optimized`**, sin error. *** ## Cómo funciona Tras recibir `model=auto`, la pasarela convierte la "intención" en un "modelo concreto" en tres pasos: Analiza las modalidades de entrada / salida de esta solicitud (texto, imagen, archivo), la intención del contenido (código, matemáticas, OCR, gráficos, idioma, si hay búsqueda en línea, etc.) y el tamaño de la solicitud (estimación de tokens de entrada / salida), normalizándolo a una **dimensión de tarea**. Por ejemplo: una pregunta con código → `text.coding`; con imagen y petición de OCR → `vision.ocr`; texto normal → `text.overall`. Excluye directamente los modelos que no cumplen las **restricciones estrictas**: que no admitan las modalidades de entrada / salida requeridas, cuya ventana de contexto no dé abasto, que estén apartados por el cortacircuitos (consulta [Fiabilidad y tolerancia a fallos](#fiabilidad-y-tolerancia-a-fallos)) o que no estén dentro del rango de modelos disponibles para tu Key. Sobre los candidatos que superan el filtro, basándose en las puntuaciones de capacidad de los modelos según **benchmarks de referencia del sector**, sumando datos de precio y rendimiento en tiempo real, realiza una puntuación ponderada en tres dimensiones "capacidad / coste / latencia" según la política elegida, y toma el de mayor puntuación. El nombre del modelo final se escribe de vuelta en la solicitud y en las cabeceras de respuesta. Ejemplo real de puntuación (con la política `quality_first`, top 3 del mismo grupo de candidatos; datos de ejemplo basados en registros históricos de decisión de producción): | Modelo candidato | Puntuación de capacidad | Coste relativo | Latencia | Puntuación global | | ----------------------- | :---------------------: | :------------: | :------: | :---------------: | | `claude-opus-4-6-think` | 1504 | 220 | 1963ms | **0.758** | | `claude-opus-4-6` | 1498 | 220 | 822ms | 0.721 | | `claude-fable-5` | 1510 | 484 | 11130ms | 0.600 | > Fíjate en que `claude-fable-5` tiene la **puntuación de capacidad más alta** (1510), pero por su mayor coste y latencia queda relegado al tercer puesto en la puntuación global. Ese es justo el sentido de la puntuación ponderada: no es "solo capacidad", sino un equilibrio entre capacidad / coste / latencia según la política. `claude-fable-5` fue un modelo base de vista previa por fases (staged preview baseline) y ahora está **descontinuado (deprecated)** y ya no se ofrece; su puntuación histórica se conserva aquí solo para ilustrar el mecanismo de puntuación ponderada — las solicitudes reales ya no lo acertarán. La identificación de la dimensión es automática: el enrutamiento inteligente incorpora **más de 30 dimensiones de tarea detalladas** (código / matemáticas / OCR / gráficos / texto largo / chino / búsqueda en línea…), mucho más fino que un "reparto grueso por familia de modelos". Con el mismo `auto`, distintos contenidos se enrutan a distintas dimensiones: | Tu solicitud | Dimensión identificada | | ------------------------------------------------------------------------------ | ------------------------- | | Pregunta de texto normal | `text.overall` | | Con código, pide escribir / depurar un programa | `text.coding` | | Demostración / resolución matemática | `text.math` | | Pregunta muy larga (unos 500+ tokens) | `text.longer_query` | | Pregunta en chino | `text.language.chinese` | | Entrada de imagen + "What is in this image?" | `vision.overall` | | Entrada de imagen + "OCR…" / "reconocer texto" | `vision.ocr` | | Entrada de imagen + gráfico / diagrama de flujo | `vision.diagram` | | Búsqueda en línea activada | `search.overall` | | Generación de imágenes (`/v1/images/generations`) | `text_to_image.overall` | | Edición de imágenes (`/v1/images/edits`, imagen de entrada → imagen de salida) | `image_edit.single_image` | Estos nombres de dimensión provienen de leaderboards autorizados del sector que desglosan las **capacidades específicas** de los modelos; `auto` envía cada tipo de solicitud al modelo más fuerte en esa capacidad. Dominios comunes, por ejemplo: * **Texto**: `text.coding` = escribir / depurar código, `text.math` = resolución matemática, `text.longer_query` = texto largo, `text.language.chinese` = chino, `text.occupational.legal` / `text.occupational.medicine` = escenarios profesionales legales / médicos. * **Visión**: `vision.ocr` = reconocer texto en imágenes, `vision.diagram` = entender gráficos / diagramas de flujo, `vision.overall` = comprensión general de imágenes. La identificación de la dimensión usa una coincidencia conservadora (alta precisión, bajo error): las solicitudes de cola larga o ambiguas recaen en dimensiones más generales (como `text.overall` / `vision.overall`) en lugar de forzarse en una categoría, evitando así un enrutamiento erróneo. **La entrada de imagen también pasa por el enrutamiento inteligente**: al incluir imágenes en `/v1/chat/completions`, se enruta según la tarea de imagen a modelos con fuerte capacidad visual. Medido en producción: «OCR this image» → `vision.ocr`, usa `qwen3.5-397b-a17b`; visión general «What is in this image?» → `vision.overall`, usa `gpt-5.4-mini`. (Aquí se refiere a la **comprensión** de imágenes; la **generación** de imágenes `/v1/images/*` también admite `auto`, consulta las [Preguntas frecuentes (FAQ)](#preguntas-frecuentes-faq).) *** ## Clasificación de puntuaciones y pool de modelos La clasificación de puntuaciones de modelos por dimensión y el pool de modelos actual pueden consultarse de forma interactiva en la [página del LLM Router](https://aihubmix.com/llm-router/auto?lang=en), u obtenerse directamente mediante los endpoints abiertos sin inicio de sesión: [Alcance de modelos de la estrategia de LLM Router](/es/api/RouterEndpoints/leaderboard) y [Iconos de proveedores de modelos](/es/api/RouterEndpoints/vendors). La clasificación muestra el mismo conjunto que los candidatos de enrutamiento: solo aparecen los modelos actualmente enrutables, las puntuaciones se normalizan de 0 a 100 dentro de cada dimensión y la clasificación se actualiza continuamente con el pool de modelos. *** ## Fiabilidad y tolerancia a fallos El enrutamiento inteligente incorpora **múltiples mecanismos de tolerancia a fallos** para garantizar que la ruta `auto` **nunca falle sin motivo**: La pasarela mantiene para cada modelo una estadística de tasa de fallos con ventana deslizante. Cuando un modelo acumula suficientes fallos dentro de la ventana y su tasa de fallos supera el umbral, se aparta temporalmente del grupo de candidatos y se recupera automáticamente tras un periodo de enfriamiento, evitando seguir enviando solicitudes a un modelo que está fallando. La señal de fallo proviene de **los errores que el upstream devuelve para esa solicitud**; el "sin canal disponible" de la propia pasarela no cuenta (eso no es problema del modelo en sí). Si el filtro estricto excluyera todos los candidatos (por ejemplo, cierta combinación de modalidades sin modelo disponible por ahora), la pasarela no devuelve un error directamente, sino que asigna un modelo de respaldo según el tipo de salida para garantizar una respuesta, y añade `X-Aihubmix-Router-Fallback: true` a las cabeceras para avisarte. Si tu Key limita el rango de modelos disponibles, el modelo que elige el enrutamiento inteligente (incluido el respaldo) está **siempre** dentro de ese rango. Si dentro del rango realmente no hay ningún modelo capaz de atender esta solicitud, devuelve un 403 explícito, en lugar de usar silenciosamente un modelo fuera del rango (posiblemente más caro). *** ## Facturación **Se factura al precio original del modelo realmente usado; el enrutamiento inteligente en sí no cobra ningún recargo.** Sea cual sea el modelo que finalmente responde, se calcula según el precio, la capacidad y los límites de contexto de ese modelo, que es el valor del campo `model` del cuerpo de la respuesta y de la cabecera `X-Aihubmix-Router-Resolved-Model`. Dicho de otro modo, el enrutamiento inteligente no "usa modelos caros a escondidas": cada modelo usado queda registrado en la respuesta y se puede conciliar entrada por entrada. *** ## Limitaciones * El enrutamiento inteligente está orientado actualmente al endpoint de **chat completions** `/v1/chat/completions` y a los endpoints de **generación / edición de imágenes** `/v1/images/*` (consulta [FAQ: qué endpoints admite](#preguntas-frecuentes-faq)). * `?router=off` o la cabecera `X-Router-Off` hacen que `model=auto` devuelva directamente un **400**: es un rechazo explícito del uso ambiguo de "querer auto pero a la vez desactivar el enrutamiento", en lugar de ignorarlo silenciosamente: ```bash theme={null} curl -i "https://aihubmix.com/v1/chat/completions?router=off" \ -H "Authorization: Bearer " \ -H "Content-Type: application/json" \ -d '{"model":"auto","messages":[{"role":"user","content":"hi"}]}' # → HTTP/1.1 400 Bad Request # {"error":{"message":"auto requires router enabled; remove ?router=off / X-Router-Off", ...}} ``` * El conjunto de candidatos cambia dinámicamente con el catálogo de la plataforma: el mismo `auto` puede usar distintos modelos en momentos distintos (es por diseño y se puede reconstruir mediante las cabeceras de respuesta). El rango actual de candidatos puede consultarse mediante el endpoint [Alcance de modelos de la estrategia de LLM Router](/es/api/RouterEndpoints/leaderboard). *** ## Diferencias con OpenRouter / LiteLLM "Elegir el modelo automáticamente" no es exclusivo de AIHubMix; OpenRouter y LiteLLM ofrecen capacidades similares. Las diferencias están sobre todo en el **coste de integración** y la **forma de alojamiento**: | Punto de diferencia | OpenRouter | LiteLLM | AIHubMix | | -------------------------------------------------------------------------------------- | :--------: | :-----: | :------: | | Selección automática de modelo según el contenido de la solicitud | ✅ | ✅ | ✅ | | Cero configuración, listo para usar (sin escribir reglas de enrutamiento / utterances) | ✅ | ❌ | ✅ | | Alojado en la plataforma, sin necesidad de montar / desplegar tu propio proxy | ✅ | ❌ | ✅ | | Múltiples políticas de coste / calidad / latencia, conmutables con un solo parámetro | ❌ | ❌ | ✅ | | Decisión de selección trazable (la cabecera incluye dimension / policy / reason) | ❌ | ❌ | ✅ | | Facturación según el modelo finalmente usado | ✅ | ❌ | ✅ | *** ## Preguntas frecuentes (FAQ) **P: ¿Qué endpoints admite el enrutamiento inteligente?** R: Actualmente `model=auto` admite el **endpoint de chat completions compatible con OpenAI** `/v1/chat/completions`, así como los **endpoints de generación / edición de imágenes** (`/v1/images/generations`, `/v1/images/edits`). El audio, `/v1/embeddings`, `/v1/rerank` y otros endpoints no admiten `auto` por ahora; especifica directamente un modelo concreto. **P: ¿El enrutamiento inteligente admite entrada de imagen?** R: Sí. Hacer una pregunta con imágenes (`image_url`) en `/v1/chat/completions` es **comprensión** de imágenes, y se enruta según la tarea de imagen a modelos con fuerte capacidad visual (`vision.ocr` = reconocer texto en imágenes, `vision.diagram` = entender gráficos / diagramas de flujo, `vision.overall` = comprensión general de imágenes, etc.). La **generación** de imágenes también admite `auto`: establece `model` en `auto` en los endpoints `/v1/images/*` y la solicitud se enruta según las dimensiones de generación de imágenes (por ejemplo, `text_to_image.overall`). **P: ¿Cómo sé qué modelo se usó realmente en esta solicitud?** R: Mira la cabecera `X-Aihubmix-Router-Resolved-Model` o el campo `model` del cuerpo de la respuesta: ambos se rellenan con el nombre real del modelo. Consulta [Cómo confirmar el modelo realmente usado](#cómo-confirmar-el-modelo-realmente-usado). **P: ¿El enrutamiento inteligente usa modelos caros a escondidas?** R: No. La política por defecto `cost_optimized` prioriza el coste; además, cada modelo usado queda registrado en la respuesta y se factura a su precio original, conciliable entrada por entrada. Consulta [Facturación](#facturación). **P: ¿Cómo controlar / estimar el coste?** R: Tres medidas combinadas: ① el `auto` por defecto (`cost_optimized`) ya prioriza el coste; ② usa el **rango de modelos disponibles de la Key** para acotar los candidatos al rango de precios que aceptes, equivalente a poner un tope al coste; ③ cada modelo usado se factura al precio original del modelo de la cabecera `Resolved-Model`, conciliable entrada por entrada. Cuando necesites más capacidad, usa explícitamente `auto:quality_first`. **P: ¿Qué diferencia hay entre `auto` y el "mapeo de modelos / fallback"?** R: El [mapeo de modelos / fallback](https://docs.aihubmix.com/es/api/Model-Mapping-Fallback) es un **alias fijo a nivel de Key + respaldo ordenado ante fallos** (siempre el mismo destino); el enrutamiento inteligente selecciona el modelo **dinámicamente según el contenido de cada solicitud**. El primero resuelve "el cliente solo reconoce cierto nombre / el modelo principal cayó y se cambia al de respaldo"; el segundo resuelve "no me importa cuál sea, dame el más adecuado". **P: ¿Se puede limitar el enrutamiento inteligente a elegir solo entre unos pocos modelos?** R: Sí, mediante el **rango de modelos disponibles de la Key**: el enrutamiento inteligente solo elegirá entre los modelos permitidos por esa Key, y no usará modelos fuera del rango. **P: ¿Se admiten solicitudes en streaming?** R: Sí. El enrutamiento se resuelve antes de que la solicitud llegue al upstream, tratando por igual el streaming y el no streaming. **P: ¿Por qué dos llamadas con la misma frase usaron modelos distintos?** R: El conjunto de candidatos y los precios cambian dinámicamente con el catálogo de la plataforma; es por diseño. Usa el `Decision-Id` y el `Resolved-Model` de las cabeceras de respuesta para reconstruir cada decisión; el rango actual de candidatos puede consultarse mediante el endpoint [Alcance de modelos de la estrategia de LLM Router](/es/api/RouterEndpoints/leaderboard). **P: ¿Cómo hago que las solicitudes usen de forma estable el mismo modelo (por ejemplo, para reutilizar la caché de prompts)?** R: `auto` elige el modelo dinámicamente según el catálogo actual y no garantiza determinismo. Si necesitas usar de forma estable el mismo modelo (por ejemplo, porque dependes de la caché de prompts del upstream o necesitas reproducibilidad estricta), **especifica directamente un nombre de modelo concreto** o **acota el rango disponible de la Key a un único modelo**: en ambos casos el modelo usado es determinista. *** ## Recursos relacionados * [Mapeo de modelos y fallback](https://docs.aihubmix.com/es/api/Model-Mapping-Fallback): alias fijo a nivel de Key + respaldo ante fallos, complementario al enrutamiento inteligente. * [Parámetros de inferencia unificados](https://docs.aihubmix.com/es/api/unified-inference): parámetros de solicitud coherentes entre modelos. * [Página de modelos de AIHubMix](https://aihubmix.com/models): consulta nombres de modelo, precios e `Input Modalities`. * [Alcance de modelos de la estrategia de LLM Router](https://docs.aihubmix.com/es/api/RouterEndpoints/leaderboard): acceso sin inicio de sesión al subconjunto público de 23 subdimensiones (de las 30+ dimensiones de enrutamiento) y al pool de modelos enrutables.