Tu LLM API va a fallar: el fallback que lo atrapa

En pocas palabras: Sí, tu LLM API va a fallar: GPT-5 devuelve HTTP 429 en hora pico y hay caídas regionales. Lo que lo atrapa es un fallback multi-modelo con reintentos, cadena de modelos y circuit breaker, que enruta cada llamada a un modelo alternativo y mantiene la app viva.

Toda LLM API falla en producción. No “puede fallar”: falla. GPT-5 devuelve 429 en hora pico, Anthropic tiene caídas regionales y Google a veces decide que tu clave no está autorizada para el modelo que venís usando toda la semana. Un sistema de fallback multi-modelo convierte esa caída dura en una degradación suave que el usuario ni nota.

Un sistema de fallback para tu LLM API es una arquitectura que enruta cada llamada a un modelo alternativo cuando el primario está caído, agotó su cuota o quedó deprecado. Combina reintentos, cadenas de modelos, enrutamiento por capacidad y circuit breakers. Su objetivo es mantener la aplicación viva cuando OpenAI, Anthropic o Google fallan, sin depender de un único proveedor ni de una única clave.

¿Por qué los reintentos no alcanzan para una LLM API en producción?

Porque el retry solo cubre lo transitorio: un timeout puntual, un rate limit de dos segundos. Según el artículo original de Seven en dev.to, hay cuatro fallas que el backoff exponencial no resuelve. Y son las que te tiran producción abajo.

Ponele que tu proveedor se cae 30 minutos. El backoff exponencial no te salva: solo hace que tu caller levante una excepción a los 14 segundos en vez de al instante. Tu agente sigue muerto igual.

• Outages sostenidos: si el proveedor está caído media hora, reintentar es esperar contra una pared.
• Cuota agotada: tu clave llegó al límite mensual. Reintentar no lo arregla, solo quema tu error budget más rápido.
• Deprecación de modelo: el proveedor da de baja la versión que fijaste y cada llamada falla con un 404. El retry gira al pedo.
• Bloqueo regional: el endpoint está arriba, pero no desde donde vive tu servidor. El cliente ve un timeout y reintenta contra el mismo muro.

El retry es la primera capa. El fallback es la segunda. Sin la segunda, cualquier caída larga de tu LLM API es una caída tuya.

¿Cómo armar un fallback entre GPT-5, Claude y Gemini?

El patrón base es simple: si el modelo A falla, probás el modelo B, y así por la cadena. Definís una lista ordenada de modelos con su endpoint y su clave, iterás, y devolvés la primera respuesta que salga bien. Si se agotan todos, ahí sí levantás la excepción con el último error registrado. Lo explicamos a fondo en analizar benchmarks de rendimiento de GPT-5.6.

Funciona hasta que deja de funcionar. El problema es que cada proveedor habla distinto. OpenAI usa Chat Completions, Anthropic usa el protocolo Messages con un parámetro system de nivel superior, y Gemini mete las instrucciones de sistema en un campo de config aparte. Si apuntás un cliente con forma de OpenAI a api.anthropic.com, te vuelve un 404 o un error ilegible.

La solución honesta: o mantenés rutas de código separadas por proveedor, o usás un gateway que presente todos los modelos detrás de un solo protocolo. El camino de protocolo único tiene menos ramas para testear (que no es poco cuando estás a las 3 de la mañana viendo por qué tu fallback devuelve basura).

¿Qué es el enrutamiento por capacidad y por qué gana a un orden fijo?

El enrutamiento por capacidad elige el modelo de fallback según lo que la tarea necesita, no según un orden estático. En vez de “probá A, después B, después C”, tu código declara la intención: “necesito contexto largo” o “necesito tool calling”, y el dispatcher elige los modelos que cumplen ese requisito. Es más resiliente y deja el código autodocumentado.

La diferencia práctica: una lista fija te puede mandar una tarea de razonamiento con contexto de 200k tokens a un modelo que no lo banca, y ahí el “fallback” falla igual. Declarando la capacidad requerida, el dispatcher descarta de entrada los que no sirven. Menos sorpresas cuando el primario cae y quedás a merced del segundo.

¿Cuáles son las trampas al saltar entre proveedores?

Hay tres trampas que rompen el fallback en silencio, y ninguna te tira un error obvio. Vienen directo del análisis de dev.to y son las que más duelen porque el sistema “parece” andar. Te puede servir nuestra cobertura de comparar costos y estrategia de routing.

