Resumen
- Anthropic registró errores elevados en Opus 4.8 y Haiku 4.5 desde 13:37:28Z hasta 15:23:37Z.
- Haiku 4.5 se recuperó antes que Opus 4.8 y antes del cierre de la primera ficha.
- Un incidente independiente de Sonnet 5 abrió a 15:24:05Z, 28 segundos después, y terminó a 16:12:32Z.
- Ambos registros enumeraron claude.ai, Console, API, Claude Code y Cowork.
- No se publicó causa común, usuarios afectados, porcentaje de error, pérdida de datos ni decisión sobre créditos.
La lista de componentes es amplia, pero no cuenta cuántas solicitudes fallaron. Una entrada puede aparecer porque una misma familia de modelos se consume desde varios productos, porque el proveedor aplica una etiqueta común o porque se detectó impacto en cada superficie. Ninguna de esas posibilidades permite reconstruir por sí sola el fallo interno.
Por eso conviene separar dos preguntas. La primera es qué experimentó un cliente que trabajaba con Claude durante esas horas. La segunda es cuántos incidentes técnicos y causas existieron. La cronología admite que la incertidumbre operativa fue casi continua, pero la evidencia pública conserva dos identidades y tres modelos diferentes.
La primera ficha contenía dos velocidades de recuperación
El registro de Opus/Haiku empezó a las 13:37:28Z con impacto menor. Anthropic identificó el problema y comunicó después que Haiku 4.5 ya se había recuperado mientras Opus 4.8 continuaba con errores elevados. La ficha pasó a monitorización a las 15:06:53Z y quedó resuelta a las 15:23:37Z.
La recuperación desigual importa para una aplicación que pueda seleccionar modelos. Algunas tareas habrían podido volver a Haiku después de una prueba controlada, mientras las que dependían de Opus seguían desviadas o en cola. Tratar todos los modelos como una única zona de salud habría ocultado esa posibilidad y también el riesgo restante.
La etiqueta “menor” tampoco cuantifica el alcance. Anthropic no publicó porcentaje de error, número de usuarios, zonas, longitudes de cola ni coste empresarial. Las fichas de estado describen una clasificación del proveedor; no sustituyen la telemetría de cada cliente.
Veintiocho segundos separan las identidades
La ficha de Sonnet 5 comenzó a las 15:24:05Z, fue marcada como identificada a las 15:36:57Z y terminó a las 16:12:32Z. Volvió a enumerar las mismas cinco superficies y mantuvo el impacto menor. Entre la resolución anterior y esta apertura transcurrieron exactamente 28 segundos según la API estructurada.
Para una cola automática, ese intervalo no permite establecer una recuperación estable. Un sistema que liberara trabajo en cuanto la página global volviera a verde podría haber enviado solicitudes a Sonnet justo cuando aparecía la nueva ficha. La experiencia del operador podría sentirse como una sola franja problemática.
La contigüidad no autoriza, sin embargo, a decir que Opus o Haiku provocaron el fallo de Sonnet. Tampoco demuestra que una reparación desplazara el problema. Anthropic creó identificadores separados, asignó modelos distintos y no publicó una causa común. Unirlos borraría información que la fuente sí conserva y añadiría una explicación que la fuente no ofrece.
El impacto comercial depende de los controles del cliente
Una organización que usa Claude en producción puede exigir varias solicitudes sintéticas correctas sobre el modelo, región e interfaz exactos antes de liberar una cola. Puede reabrir el tráfico por etapas, mantener claves de idempotencia, limitar reintentos y conservar otra ruta para tareas que toleren un modelo o proveedor alternativo.
El estado debe seguirse al menos por modelo y superficie. Para cargas sensibles, también conviene distinguir herramientas, longitud de contexto y modalidad interactiva o por lotes. El éxito de una consulta corta en API no prueba que un flujo largo de Claude Code o una tarea en Cowork se haya recuperado.
Estos dos incidentes ocurrieron después del corte temporal de los cuatro registros que BTW ya había cubierto. Constituyen una recurrencia nueva, no una corrección que convierta todos los episodios previos en una sola caída. La repetición sí refuerza el argumento a favor de controles independientes.
Lo que no está publicado limita la conclusión
No hay una causa común, cifra de clientes, tasa de fallos, reparto regional, declaración de pérdida de datos ni tratamiento de SLA. Sin esos datos no se puede estimar disponibilidad contractual, atribuir el problema a capacidad ni calcular un daño agregado.
Lo comprobable es la secuencia: alrededor de una hora y 46 minutos en la primera ficha, 28 segundos de separación y unos 48 minutos en la segunda. Para el proveedor son dos identidades. Para el cliente, la seguridad de reanudar trabajo debe venir de pruebas propias, no de convertir una coincidencia de cinco interfaces en una causa técnica inventada.