Routers de LLM y fallback: continuidad operacional sin regalar tus credenciales

La respuesta obvia circula hace meses en foros y videos: poner un router de modelos en el medio. Un proxy local que recibe las peticiones de tu editor y las reparte entre varios proveedores, con una cadena de respaldo. Si el principal falla, se cae a la siguiente opción. Continuidad operacional aplicada a los LLM, que es literalmente el problema que llevamos años resolviendo con enlaces redundantes y réplicas de base de datos.

La idea es buena. La implementación popular tiene tres trampas que casi nadie menciona, y una de ellas te puede costar la cuenta que estás intentando proteger.

Este artículo es sobre cómo separar la parte que sirve de la parte que no.

El problema real: no es el modelo, es la interrupción

Conviene ser honestos con el diagnóstico antes de comprar la solución.

Cuando un equipo dice “necesito otro modelo”, casi nunca quiere decir que el modelo sea malo —ya revisamos en qué tareas ayudan de verdad y en cuáles son un riesgo—. Quiere decir alguna de estas tres cosas:

• Se agotó la cuota a mitad de una tarea con contexto caro de reconstruir.
• El proveedor devolvió un error —rate limit, 529, timeout— y no hay plan B.
• El costo se disparó porque se está usando el modelo más caro para tareas que no lo necesitan.

Son tres problemas distintos y solo el segundo se resuelve bien con fallback automático. El primero se resuelve con política de uso y, si de verdad se necesita volumen, con facturación por uso. El tercero se resuelve eligiendo mejor el modelo, no agregando capas.

Es la misma conversación de siempre: antes de meter un componente nuevo en la arquitectura, hay que saber qué falla se está mitigando. Un router que existe “por si acaso” es infraestructura que mantienes sin razón.

Qué hace un router de LLM con fallback

El patrón es sencillo y viejo: un proxy compatible con las APIs de los proveedores, escuchando en localhost.

Editor / CLI  ->  router local  ->  proveedor A (principal)
                                ->  proveedor B (respaldo)
                                ->  proveedor C (respaldo)

En vez de configurar cada herramienta contra un proveedor específico, todas apuntan al router, y el router decide. La herramienta más comentada del rubro, 9Router, escucha por defecto en http://localhost:20128/v1 y expone un dashboard para armar lo que llama combos: listas ordenadas de modelos que se intentan en secuencia.

Combo: coding-stack
1. modelo principal   (el bueno)
2. modelo intermedio  (barato)
3. modelo de respaldo (gratuito)

Traducido a lenguaje de infraestructura: es un balanceador con health-check pobre. Y esa pobreza importa, porque el fallback solo se dispara si el proveedor reporta el error de una forma que el router entienda. Una respuesta degradada, un truncamiento silencioso o un timeout largo no siempre gatillan el salto. No es alta disponibilidad; es un reintento con otro backend.

Trampa 1: el OAuth de tu suscripción no es tuyo para prestarlo

Acá está el punto que hace que la mayoría de los tutoriales de este tema sean un mal consejo.

Estas herramientas ofrecen conectar tu suscripción —Claude, y equivalentes— vía OAuth desde el dashboard. Es tentador: ya pagas un plan mensual, ¿por qué usar además una API de pago por uso?

Porque no está permitido. En febrero de 2026 Anthropic explicitó en su documentación legal y de cumplimiento que usar tokens OAuth obtenidos de cuentas Free, Pro o Max en cualquier otro producto, herramienta o servicio —incluido el propio Agent SDK— no está autorizado. No es una zona gris que alguien esté interpretando de más: hubo cuentas suspendidas, y el proyecto OpenCode retiró el soporte de Claude en febrero de 2026 citando requerimientos legales de Anthropic.

Los términos de consumo son igual de directos en la parte que lo sustenta: no puedes compartir tus credenciales de cuenta con nadie más, y el acceso por medios automatizados solo está permitido a través de una API key.

