Cómo hacer que tu aplicación de IA sobreviva cuando un modelo desaparece de repente

Todo desarrollador que construye sobre IA acaba aprendiendo la misma lección por las malas: el modelo del que dependes no tiene garantizado estar ahí. Puede quedar limitado por tasa en horas punta, devolver un rechazo, dar un error de sobrecarga o — como le pasó a Claude Fable 5 en junio de 2026 — apagarse por completo por razones que no tienen nada que ver con tu código. Las aplicaciones que sobreviven a estos momentos no son las que tienen el mejor prompt. Son las que planificaron la ausencia del modelo.

Esta guía recorre un enfoque práctico y por capas para la resiliencia que funciona tanto si llamas a un proveedor directamente como si enrutas a través de una pasarela.

Paso 1: Nunca codifiques un único modelo de forma fija

La fragilidad más común es un nombre de modelo incrustado directamente en una petición. En el momento en que esa cadena deja de funcionar, todas las llamadas fallan. En su lugar, define tus modelos como configuración — una pequeña lista de prioridad, no una constante:

MODEL_CHAIN = [
    "claude-opus-4-8",      # primary
    "claude-sonnet-4-6",    # same provider, cheaper/faster
    "gpt-5.5",              # different provider entirely
]

Este único cambio hace que cambiar de proveedor durante un incidente sea una edición de configuración, no un despliegue de código. Fíjate en que la tercera entrada es un proveedor distinto. Los respaldos del mismo proveedor te protegen de la caída de un único modelo; los respaldos entre proveedores te protegen de la caída de todo el proveedor — o de que lo obliguen a apagarse.

Paso 2: Usa una cadena de respaldo, no un único intento

El patrón es simple: prueba cada modelo en orden, pasa al siguiente cuando falle y solo expón un error si se agota toda la cadena.

def call_with_fallback(messages):
    last_error = None
    for model in MODEL_CHAIN:
        try:
            return client.complete(model=model, messages=messages)
        except (RateLimitError, OverloadError, RefusalError) as e:
            last_error = e
            continue  # try the next model
    raise AllModelsFailedError(last_error)

Lo que usas como respaldo importa. Reintentar el mismo modelo ante un overloaded transitorio (HTTP 529) tiene sentido tras un breve retroceso. Pero un error de autenticación o una petición mal formada fallarán de forma idéntica en todos los modelos — esos deberían exponerse de inmediato en lugar de consumir toda tu cadena.

Paso 3: Apóyate en la plataforma cuando ofrece respaldos de forma nativa

No siempre tienes que hacerlo todo a mano. Varias plataformas ya lo hacen en el lado del servidor:

• La API de Anthropic añadió un parámetro beta fallbacks que reintenta una petición rechazada en un modelo alternativo en un solo viaje de ida y vuelta — Fable 5, por ejemplo, estaba configurado para recurrir a Opus 4.8 cuando sus clasificadores rechazaban una petición. La facturación sigue al modelo que realmente sirvió la respuesta.
• OpenRouter te permite pasar un array models en orden de prioridad; conmuta automáticamente ante errores de longitud de contexto, marcas de moderación, límites de tasa y caídas, facturándote a la tarifa del modelo que respondió.
• LiteLLM incluye un Router con reintentos, respaldos y balanceo de carga integrados entre despliegues y proveedores, que autoalojas para máximo control.

Una pasarela como OpenRouter o LiteLLM te da un único endpoint unificado entre muchos proveedores, de modo que un respaldo entre proveedores es solo otra entrada en una lista en lugar de un segundo SDK que integrar.

Paso 4: Añade un disyuntor para fallar rápido

Si un modelo está claramente caído, no querrás que cada petición espere a que agote el tiempo de espera antes de pasar al siguiente. Un disyuntor (circuit breaker) rastrea los fallos recientes y, una vez cruzado un umbral, omite por completo el modelo roto durante un período de enfriamiento. Los equipos en producción en 2026 suelen situarse en torno a cinco fallos consecutivos para disparar el disyuntor y un enfriamiento de ~60 segundos antes de probar la recuperación. Mientras el disyuntor está abierto, el tráfico va directo al siguiente modelo de la cadena — sin latencia desperdiciada.

Paso 5: Decide qué significa "degradado" para tu producto

Recurrir a un modelo más barato no es gratis — la calidad baja y tus prompts pueden comportarse de forma diferente. Planifícalo:

• Prueba tus prompts contra cada modelo de la cadena. Un prompt afinado para un modelo puede producir resultados notablemente peores en su respaldo.
• Avisa al usuario cuando hayas degradado si importa (p. ej. "funcionando en modo rápido"), en lugar de entregar silenciosamente resultados de menor calidad.
• Registra qué modelo sirvió realmente cada petición para que puedas ver, tras un incidente, cuánto tráfico absorbieron los respaldos.

La conclusión

La resiliencia no es una funcionalidad que atornillas tras el lanzamiento — es una pequeña cantidad de estructura que añades pronto: configuración en lugar de constantes, una cadena de prioridad en lugar de una única llamada, un disyuntor para fallar rápido y prompts probados en cada nivel. Los equipos cuyas aplicaciones siguieron en pie durante el apagón de Fable 5 de junio no tuvieron suerte. Simplemente ya habían respondido a la pregunta que todo constructor de IA debería hacerse el primer día: ¿qué pasa cuando este modelo no esté ahí mañana?