Esta madrugada Claude estuvo devolviendo errores durante casi tres horas, y mi primera reacción no fue abrir el estado del servicio: fue abrir mis propios flujos de n8n a ver cuáles se habían quedado a medias. Esa reacción, que probablemente compartes si vives de esto, es la noticia real del día. La caída del 24 de agosto no me parece un escándalo; me parece la confirmación de algo que llevamos semanas fingiendo que no pasa. Anthropic acumula incidentes el 6, el 7, el 14, el 16, el 18, el 19, el 20 y hoy el 24 —el del día 6 clasificado como grave— y con esa cadencia dejamos de hablar de un accidente para hablar de una característica del servicio. Mi postura es incómoda y no va dirigida a Anthropic: si una automatización que has vendido a un cliente no sobrevive a tres horas de API caída, el problema es tuyo.
Ocho incidentes en tres semanas ya no son mala suerte
Los datos del episodio de hoy son conocidos: errores elevados desde las 05:06 UTC, resueltos hacia las 08:30 UTC, con impacto en claude.ai, la API, Claude Code y Cowork, y con Mythos 5, Fable 5, Opus 5 y Opus 4.8 entre los modelos afectados. Anthropic identificó la causa y la comunicó después. Como gestión de incidente, correcto. Como hecho aislado, irrelevante para cualquiera que no estuviera trabajando a esa hora.
Lo que cambia el significado es la lista. Ocho fechas con incidencias en menos de tres semanas dibujan un patrón, y un patrón se planifica. No es lo mismo diseñar sobre un servicio que se cae una vez al trimestre que sobre uno que ha tenido problemas uno de cada dos o tres días durante un mes entero. La primera situación permite ignorar el riesgo y tener razón casi siempre. La segunda convierte esa misma decisión en negligencia, porque ya no estás apostando contra un imprevisto: estás apostando contra una estadística que tienes delante.
Y aquí es donde el debate se tuerce siempre hacia el sitio cómodo. Es facilísimo escribir el artículo que exige a Anthropic más fiabilidad, más transparencia y más créditos de servicio. Lo firmaría, y no cambiaría absolutamente nada de mi lunes por la mañana. Anthropic va a seguir creciendo a un ritmo que castiga su infraestructura, va a seguir lanzando modelos, y sus incidentes seguirán existiendo. La única variable sobre la que tengo control es cómo está montado lo que yo entrego.
Cuando facturas automatizaciones no vendes un modelo: vendes que el proceso ocurra. Y eso se cumple o no se cumple los días malos.
Lo que le vendes al cliente es disponibilidad, aunque no lo hayas escrito
Cuando entrego un flujo que genera contenido, lo revisa y lo publica en un WordPress, el cliente no compra tokens ni entiende qué modelo hay detrás. Compra que los martes aparezcan tres entradas publicadas. Esa expectativa es un compromiso de disponibilidad en toda regla, solo que no está firmado en ninguna parte, no tiene ventana de mantenimiento pactada y no incluye ninguna cláusula sobre proveedores externos. Hemos estado asumiendo, gratis y sin decirlo, el riesgo operativo de una empresa de la que no controlamos nada.
Me incluyo sin reservas. En ninguna propuesta que he mandado este año aparece una línea que diga que el servicio depende de un proveedor externo, que ese proveedor tiene incidencias documentadas y que en esos casos el proceso se retrasa. No lo he puesto por la razón de siempre: porque suena a excusa preventiva y porque nadie más lo pone. Después de agosto, la que suena mal es la conversación contraria, la de explicar por teléfono a las nueve de la mañana por qué no salió lo que tenía que salir mientras buscas el enlace a un status page para demostrar que no fue culpa tuya.
Un párrafo en el presupuesto no arregla la caída, pero cambia la naturaleza de la conversación: convierte un fallo en un escenario previsto. Y lo que es más importante para el freelance, deja de ser un motivo de desgaste con el cliente para pasar a ser una demostración de que sabes cómo funciona lo que estás montando.
Un workflow serio se nota los días en que la API no responde
La parte técnica no tiene ningún misterio, y por eso resulta tan molesto no haberla aplicado. Un flujo que aguanta un incidente de tres horas hace cuatro cosas que un flujo escrito con prisa no hace:
- Reintenta con backoff exponencial y algo de aleatoriedad, en lugar de disparar tres reintentos seguidos en diez segundos y darse por vencido justo cuando el servicio empieza a recuperarse.
- Guarda estado entre pasos, para que reanudar no signifique volver a generar —y volver a pagar— todo lo que ya estaba hecho antes del fallo.
- Distingue un error temporal de uno definitivo, porque tratar una sobrecarga como si fuera una petición mal formada es la forma más rápida de perder trabajo bueno.
- Avisa a un humano cuando se rinde, en vez de terminar en silencio con estado verde y dejar el hueco para que lo descubra el cliente.
Sobre el fallback de modelo tengo una opinión menos entusiasta de la que se lleva. Cambiar automáticamente a otro proveedor cuando Claude falla suena bien en un diagrama y funciona regular en producción: los prompts están afinados para un modelo concreto, el formato de salida cambia lo justo para romper el paso siguiente, y acabas publicando algo peor sin enterarte. Para tareas mecánicas el fallback tiene sentido; para lo que va firmado con el nombre de tu cliente, prefiero un flujo que se detenga y avise antes que uno que improvise. Degradar con criterio también es tolerancia a fallos.
Claude Code es donde más duele y donde menos red tenemos
Hay una diferencia importante entre un flujo desatendido y una sesión de trabajo, y hoy se ha visto. Un flujo que falla se reintenta. Una sesión larga de Claude Code que se corta a mitad de una refactorización deja algo peor que un error: deja un repositorio en un estado intermedio que nadie diseñó, con la mitad de los cambios aplicados y sin la conversación que explicaba a dónde iban. Recuperar eso cuesta más que empezar de cero, y esa es la clase de pérdida que no aparece en ningún informe de incidente.
La lección que me llevo es de higiene, no de arquitectura: commits pequeños y frecuentes durante las sesiones largas, ramas separadas para el trabajo agéntico, y una regla que llevo tiempo repitiéndome y saltándome, que es no lanzar tareas de una hora sin un punto de control intermedio. No porque Claude vaya a fallar, sino porque cualquier cosa puede fallar y el coste de un checkpoint es de segundos. Hemos normalizado dejar corriendo procesos larguísimos con una confianza que no le damos a ninguna otra herramienta de nuestro stack.
El punto único de fallo lleva el nombre de otra empresa
Durante años nos reímos, con razón, de las arquitecturas con un único servidor sin réplica. Después montamos negocios enteros sobre una sola API de un solo proveedor, sin réplica, sin degradación planificada y sin haberlo puesto por escrito en ningún contrato, y a eso lo llamamos ser productivos. La diferencia es que aquel servidor era nuestro y este punto de fallo tiene el nombre de otra empresa en la factura.
No propongo desconfiar de Claude ni buscar alternativas por deporte; sigo trabajando con él todos los días y no pienso cambiarlo. Propongo algo más aburrido y más útil: tratarlo como lo que es, una dependencia externa excelente y ocasionalmente caída, y montar alrededor lo mismo que montaríamos alrededor de cualquier otra. La madurez de un stack no se mide el día que todo funciona. Se mide a las 05:06 UTC de un lunes cualquiera, cuando el servicio empieza a devolver errores y lo único que queda en pie es lo que tú construiste alrededor.
Agosto nos ha dado ocho avisos. Sería una pena un noveno.