El resultado es de un absurdo perfecto: montas una capa de continuidad para no quedarte sin herramienta, y el mecanismo que elegiste es justamente el que puede dejarte sin cuenta. Es el equivalente a configurar un cluster de alta disponibilidad usando la misma fuente de poder para los dos nodos.

La versión compliant existe y es aburrida: API keys propias de cada proveedor, contratadas a tu nombre, facturadas por uso. Cuesta más por token que una suscripción plana, pero es la única forma de rutear tráfico por infraestructura de terceros sin apostar la cuenta.

Trampa 2: le estás entregando todas tus llaves a un proceso local

La segunda trampa es de superficie de riesgo, y es la que a nosotros nos importa profesionalmente.

Un router de modelos es, por definición, el punto donde conviven todas tus credenciales de IA. Es un llavero de credenciales. Y como cualquier llavero, hay que preguntarse cómo guarda las llaves antes de meterlas.

Una auditoría de seguridad pública de 9Router, publicada por StationX en julio de 2026, encontró un conjunto de hallazgos que ningún equipo debería ignorar:

• Verificación TLS deshabilitada (rejectUnauthorized: false) al reenviar peticiones hacia los proveedores. Es decir: la conexión que transporta tus claves no valida el certificado del otro extremo.
• Tokens y API keys almacenados en texto plano en su base de datos local. Cualquier lectura del archivo entrega todo.
• Contraseña por defecto 123456 en el dashboard, que emite sesiones válidas por 24 horas. Grave si además se expone por túnel.
• Clave privada de la CA legible por cualquier usuario del sistema, lo que habilita forjar certificados.
• Auto-actualizaciones sin firma, que es ejecución remota de código con pasos extra.

El veredicto del auditor fue explícito: no rutearía credenciales reales a través de esa herramienta.

Esto no significa que la categoría “router de LLM” sea mala. Significa que esta implementación específica, en esta versión, no está lista para sostener credenciales de producción, y que la decisión correcta depende de qué claves estás dispuesto a perder.

El criterio práctico: si un proceso concentra todas tus credenciales, su postura de seguridad tiene que ser al menos tan buena como la del secreto más valioso que guarda. Un llavero con la puerta abierta es peor que no tener llavero.

Trampa 3: la integración que pide MITM

Hay una tercera trampa que aparece en estas guías y que merece una advertencia aparte.

Para integrar clientes que no permiten cambiar el endpoint, algunas soluciones proponen interceptar el tráfico con DNS local, un proxy MITM y un certificado raíz instalado en el sistema.

Cliente  ->  DNS local / MITM  ->  router  ->  proveedor

Leamos eso con calma. Instalar una CA propia en el almacén de confianza del sistema significa que cualquiera que controle esa clave privada puede firmar certificados que tu equipo va a creer. Combínalo con el hallazgo anterior —clave privada de la CA legible por otros usuarios— y ya no estamos hablando de una molestia de configuración, sino de un vector de intercepción de todo el tráfico HTTPS de esa máquina.

En un equipo personal de laboratorio, es tu decisión. En un notebook corporativo con acceso a producción, es un cambio que ningún responsable de seguridad debería aprobar sin un análisis formal. Y desde luego no es el primer paso de una implementación: es el último, si acaso.

La configuración que sí es defendible

Después de todo lo anterior, ¿hay una forma razonable de tener fallback? Sí, y se parece bastante a cómo montamos cualquier otra redundancia.