• El system prompt desaparece: tu prompt de sistema cuidadosamente armado puede llegar como mensaje de usuario, o directamente no llegar. Testealo pidiéndole al modelo que cite el system prompt textual. Si no puede, tu fallback lo está tirando a la basura.
• El tool calling se rompe entre familias: los esquemas de function calling de Anthropic y OpenAI son distintos. Las definiciones que andan en GPT pueden producir bloques que tu parser no reconoce en Claude.
• Incompatibilidad de protocolo: el mismo request con forma de un proveedor genera un 404 en otro sin capa de traducción.

La regla que da el autor: para pipelines de agentes con tool calling pesado, hacé fallback dentro de la misma familia primero (familia GPT antes que Claude antes que Gemini) y cruzá familias solo cuando la tarea no exija salida estructurada.

Proveedor	Protocolo	System prompt	Tool calling
OpenAI (GPT-5)	Chat Completions	Rol system en el array de mensajes	Esquema propio de functions
Anthropic (Claude)	Messages	Parámetro system de nivel superior	Esquema propio, incompatible con OpenAI
Google (Gemini)	generativelanguage v1beta	Campo de config aparte	Otro esquema distinto

¿Cómo funciona un circuit breaker para no quemar cuota?

Un circuit breaker corta las llamadas a un modelo tras N fallos consecutivos y lo reactiva recién después de un cooldown, por ejemplo 30 segundos. Evita que ante una caída del primario tu sistema empiece a martillar todos los fallbacks al mismo tiempo y termine agotando la cuota en cascada sobre proveedores que estaban sanos.

El escenario que previene: tu primario devuelve 429 porque te pasaste del rate limit. Sin breaker, cada request fallida dispara un intento inmediato en el siguiente modelo, después en el siguiente, y así con cada usuario en simultáneo. Multiplicá eso por mil pedidos por minuto y quemaste la cuota de tres proveedores en un rato. El breaker abre el circuito, espera, y prueba de nuevo cuando el modelo tuvo tiempo de recuperarse.

¿Qué monitorear para saber si tu fallback anda?

Como mínimo, logueá tres cosas por llamada: qué modelo respondió, qué tipo de error tiró cada modelo que falló antes, y la latencia. Cuando una llamada tiene éxito recién en el tercer modelo de la cadena, necesitás saber por qué fallaron los dos primeros. Un fallback sin instrumentación es una pesadilla de debugging.

La métrica que hay que vigilar en el tiempo es el fallback rate: el porcentaje de llamadas que terminan en un modelo de respaldo. Si trepa por encima del 1-2%, tu proveedor primario tiene un problema de confiabilidad. Si pega un salto de golpe, algo se rompió. En los dos casos querés enterarte antes que tus usuarios. Relacionado: elegir entre múltiples modelos alternativos.

Sumá un health check que le pegue al primario cada 60 segundos con un prompt trivial y exponga el resultado, algo tipo {"status": "ok", "latency_ms": 420}. Enchufalo a tu monitoreo actual. Querés detectar la degradación del proveedor antes de que tu fallback tenga que demostrar de qué está hecho bajo fuego.

¿Cómo probar el fallback sin esperar la caída?

El peor momento para descubrir que tu fallback está roto es durante una caída real. Provocá la falla vos mismo, con estos tres métodos que trae el artículo:

• Endpoint muerto: apuntá el primario a un puerto donde no escucha nada, tipo http://localhost:19999/v1, y verificá que dispare el fallback.
• Proxy de inyección de errores: un proxy chico que devuelve 503 en ~30% de los requests. Corré tu app contra él. Si el fallback no salta en pocos requests, algo está mal configurado.
• Rotación de clave: cambiá la clave del primario por un valor inválido. Esto agarra el caso donde el fallback está configurado pero las credenciales están mal, una falla silenciosa hasta que el primario se cae de verdad.

¿Qué limitaciones honestas tenés que aceptar?

Ningún sistema de fallback es transparente para el que llama. Estos son los costos reales, sin maquillaje.

• Latencia: cada intento suma conexión más inferencia. Una llamada que normalmente tarda 800 ms puede irse a 3+ segundos si fallan los dos primeros modelos. Para tiempo real, poné un timeout total y avisale al usuario que hay un fallback en curso.
• Costo impredecible: los modelos de respaldo pueden tener otro precio. Si tu primario tiene una mala semana y todo el tráfico se va a un fallback más caro, tu factura se dispara. Trackéa gasto por modelo y poné alertas.
• Deriva de comportamiento: un prompt que Claude maneja elegante puede producir rechazos agresivos en Gemini. Testeá los modelos de respaldo con tus prompts reales antes de depender de ellos.
• Se acabó el determinismo: modelos distintos dan salidas distintas. Si tu app depende de comportamiento determinista, el fallback cross-model cambia la semántica de la llamada. Te mantiene vivo, no idéntico.

