40 min sin Anthropic: armá tu fallback Multi-LLM

Se cae Anthropic durante 40 minutos. Si tu SaaS depende solo de Claude, tu producto no funciona durante esos 40 minutos.

Es una ecuación brutal y simple que la mayoría de los founders deciden ignorar hasta que les explota en la cara. Durante 2025 vimos múltiples caídas de servicio masivas en los tres gigantes: OpenAI, Anthropic y Google. Cada vez que uno de estos outages ocurre, las redes se llenan de desarrolladores mostrando cómo sus aplicaciones quedaron completamente congeladas, devolviendo errores 500 a usuarios que están pagando por un servicio que no pueden usar.

Llevo casi 40 años de oficio peleando con sistemas en producción. Si algo te enseña la calle es que asumir que una red externa va a estar siempre disponible es ingeniería de la esperanza. Y la esperanza no es una estrategia válida cuando tenés facturas que pagar.

En la arquitectura de sistemas clásicos, jamás dejarías que toda tu operación dependa de un solo servidor sin redundancia. Sin embargo, en la fiebre del desarrollo con IA, veo arquitecturas enteras hardcodeando un cliente de Anthropic u OpenAI en su backend, atando la supervivencia de su negocio al uptime de un tercero.

Para resolver esto en proyectos propios como Konfetify (que corre sobre Next.js, Supabase y Vercel) o en plataformas analíticas como saas-metrics-ai, la regla es clara: el sistema asume que el modelo principal va a fallar. Para lograr esa resiliencia, tenés que implementar una capa de orquestación Multi-LLM.

Cuatro estrategias para no depender de un solo proveedor

No se trata simplemente de poner un bloque try/catch y llamar a otro modelo si el primero da error. Una arquitectura Multi-LLM seria requiere manejar el estado, el contexto y los costos de manera inteligente.

1. Health check y circuit breaker

El patrón más básico y urgente es el Circuit Breaker (cortacircuitos). Si la API de OpenAI está caída y tardando 15 segundos en devolver un timeout, no podés permitir que cada request de tus usuarios espere 15 segundos antes de intentar con un fallback. Vas a colapsar tu propio servidor por agotar los hilos de conexión.

Necesitás implementar un sistema que mida la tasa de fallos. Si detectás tres timeouts seguidos, el circuito se "abre" y todos los nuevos requests se enrutan inmediatamente al proveedor secundario (por ejemplo, Gemini) sin siquiera intentar pegarle al proveedor principal caído. Librerías como el AI SDK de Vercel, LiteLLM o LangChain te permiten estructurar estos fallos de forma casi transparente, estandarizando los payloads de entrada y salida para que cambiar de proveedor no rompa tu interfaz.

2. Fallback por capability

No todos los modelos son buenos para lo mismo, y tu fallback debería ser consciente de las capacidades (capabilities) de cada uno.

Si el request original requería razonamiento profundo o escritura de código complejo, tu primera opción natural hoy suele ser Claude. Si Claude falla, el fallback lógico no es un modelo rápido de Google, sino escalar a la familia de GPT-4.

En cambio, si estabas usando OpenAI por su predictibilidad extrema para generar estructuras JSON complejas y llamar a herramientas (tool calling), tu fallback tiene que ser un modelo que garantice esa misma estructura. Por otro lado, si la tarea era procesar un PDF gigante de 1.5 millones de tokens, tu única opción real de fallback o ruteo es Gemini, que domina la ventana de contexto multi-modal de 2M. Enrutar por capacidad significa que el sistema sabe qué pedirle a quién cuando las papas queman.

3. Cost-based routing

El 80% de los SaaS construidos rápido con IA mandan absolutamente todos los prompts al modelo más caro y pesado que encuentran. Usan GPT-4o o Claude 3.5 Sonnet para resumir un mail de tres líneas. Es un desperdicio financiero ridículo.

El ruteo por costos (cost-based routing) es la estrategia donde tu orquestador evalúa la complejidad de la tarea. Para tareas simples, clasificación rápida o extracción de datos básicos, el sistema siempre dispara primero a Gemini Flash o GPT-4o-mini. Solo si el modelo económico devuelve un error de formato, alucina (validado por tu capa determinista) o reporta baja confianza, el sistema hace un fallback hacia los modelos más grandes y caros. Implementar esto en producción suele ahorrarte entre un 60% y un 80% de la factura de IA a fin de mes, manteniendo la misma calidad percibida por el usuario.

4. Multi-region failover

A veces no podés cambiar de proveedor. Si estás construyendo un sistema para un cliente enterprise, es muy probable que por cuestiones de compliance (GDPR, HIPAA, etc.) te exijan usar exclusivamente Azure OpenAI o AWS Bedrock en una región específica. No tenés permiso legal para mandar los datos a Google si falla Azure.

En este caso, el fallback debe ser multi-región. Tenés tu cliente configurado apuntando a US-East. Si el datacenter de esa región se cae (como pasó varias veces en los últimos meses), tu orquestador intercepta el error y redirige el tráfico a tu instancia desplegada en EU-West. Seguís usando el mismo proveedor y el mismo modelo, pero saltás el outage regional de infraestructura.

El momento exacto para implementarlo

Multi-LLM NO es para todos. Y este es el anti-claim que tenés que entender antes de ponerte a reescribir tu código.

Si tenés 10 usuarios y estás iterando frenéticamente para encontrar el Product-Market Fit (PMF), tu foco tiene que estar en el producto. Si Anthropic se cae, le mandás un mail a esos 10 usuarios pidiendo disculpas, te vas a tomar un café, y esperás a que vuelva. No tiene sentido quemar semanas de ingeniería agregando complejidad de infraestructura cuando todavía no sabés si tu SaaS tiene sentido de existir.

Pero la ecuación cambia de golpe. Cuando tenés 100+ usuarios pagos, SLAs que respetar y empresas reales dependiendo de tu herramienta para operar, un outage prolongado de un proveedor te cuesta la confianza del cliente, cancelaciones de suscripciones y, potencialmente, un mes de runway por daño reputacional. Ahí, tener un fallback deja de ser un lujo de arquitectura y se convierte en una obligación técnica.

La diferencia entre un vibe-coded MVP y un SaaS B2B serio es que el segundo tiene un plan claro y automatizado para cuando los sistemas que no controla fallan.