1. Decide qué falla estás cubriendo. Si es continuidad ante caída del proveedor, sirve. Si es “quiero pagar menos”, esto no es la solución.
2. Usa API keys propias, nunca OAuth de suscripción. Una key por proveedor, a tu nombre, con límite de gasto configurado en el panel del proveedor. Esto solo ya elimina el riesgo de suspensión.
3. Aísla el router. Escuchando en 127.0.0.1, sin exponerlo por túnel, sin la función de compartir remoto, con la contraseña por defecto cambiada antes del primer uso. Si necesitas alcanzarlo desde otra máquina, va detrás de autenticación real, no del dashboard.
4. Rota y limita las claves. Asume que el almacenamiento es texto plano y trabaja con esa premisa: claves con permisos mínimos, presupuesto acotado, rotación periódica y revocación inmediata ante cualquier duda.
5. Elige respaldos que hagan el trabajo. Un modelo de fallback —de un tercero o uno alojado internamente— sirve si soporta el tipo de petición que envías —tool calling, contexto largo, streaming—. Como ejemplo concreto, nvidia/nemotron-3-ultra-550b-a55b es un MoE híbrido Transformer-Mamba de 550B totales con 55B activos y ventana de 1M tokens, orientado a flujos agénticos; es un respaldo plausible para tareas de código —distinto es el caso de tareas de triaje de logs, donde un modelo más liviano suele bastar—. Otros modelos ligeros van a fallar justo en la petición compleja que gatilló el fallback, que es el peor momento para descubrirlo.
6. Prueba el fallback a propósito. Corta la red del proveedor principal, o invalida su key a mano, y ejecuta una tarea real: leer archivos, explicar una función, proponer un diff. Un respaldo que nunca se probó es una suposición, no un respaldo. Esto es idéntico a un backup que jamás se restauró: validar que el respaldo sirve es un ejercicio separado de tenerlo.
7. Deja el MITM fuera. Si un cliente no permite cambiar su endpoint, la respuesta es usar otro cliente, no reescribir la confianza criptográfica del equipo.

Conclusiones: cuándo un router de LLM con fallback vale la pena

Un router de modelos con fallback resuelve un problema real y acotado: que la caída o el límite de un proveedor no detenga el trabajo. Como patrón de arquitectura, es sensato y viejo.

Lo que no resuelve es el costo, y lo que puede empeorar es tu superficie de riesgo. Las dos decisiones que separan una implementación profesional de un experimento caro son concretas:

• Autenticarse con API keys propias, no con el OAuth de una suscripción. Es la diferencia entre una arquitectura y una infracción de términos con historial de sanciones.
• Tratar al router como lo que es: un punto de concentración de credenciales que hereda el nivel de exposición de la clave más valiosa que guarda.

Y el criterio de fondo, que aplica mucho más allá de este tema: la continuidad operacional no se consigue acumulando herramientas. Se consigue sabiendo qué falla estás cubriendo, probando que la cobertura funciona, y midiendo lo que la solución agrega en riesgo además de lo que quita en molestia. Decidir bien evita pagar dos veces.

Cómo Reactiv puede ayudar

Si tu equipo de desarrollo ya depende de asistentes de IA para trabajar —y a esta altura, la mayoría depende— esa dependencia es infraestructura —lo mismo vale para la memoria y el contexto que le das a esos asistentes—. Y como toda infraestructura, se diseña, se asegura y se le mide la continuidad. En Reactiv lo abordamos así:

• Arquitectura de infraestructura Linux. Definimos si realmente necesitas un router, qué falla cubre y cómo se integra sin volverse un punto único de fallo. Muchas veces la respuesta correcta es una configuración más simple que la que estabas por instalar.
• Revisión de código y configuración. Auditamos cómo quedaron las credenciales, los endpoints y los permisos: qué se guarda, dónde, en qué formato y quién puede leerlo.
• Ethical hacking. Verificamos la exposición real de las herramientas internas del equipo —dashboards en localhost que terminaron en un túnel, tokens en texto plano, certificados de confianza instalados sin control.
• Continuidad operacional. Diseñamos y probamos los planes de respaldo, que es la parte que casi siempre se omite. Un fallback sin ensayo es del mismo tipo de ficción que un backup sin restauración.

Trabajamos con equipos que operan infraestructura crítica en Linux, MySQL/MariaDB y entornos autohospedados. Si quieres que tu equipo de desarrollo gane continuidad sin ampliar su superficie de riesgo, conversemos: revisamos tu caso concreto y te decimos qué cambiaríamos, con criterio y sin vender capas que no necesitas.