Claude ha encadenado más de 20 incidentes de disponibilidad en tres semanas: qué se sabe con certeza y qué hacer si dependes de la API a diario
El 3 de septiembre, un fallo confirmado por Anthropic afectó durante poco más de tres horas a Sonnet 5, Opus 5 y varios modelos Mythos y Fable, coincidiendo con caídas simultáneas de ChatGPT y Grok. Un análisis independiente sitúa ese incidente dentro de
Tres horas y seis minutos de errores elevados, confirmados por la propia Anthropic
El 3 de septiembre de 2026, a las 9:41 de la mañana hora del Este de Estados Unidos, la página oficial de estado de Anthropic empezó a reportar tasas de error elevadas al enviar solicitudes a varios modelos de Claude. En los minutos siguientes, la compañía confirmó que el problema afectaba a Claude Mythos 5.1, Fable 5.1, Mythos 5, Fable 5, Opus 5, Opus 4.8 y Opus 4.6, y publicó actualizaciones sucesivas a medida que identificaba la causa y desplegaba una solución. Según el propio historial de estado de Anthropic, el incidente quedó resuelto tras un total de tres horas y seis minutos, con el impacto completamente cesado a las 9:16, hora del Pacífico. La coincidencia temporal no pasó desapercibida: ese mismo día, según informó The Register, tanto ChatGPT como Grok sufrieron interrupciones propias, en el caso de OpenAI por un error de enrutamiento que comenzó poco antes de las ocho de la mañana hora del Pacífico.
Qué dice exactamente la fuente oficial, y qué no
La página status.claude.com de Anthropic es la fuente primaria más fiable para saber si un problema de disponibilidad es real: publica el estado de cada componente por separado —la API de Claude, Claude Code, Claude Cowork, Claude para el Gobierno, entre otros—, con un historial de incidentes y una cifra de tiempo de actividad de los últimos noventa días. En el momento de escribir este artículo, ese historial muestra una disponibilidad de la API de Claude por encima del 99,5% en ese periodo, una cifra que, aunque alta en términos absolutos, deja margen para varias horas acumuladas de interrupciones a lo largo de tres meses.
El matiz que la cobertura habitual no separa bien: incidente confirmado frente a ruido de foros
Aquí está la distinción que más conviene hacer con cuidado. Por un lado, existen incidentes confirmados por la propia Anthropic en su página de estado y recogidos por medios especializados serios, como el del 3 de septiembre. Por otro lado, existen sitios agregadores automáticos de tipo «¿está caído?» que generan constantemente artículos genéricos basados en picos de búsquedas o menciones en redes sociales, sin verificar contra la fuente oficial, y que pueden sugerir una caída activa en un momento en el que el servicio en realidad funciona con normalidad. Un análisis independiente publicado por una consultora especializada en infraestructura de IA, ajena a Anthropic, ha contabilizado un total de veintiún incidentes distintos en la página de estado de Anthropic entre el 12 de agosto y el 2 de septiembre de 2026, señalando además que el propio día 14 de agosto la página de estado quedó temporalmente inaccesible, sirviendo un certificado de seguridad inválido a quien intentaba comprobar qué estaba pasando. Conviene ser preciso con el origen de este dato: es un recuento y una interpretación de un tercero, no una cifra que Anthropic haya publicado o confirmado como tal, así que merece tratarse como una señal de tendencia a vigilar, no como un hecho cerrado con el mismo peso que un incidente confirmado directamente por la compañía.
Matices antes de sacar conclusiones alarmistas
Una racha de incidentes reportados en la página de estado no equivale automáticamente a un servicio poco fiable en términos absolutos: muchos de esos incidentes pueden ser de corta duración, afectar solo a un modelo o función concreta en lugar de a todo el servicio, o resolverse en minutos sin llegar a interrumpir el trabajo de la mayoría de usuarios. Dicho esto, la combinación de una racha de incidentes documentados y al menos un fallo con impacto amplio y confirmado, como el del 3 de septiembre, es un motivo razonable para que cualquier equipo con procesos críticos construidos sobre la API de Claude revise su propia resiliencia frente a interrupciones del proveedor, independientemente de cuál sea ese proveedor.
Por qué importa hoy
Para cualquier equipo que tenga procesos de negocio dependientes de la API de Claude sin ninguna capa de contingencia, la recomendación práctica más directa es consultar directamente status.claude.com en lugar de fiarse de agregadores de terceros ante cualquier sospecha de caída, implementar reintentos con espera progresiva en el propio código para absorber interrupciones cortas sin que fallen las tareas del usuario, y, para los flujos de trabajo más críticos, valorar una estrategia de conmutación a un modelo o proveedor alternativo cuando la tarea lo permita, en lugar de depender de un único punto de fallo. Ninguna de estas medidas exige abandonar Claude ni dramatizar el problema: son las mismas prácticas de resiliencia que cualquier equipo de ingeniería aplicaría frente a cualquier proveedor externo del que dependa su producto.
Conviene también situar este episodio en un contexto más amplio del sector, no como algo exclusivo de Anthropic: ese mismo 3 de septiembre, tanto OpenAI como la infraestructura de Grok sufrieron sus propias interrupciones, lo que sugiere que buena parte de la industria de la IA generativa comparte cuellos de botella de infraestructura similares —picos de demanda, dependencias de proveedores de nube compartidos, complejidad creciente de los sistemas de enrutamiento entre modelos— más que un problema aislado de un único proveedor. Para quien evalúa qué proveedor de IA usar en un producto crítico, la lección práctica no es necesariamente elegir uno u otro por su historial de incidentes puntual, sino asumir desde el diseño que cualquier proveedor de este tipo de infraestructura, sea cual sea, puede fallar, y construir el propio sistema con esa posibilidad en mente desde el primer día.