Y no existe la opción sin dependencias. Un fallback que abarca varios proveedores significa que dependés de todos ellos: su uptime, sus cambios de precio, sus deprecaciones. Tu superficie operativa se multiplica. Es el precio de no morir cuando cae uno.

Qué significa para equipos en Latinoamérica

El bloqueo regional pega más fuerte acá. Un endpoint que responde bárbaro desde un datacenter en Estados Unidos puede darte timeout o rechazo desde un servidor en la región. Si desplegás tu app sobre infraestructura local, tener un fallback y monitorear la latencia por región deja de ser un lujo. Para el hosting y los servidores donde corre tu backend, donweb.com es una opción AR a considerar. El health check cada 60 segundos te avisa cuando un proveedor se degrada desde tu ubicación puntual, antes de que el usuario final vea el error.

Errores comunes al implementar fallback

• Confiar en el retry como si fuera fallback: reintentar contra el mismo proveedor caído no te salva de un outage de 30 minutos. Necesitás otro modelo, no el mismo tres veces.
• No testear el system prompt tras el salto: el fallback dispara, la llamada “tiene éxito”, pero el prompt de sistema se perdió y el modelo responde cualquier cosa. Verificá que el prompt sobrevive el cruce de proveedor.
• Fallback sin circuit breaker bajo carga: ante un 429 masivo, martillar todos los respaldos en simultáneo agota la cuota en cascada. El breaker corta y espera.
• Tratar el gateway como infalible: un gateway que unifica todos los modelos también es un único punto de falla. Si se cae, se caen todos. Mantené una clave directa a un proveedor como escape para los caminos críticos.

Preguntas Frecuentes

¿Cuál es la diferencia entre retry y fallback para una LLM API?

El retry reintenta la misma llamada contra el mismo modelo, útil para blips de red y rate limits cortos. El fallback cambia a otro modelo o proveedor cuando el primario está caído, con la cuota agotada o deprecado. El retry es la primera capa; el fallback es la segunda y la que te salva de una caída larga. Sobre eso hablamos en considerar alternativas como Claude.

¿Qué es un circuit breaker para APIs de IA?

Un circuit breaker es un patrón que deja de llamar a un modelo tras N fallos consecutivos y lo reactiva recién después de un cooldown, por ejemplo 30 segundos. Evita cascadas donde una falla del primario dispara intentos inútiles en todos los proveedores a la vez y termina quemando cuota sana.

¿Cómo monitoreo si mi sistema de fallback funciona?

Logueá por cada llamada el modelo que respondió, el error de los que fallaron y la latencia, y seguí el fallback rate en el tiempo. Si ese porcentaje pasa de 1-2%, tu proveedor primario tiene un problema. Sumá un health check cada 60 segundos que pruebe el primario con un prompt trivial.

¿Cómo pruebo el fallback sin esperar una caída real?

Apuntá el primario a un puerto muerto como localhost:19999, o levantá un proxy que devuelva 503 en el 30% de los requests, o rotá la clave a un valor inválido. Cualquiera de los tres fuerza la falla y te muestra si el fallback dispara en segundos o si está mal configurado.

¿Conviene hacer fallback entre proveedores o dentro de la misma familia?

Para tareas con tool calling o salida estructurada, hacé fallback dentro de la misma familia primero (por ejemplo GPT antes que Claude antes que Gemini), porque los esquemas de function calling no son compatibles entre proveedores. Cruzá familias solo cuando la tarea no exige salida estructurada y ya testeaste tus prompts en el modelo de respaldo.

Conclusión

El objetivo de un sistema de fallback no es la perfección: es convertir una falla dura (tu agente crashea, tu pipeline se frena, el usuario ve un error) en una degradación suave que capaz ni se nota. Vale la complejidad extra.

Si te llevás una sola cosa, hacé estas tres hoy: identificá y contá cuántas llamadas de tu código son mono-modelo y mono-proveedor (cada una es un punto único de falla); agregá una cadena de dos modelos a un camino no crítico, como una clasificación o un resumen, instrumentalo y mirá los logs una semana; y sumá un health check que pruebe el primario cada 60 segundos. Después llevás el patrón a los caminos críticos, ya con confianza y no a los apurones durante la próxima caída.

Fuentes

• Your LLM API will fail in production. Here’s the fallback system that catches it – artículo original de Seven en dev.to
• llm-honesty-probe – herramienta open source que verifica si tu endpoint sirve el modelo que dice servir
• Documentación de OpenAI – protocolo Chat Completions
• Documentación de Anthropic – protocolo Messages y parámetro system
• Documentación de Google Gemini – API generativelanguage