Cómo funciona el enrutamiento de prompts, y la parte que ningún gateway hace por usted

La capa base es la que la mayoría de los equipos ya usa: un solo endpoint compatible con OpenAI y una sola clave que dan acceso a cientos de modelos de distintos proveedores. Cambie el campo model y la solicitud va a otro lado: sin SDK nuevo, sin clave nueva, una sola factura. OpenRouter es el ejemplo más conocido (más de 400 modelos, más de 60 proveedores). Esto es pura comodidad: unifica el acceso, pero no toma ninguna decisión por usted. Usted sigue diciendo qué modelo.

Debajo de la API unificada, para un mismo modelo que alojan varios proveedores, el gateway reparte la carga entre ellos según precio, latencia y disponibilidad, con conmutación automática si uno se cae. Puede fijar o excluir proveedores en cada solicitud (OpenRouter expone order, only, ignore, max_price, preferred_max_latency y más). Esta es la capa detrás de las diferencias de velocidad y precio que mide un benchmark, y es ingeniería de confiabilidad realmente útil. Pero fíjese en qué optimiza: conseguir el modelo que usted ya eligió, de forma barata y confiable. Nunca cuestiona la elección en sí.

Vercel AI Gateway es la misma capa, integrada en el AI SDK, y la opción obvia si ya despliega en Vercel. Usted escribe streamText({ model: 'anthropic/claude-opus-4.7' }) y controla el transporte con providerOptions.gateway: order / only para fijar proveedores, sort: 'cost' | 'ttft' | 'tps' para ordenarlos, caching: 'auto', tiempos límite por proveedor, respaldos a nivel de modelo y BYOK (traiga su propia clave): precios de traspaso, sin margen por token. Es excelente en ese trabajo. Pero lea su sort: 'cost' con precisión: encuentra el proveedor más barato del modelo que usted nombró, no el modelo más barato que todavía responde bien. Como todo gateway, su “mejor experiencia” significa disponibilidad y latencia: no tiene ninguna medida de si el modelo es el correcto para la tarea.

El tercer sentido de enrutamiento es el que más importa y el más difícil: decidir a qué modelo debe ir un prompt. Mandar la llamada agéntica difícil al modelo fuerte y la clasificación barata al modelo barato. Bien hecho, aquí están a la vez el ahorro y la calidad. Existen dos variantes integradas, y vale la pena ser precisos con ellas:

Auto Router (openrouter/auto). Usted manda el prompt a ese ID de modelo y su clasificador elige un modelo por usted (con un control cost_quality_tradeoff de 0 a 10). Cómodo, pero es una caja negra: la lógica de selección es de ellos, heurística y no se puede someter a un benchmark. Para todo lo que quiera medir, trátelo como una línea base que hay que superar, no como el enrutador.

El arreglo models[] (respaldo). En lugar de un solo modelo, pasa una lista ordenada y el gateway los prueba en orden, pasando al siguiente ante un error, un límite de tasa o una falla por longitud de contexto. Eso le da una cadena explícita principal→retador→respaldo que define usted. Es determinista, pero enruta según el orden y la disponibilidad, no según la calidad. Si el primer modelo de su lista es la herramienta equivocada para la tarea, la solicitud va ahí de todos modos.

Este es el punto central, y la demostración de arriba está construida en torno a él. OpenRouter, y todo gateway de uso general (LiteLLM, Portkey, Cloudflare, Helicone), enruta según disponibilidad, precio, latencia y el orden que usted declara. No tiene idea de qué modelo es de verdad mejor para una tarea dada. El enrutamiento según la capacidad que todos quieren (“las llamadas agénticas difíciles al modelo fuerte, la clasificación barata al barato”) es una capa lógica que va encima y usa el gateway como base de ejecución.

Algunos productos sí enrutan según la calidad prevista (Martian, con su “model-mapping” propietario, y Not Diamond, un recomendador aprendido), y esos son la comparación real. Pero su modelo de enrutamiento es una caja negra: no puede ver por qué un prompt fue a donde fue, ni comprobar la decisión contra sus propias tareas. La diferencia que marca EyesInAI no es considerar la calidad o no: es calidad opaca frente a calidad medida e inspeccionable.

Las herramientas van desde balanceadores de carga simples y proxies de políticas que usted mismo aloja hasta un puñado de verdaderos enrutadores por capacidad. La mayoría son compatibles con OpenAI, así que proxies como LiteLLM (presupuestos, claves por cliente, enrutamiento por complejidad y semántico) o Portkey (enrutamiento condicional componible + barreras de protección) se colocan delante de OpenRouter para tener políticas más ricas que el respaldo nativo. Unos pocos, Martian y Not Diamond, sí enrutan según la calidad prevista, pero a través de un modelo propietario y opaco que no se puede inspeccionar. Lea con cuidado la columna sobre la calidad, y haga clic en cualquier fila para ver la reseña completa:

