Llevo meses dando el mismo consejo, aquí y a clientes: mete un nodo de fallback en n8n, que si Claude falla tire de otro modelo y el flujo siga vivo. Hoy toca reconocer que ese consejo, tal y como lo he estado dando, no habría salvado absolutamente nada el 3 de septiembre. Claude, ChatGPT y Grok se cayeron a la vez, en la misma franja de la tarde. El plan B estaba tan muerto como el plan A.
No escribo esto para regodearme en la caída de nadie. Escribo porque la lección que va a sacar la mayoría de la gente —»pues meto un tercer proveedor»— es la lección equivocada, y porque el error de diseño que ayer quedó al descubierto es mío, no de Anthropic.
El plan B estaba caído a la misma hora
Los números, porque importan para el argumento. En Anthropic no fue una caída, fueron dos incidentes encadenados. El primero, corto, afectó a Claude Sonnet 5 entre las 12:37 y las 12:56 UTC: diecinueve minutos, algo que ni te enteras si tus flujos reintentan. El segundo empezó a las 13:26 UTC y no se dio por resuelto hasta las 16:23 UTC, casi tres horas, con errores elevados en Mythos 5.1, Fable 5.1, Opus 5, Opus 4.8 y Opus 4.6. Es decir: prácticamente toda la gama alta, incluido el modelo que Claude Code trae por defecto desde el 1 de septiembre.
En paralelo, OpenAI reportaba tasas de error elevadas en ChatGPT y en Codex. Grok también estaba caído, y xAI reconoció que estaba trabajando en ello. Y por debajo de los tres, Microsoft Azure registraba a la vez un pico de reportes de incidencias. Nadie ha explicado si esas cuatro cosas están conectadas. Pero que no esté demostrado no significa que sea casualidad, y ese es exactamente el punto que me interesa.
El fallback entre modelos protege del bug, no del apagón
Aquí está mi postura, y es autocrítica. Cuando montas un nodo de fallback de Claude a GPT, estás protegiéndote de una clase concreta de fallo: que ese proveedor tenga un mal día, que te devuelva un 429 por límites, que un modelo concreto se retire, que una respuesta no valide contra tu esquema. Para eso el fallback funciona y hay que tenerlo. Lo que no cubre es el escenario de ayer, porque la redundancia de proveedor solo es redundancia si las dependencias por debajo son distintas, y no lo son.
Los tres grandes se apoyan en un puñado muy corto de nubes, en las mismas regiones, con el mismo hardware de un único fabricante dominante y con proveedores de cómputo que se solapan entre ellos. Cuando eliges «otro modelo» como reserva, sobre el papel has diversificado el proveedor; en la práctica, muchas veces has cambiado de logo sin cambiar de centro de datos. Es la falacia clásica de la alta disponibilidad: dos servidores en el mismo rack no son dos servidores, son un rack.
Dos modelos distintos sobre la misma nube no son dos proveedores. Son un proveedor con dos facturas.
Y hay algo peor que no protegerte: el fallback mal entendido te hace creer que estás cubierto. Yo he cerrado propuestas describiendo ese nodo como garantía de continuidad. Ayer esa garantía valía cero durante tres horas, y si un cliente me lo hubiera preguntado en caliente no habría tenido nada que responder más allá de «está caído todo».
Lo que aguanta no es un segundo proveedor, es una cola
La redundancia que sí sobrevivió ayer no es de modelo, es de arquitectura, y se resume en una pregunta incómoda: ¿cuántos de tus flujos tienen una llamada a un LLM en el camino crítico de algo que debe responder en el acto? Cada uno de esos es una bomba de relojería con la mecha en manos de terceros.
Lo que convierte tres horas de caída en un incidente aburrido es bastante viejo y nada glamuroso. Trabajo asíncrono en vez de síncrono: la petición entra en una cola, se procesa cuando se pueda y el resultado se entrega después. Reintentos con backoff exponencial y jitter, para no ir todos a la vez contra la API en el segundo en que vuelve —porque si tu flujo y otros diez mil reintentan al unísono, la segunda caída la provocas tú—. Idempotencia, con una clave por tarea, para que ese reintento no publique el mismo post dos veces en WordPress ni mande el mismo email dos veces al cliente. Y degradación explícita: preferible un aviso de que el informe llegará por la tarde que un flujo que muere en silencio y descubres tres días después.
🔧 Revisión rápida, media hora bien invertida
Abre tus workflows y clasifícalos en dos montones: los que un usuario o un cliente está esperando en tiempo real, y los que pueden terminar más tarde sin que nadie se entere. Del primer montón, saca todas las llamadas a la API que puedas: precalcula, cachea la respuesta anterior, o responde con un estado «en proceso». Del segundo, comprueba solo tres cosas: que reintenta, que el reintento espera cada vez más, y que ejecutarlo dos veces no duplica nada.
Ninguna de esas cuatro ideas es novedad para quien viene de sistemas. Lo llamativo es lo poco que se aplican en automatización con IA, donde el patrón dominante sigue siendo el webhook que llama a un modelo y devuelve la respuesta al momento. Hemos importado la comodidad del prompt y respuesta del chat a la capa de producción, y con ella hemos importado una fragilidad que en cualquier otro contexto nos parecería inaceptable.
«Identificamos la causa» no es un post mortem
Dicho todo lo anterior, y asumida mi parte, hay una segunda incomodidad y esta sí es del lado del proveedor. Anthropic comunicó bien durante el incidente: actualizó su página de estado, reconoció el problema pronto y dijo haber identificado la causa. Perfecto. Lo que no ha llegado, un día después, es cuál era esa causa. Tampoco ha llegado de OpenAI ni de xAI ninguna explicación de por qué tres compañías competidoras se cayeron en la misma tarde.
Me parece poco. No por transparencia abstracta, sino por una razón práctica muy concreta: sin saber qué falló, no puedo decidir si mi mitigación sirve. Si la causa fue un despliegue interno de Anthropic, diversificar proveedor ayuda. Si fue una dependencia compartida de red o de nube, diversificar proveedor no ayuda nada y lo que tengo que hacer es rediseñar el flujo. Son dos inversiones de tiempo completamente distintas y no tengo el dato para elegir. Cuando una API se convierte en infraestructura sobre la que otros facturan trabajo a clientes, el post mortem público deja de ser un gesto de buena voluntad y pasa a ser parte del producto.
Lo que voy a cambiar esta semana
Voy a dejar de vender el nodo de fallback como garantía de continuidad, porque no lo es, y voy a empezar a decir a los clientes una frase bastante menos vendedora: este flujo depende de una API que puede estar caída tres horas, y lo hemos diseñado para que eso solo signifique un retraso. Es peor titular comercial y es mucho mejor ingeniería.
Y voy a asumir una idea que ayer se vio con una claridad rara: los tres grandes modelos de IA no son tres opciones independientes, son tres interfaces sobre una infraestructura común y bastante más concentrada de lo que nos gusta pensar. Mientras eso siga siendo cierto, la pregunta correcta no es «¿a qué modelo salto si este falla?», sino «¿qué parte de mi trabajo sigue funcionando cuando no hay ningún modelo disponible?». Si la respuesta honesta es «ninguna», la caída del 3 de septiembre no fue un incidente ajeno. Fue un aviso con nombre y apellidos.
