Lo que las reglas de enrutamiento realmente sacan de tu base de código
Las reglas de enrutamiento de Vercel AI Gateway hacen una cosa de manera decisiva: sacan la conmutación por error del modelo y los cambios de proveedor de decisiones en tiempo de implementación a configuración en tiempo de ejecución. Antes de que existiera esta capa, tus opciones eran cadenas de proveedores codificadas en el código de la aplicación o una bandera de característica en Postgres o LaunchDarkly. Ahora escribes una regla como YAML o JSON en la puerta de enlace, defines un proveedor principal (Anthropic) y cadenas de respaldo (OpenAI, luego Bedrock), y propaga esa decisión en segundos en lugar de un ciclo de implementación de 30-90 minutos.
Eso es real. Una interrupción de Anthropic a las 3am solía significar un PR, revisión de código, fusión, compilación, implementación, esperar a que se actualicen los cachés de borde. Ahora es un cambio de configuración y estás en Bedrock Claude en 10-15 segundos. La puerta de enlace observa modos de fallo específicos—límites de velocidad 429, errores 5xx, tiempos de espera más allá de tu SLA—y cambia proveedores automáticamente sin tocar tu código de aplicación.
Lo que permanece en el código: indicaciones, esquemas de herramientas, lógica de reintentos, claves de idempotencia y la estrategia de reintento en sí. La puerta de enlace maneja la conmutación por error a nivel de proveedor. No maneja el hecho de que Claude 3.5 Sonnet y GPT-4o tienen semánticas de llamada de herramientas completamente diferentes.
La mitad que no resuelve: desviación de comportamiento
Anthropic utiliza bloques nativos de tool_use. OpenAI utiliza llamadas de función en el flujo de mensajes. Puedes cambiar proveedores en la puerta de enlace y fallar silenciosamente durante semanas porque tus evaluaciones pasan, tus registros se ven limpios, y luego los usuarios comienzan a presentar tickets porque el agente se niega a hacer llamadas de herramientas que debería aceptar, o las llamadas de herramientas están mal formadas de formas que no has instrumentado.
Las diferencias de formato de llamada de herramientas son solo el comienzo. El modo JSON en OpenAI funciona diferente que las restricciones de salida estructurada de Anthropic. Las tasas de rechazo cambian—Claude 3.5 Sonnet rechaza ciertas clases de solicitudes más agresivamente que GPT-4o. Las expectativas de etiquetado XML difieren. La ingeniería de indicaciones que funciona en un proveedor requiere variantes para otro, pero tu regla de enrutamiento no sabe qué modelo está manejando la solicitud en tiempo de ejecución, así que no puedes ramificar la indicación.
Las regresiones silenciosas son el costo operacional real. Cambias Claude por GPT-4o en la puerta de enlace por disponibilidad, y 72 horas después tu equipo está depurando por qué la precisión de planificación de herramientas cayó de 94% a 87%. No tienes un rastro directo del incidente al cambio de enrutamiento. Por eso cualquier cambio de regla de enrutamiento necesita un arnés de evaluación que cierre la implementación y exponga deltas de comportamiento antes de que lleguen a producción. Un conjunto de pruebas que ejecuta el bucle de decisión de tu agente contra un conjunto de datos dorado de 200-500 solicitudes reales, comparando la forma de salida y la corrección de llamadas de herramientas entre proveedores.
El patrón que hemos visto funcionar: una evaluación por proveedor, no una evaluación con N backends. Mides precisión de llamada de herramientas, tasa de falsos positivos de rechazo y cumplimiento de esquema JSON por separado para cada proveedor. Cierras cualquier cambio de regla de enrutamiento—incluso un reorden de cadena de respaldo—en resultados de evaluación. Esto es costoso en el momento. Es gratis comparado con 48 horas de depuración en producción.
El enrutamiento de costo y latencia es una preocupación de aplicación, no de puerta de enlace
Las reglas de enrutamiento sobresalen en conmutación por error de disponibilidad. Fallan en optimización de costo y latencia porque la puerta de enlace no puede ver la intención semántica de la solicitud.
Un patrón real: tu agente recibe una consulta del usuario, la clasifica en 200ms en GPT-4o mini ($0.25/M tokens), luego enruta el 5% de tareas de planificación compleja a Claude 3.5 Sonnet ($15/M tokens). El modelo barato maneja el 95% del tráfico, el modelo fronterizo maneja el 5% difícil. No puedes expresar esto en la puerta de enlace. La puerta de enlace ve "la solicitud llegó" y "el modelo X disponible"—no ve "esto es una llamada de resumen" vs. "esto es planificación de múltiples pasos."
Esta lógica pertenece a tu bucle de agente, instrumentada con contabilidad de tokens por inquilino y por paso. El almacenamiento en caché semántico—verificar Redis o Upstash antes de llamar a la puerta de enlace en absoluto—maneja otro fragmento. Pero la verdadera ganancia es clasificar la solicitud en código, donde tienes contexto. Luego tu regla de enrutamiento solo necesita manejar "primario no disponible, usar respaldo," no "enrutar por costo y latencia."
El sobreaprovisionamiento de modelos fronterizos es un hábito que hemos tenido que romper. Los equipos envían GPT-4o o Claude 3.5 Sonnet para cada solicitud, luego se preguntan por qué su gasto de tokens es 10x el del competidor. El dimensionamiento correcto significa clasificar, luego enrutar. La puerta de enlace maneja la conmutación por error. El agente maneja la optimización.
Cuando las reglas de enrutamiento son infraestructura prematura
Omite las reglas de enrutamiento si estás por debajo de 1M tokens/día con un único proveedor. No tienes el cambio operacional para justificar la complejidad. Un único proveedor con un respaldo codificado—o una bandera de característica en Postgres—cubre el 80% del valor y añade cero superficie operacional.
No estás listo si aún no tienes una rotación de guardia. Las reglas de enrutamiento te compran velocidad de respuesta a incidentes. Si eres el único ingeniero y estás durmiendo, no importa que la conmutación por error sea 10 segundos en lugar de 90. Aún tienes que depurarlo a las 6am.
La trampa real es enviar enrutamiento multi-proveedor antes de tener evaluaciones, observabilidad o un conjunto de datos dorado. Hemos visto equipos desplegar reglas de enrutamiento de Vercel AI Gateway, luego pasar semanas persiguiendo regresiones de comportamiento que no instrumentaron. Una bandera de característica en LaunchDarkly con un conmutador canario—promoviendo al 10% del tráfico manualmente—resuelve esto durante meses. Cámbialo si obtienes dos incidentes de proveedor en un trimestre que afecten a los usuarios, no antes.
Cuando realmente se amortizan
Agentes multi-región, multi-inquilino empujando 100M+ tokens/día. Cargas de trabajo reguladas que necesitan proveedores fijados por región (solo UE a través de Bedrock Frankfurt). Equipos con una rotación de guardia y procedimientos de respuesta a incidentes.
Si estás aquí, necesitas reglas de enrutamiento emparejadas con:
- Rastreo distribuido (OpenTelemetry, Langfuse, Helicone) para que puedas atribuir regresiones de comportamiento a un cambio de enrutamiento específico. Un ID de rastro que viaja desde la solicitud del usuario a través de la puerta de enlace al proveedor, etiquetado con qué modelo lo manejó.
- Colas de letra muerta para llamadas de herramientas fallidas, no solo finalizaciones fallidas. Una llamada de herramienta que falla silenciosamente es peor que un tiempo de espera del modelo porque no la verás en tu observabilidad estándar.
- Canario por modelo al 5% del tráfico antes de promover una regla. Envía el nuevo proveedor o cadena de respaldo al 5% de la producción, mide latencia y tasas de error durante 4-8 horas, luego promueve o revierte.
- Un manual de reversión que esté ensayado, no teórico. Documenta exactamente qué sucede cuando deshabilitas un proveedor a las 2am, qué rastros observar y cómo validar que la reversión funcionó.
A escala de tokens, la orquestación está resuelta—el enrutamiento es el problema difícil. Pero se resuelve emparejando múltiples capas.
La pila que enviaríamos alrededor de ella
Capa 1: Clasificador en aplicación y caché semántico. Clasifica intención en un modelo barato, verifica Redis antes de golpear la puerta de enlace en absoluto. El gasto de tokens cae 40-60% y tu presupuesto de latencia es más ajustado.
Capa 2: Vercel AI Gateway para conmutación por error de proveedor y suavizado de límite de velocidad. Proveedor principal + cadena de respaldo. Tú posees la decisión de cambiar, la puerta de enlace posee la ejecución.
Capa 3: Puerta de evaluación en CI. Cada cambio de indicación, cada cambio de regla de enrutamiento, cada cambio de modelo se ejecuta a través de un conjunto de pruebas que compara corrección de llamada de herramientas y tasas de rechazo entre proveedores. No envíes si la evaluación no pasa.
Capa 4: Filtrado de seguridad por decisión. No un filtro a nivel de puerta de enlace que se aplique a todo. Las diferentes solicitudes tienen diferentes perfiles de seguridad. Enruta las pesadas a través de verificaciones adicionales.
Capa 5: Observabilidad con IDs de rastro propagados desde solicitud del usuario → puerta de enlace → proveedor. Paneles de costo por característica, no por proveedor. La atribución importa más que el gasto bruto.
Si estás mirando una configuración de regla de enrutamiento preguntándote si está resolviendo tu problema real u ocultándolo, hablemos. Hemos enviado esta capa para equipos en ambos extremos del espectro de volumen de tokens, y la diferencia entre "tenemos reglas de enrutamiento" y "tenemos reglas de enrutamiento que no rompen cosas" es generalmente tres semanas de instrumentación que no esperabas.