Los enrutadores mueven la solicitud; no saben qué modelo es el correcto. Esa entrada que falta (qué modelo es de verdad correcto, por tarea y a qué costo) es justo lo que mide este sitio. La tasa de aprobación por tarea, el costo por llamada, la latencia y la varianza entre ejecuciones repetidas son la señal que necesita un enrutador por capacidad para tomar una decisión defendible. El patrón es: usar el benchmark para decidir el modelo y el gateway para ejecutar la llamada.

Y esa señal que falta no es un lujo: su ausencia es el modo de falla documentado. Enrutar con la suposición de un clasificador en lugar de con calidad medida es la forma en que los equipos recortan la factura y rompen el producto sin darse cuenta: en el momento de decidir, el clasificador no distingue el centro fácil de la cola larga escondida, el modelo barato se equivoca con aparente confianza en los casos que importan, y los tableros siguen en verde mientras la pérdida de calidad (varias veces el ahorro) cae en un centro de costos que nadie está mirando. La defensa es medir por nivel y condicionar cualquier cambio a un modelo más barato a pruebas con tráfico real. Eso es justo lo que aporta la señal de calidad de abajo.

No es teoría; es el caso de estudio: hicimos el benchmark de las tareas reales del chatbot de un cliente con cinco modelos y produjimos una tabla de enrutamiento por tarea que redujo el costo de los modelos en ~32% sin perder precisión. Las recomendaciones de enrutamiento en vivo aplican la misma idea a la tabla pública de posiciones. El gateway nunca fue la parte difícil; lo difícil es saber a qué modelo apuntarlo.

Y las dos capas se combinan limpiamente. Nuestro enrutador decide qué: el modelo menos costoso que todavía aprueba la tarea, a partir de una tabla en vivo que usted puede inspeccionar. Luego le pasa ese ID de modelo a un gateway de transporte como Vercel AI Gateway, que decide cómo: el proveedor sano más barato, la conmutación por falla, la caché. En concreto, nuestro enrutador devuelve un modelo más una fallback_chain medida, y eso se traduce directamente a las opciones model + order / respaldo del gateway, así que hasta el respaldo es un modelo que salió bien en el benchmark, no una suposición. Mida para elegir el modelo; deje que el gateway ejecute la llamada. No reemplaza el enrutador de Vercel: le da la única entrada que no puede producir por sí mismo.

Un movimiento más reciente que vale la pena nombrar: la calidad en tiempo de inferencia. En junio de 2026 OpenRouter lanzó Fusion: usted manda un prompt, este se reparte en paralelo entre un panel de modelos y luego un modelo juez fusiona sus respuestas en una sola. Su propio benchmark muestra que una fusión de dos modelos supera a cada modelo individual de la prueba. Es una ganancia de calidad real, pero se compra en otra capa: gasta más cómputo por solicitud (N modelos más un juez, en cada llamada), y la síntesis del juez es una caja negra que no puede auditar en sus propias tareas. Dos herramientas hermanas, Advisor (un modelo barato hace una pausa para consultar a uno más fuerte) y Subagent (el modelo principal delega una subtarea a uno más barato), son la misma idea apuntada al costo.

Eso afina la distinción, en lugar de amenazarla. Hay dos tipos de calidad: la de tiempo de inferencia (pagar cómputo ahora para combinar modelos y juzgar) y la de tiempo de medición (hacer el benchmark primero para saber de antemano cuál es el modelo individual más barato que supera el umbral). Se combinan: medir para elegir qué modelos van en el panel y cuál debe juzgar; fusionar cuando una tarea de verdad vale el gasto extra; y, para la mayor parte del tráfico de rutina, enrutar a un solo modelo barato que según la medición va a aprobar. Fusionar cada solicitud es la opción cara por defecto; saber cuándo no hace falta es la opción medida.

Tres capas, de dificultad creciente: unificar el acceso (resuelto), elegir el proveedor confiable más barato para un modelo (resuelto) y elegir el modelo correcto para el prompt (el problema abierto). Los gateways resuelven muy bien las dos primeras y se desentienden de la tercera, porque la tercera necesita algo que no tienen: una señal medida de qué modelo es de verdad correcto. Aporte esa señal y el enrutamiento deja de ser una comodidad de caja negra para convertirse en una decisión de ingeniería que puede defender con números, que es justamente el sentido de medir modelos.