Resumen
- Anthropic calificó como crítica la incidencia
q2kg8n613kr3; claude.ai, la API de Claude, Claude Code y Claude Cowork pasaron inicialmente de operativos a interrupción grave. - El balance posterior delimitó tasas de error elevadas entre las 19:45 y las 21:26 UTC del 29 de julio: 101 minutos de síntomas medidos.
- La ficha pública estuvo abierta desde las 19:49:45 hasta las 22:36:20 UTC, un ciclo de investigación y verificación cercano a 171 minutos.
- A las 21:38 la mayoría de los modelos se recuperaba, aunque seguían elevadas las solicitudes y la latencia; las cuatro superficies volvieron a operativas al entrar en monitorización a las 22:20.
- Anthropic no comunicó causa raíz, códigos de error, número o porcentaje de solicitudes fallidas, clientes, regiones, mitigación ni revisión posterior.
- GitHub publicó una incidencia simultánea sobre proveedores externos de modelos, pero no identificó a Anthropic; la coincidencia horaria no demuestra relación causal.
Sin denominador, «todos los modelos» describe alcance y no intensidad
La frase más llamativa de la página de Anthropic es “todos los modelos”. Establece que el problema no quedó confinado a una sola familia Claude. El primer cambio estructurado también incluyó cuatro puertas de entrada: el sitio claude.ai, la API, Claude Code y Cowork. Para una empresa que había distribuido tareas entre modelos o interfaces, ese perímetro reduce la utilidad de un simple cambio interno dentro del mismo proveedor.
Pero el alcance horizontal no revela la profundidad. El registro no indica cuántas solicitudes entraron durante la ventana, cuántas fallaron en el primer intento, cuántas se completaron tras un reintento ni cuántas terminaron definitivamente en error. Tampoco separa organizaciones, países o tipos de carga.
Por eso la etiqueta crítica no puede convertirse en un porcentaje. Sirve para priorizar una respuesta del proveedor, no para calcular disponibilidad contractual o pérdidas. Tampoco autoriza a describir una caída total: las actualizaciones hablan de tasas elevadas, recuperación de la mayoría y después de todos los modelos, no de que cada petición fuera imposible.
Cuatro productos cambiaron juntos, aunque la capa averiada sigue oculta
Al abrir la incidencia, Anthropic movió claude.ai, la API, Claude Code y Cowork de operativo a interrupción grave. A las 20:33 UTC dijo haber identificado un problema que provocaba errores elevados en varios modelos. A las 21:38 señaló recuperación en la mayoría, mientras continuaban elevadas las solicitudes y la latencia; las cuatro superficies bajaron entonces a interrupción parcial.
A las 22:20 volvieron juntas a estado operativo y comenzó la monitorización. La resolución se publicó 16 minutos después. Este movimiento coordinado muestra un dominio operativo compartido: el problema podía ser visible tanto para una integración directa como para herramientas de trabajo construidas sobre Claude.
No localiza el origen. Un servicio común de inferencia, una capa de enrutamiento, una dependencia, un despliegue o la propia forma de agrupar componentes en la página de estado podrían producir transiciones idénticas. Anthropic no nombró ninguna de esas posibilidades. El patrón permite hablar de radio de impacto, no de causa raíz.
Tampoco prueba un defecto del modelo. Una llamada puede fallar antes de la inferencia, durante el flujo de respuesta o en la orquestación que rodea a una herramienta. Code y Cowork añaden sesión, ejecución y estado por encima de la respuesta del modelo. No hay evidencia publicada de pesos dañados, respuestas corruptas, pérdida de datos o fallo de controles de seguridad.
Una operación de negocio puede generar varias solicitudes técnicas
La documentación ordinaria de Anthropic clasifica distintos errores de API. Explica que un 500 representa un error interno y un 529 una sobrecarga temporal. Los SDK oficiales reintentan por defecto dos veces ciertos fallos transitorios —conexión, límites y errores 5xx— con espera exponencial.
Esos datos no diagnostican esta incidencia. La ficha no comunicó códigos HTTP ni dijo que hubiera sobrecarga. Sin embargo, ayudan a entender la medición que falta. Una acción del usuario puede producir un primer intento fallido y un segundo satisfactorio. El cliente percibe lentitud, mientras el proveedor observa dos solicitudes y una aplicación quizá registra cero errores terminales.
También puede ocurrir lo contrario: muchos reintentos simultáneos elevan el tráfico durante una recuperación. La mención de solicitudes y latencia elevadas a las 21:38 no distingue demanda original de intentos repetidos. Afirmar que los reintentos causaron la situación sería especulativo; ignorarlos dejaría incompleto el denominador.
Una telemetría útil separaría operaciones de negocio, intentos totales, reintentos y resultados terminales. Los identificadores de solicitud que Anthropic documenta permiten conservar una cadena verificable para soporte. Sin esa cadena, el color global de la página no explica qué pasó a una tarea concreta.
Los 101 minutos y los 171 minutos responden a preguntas distintas
Anthropic abrió el registro a las 19:49:45 UTC. Más tarde fijó el inicio real de las tasas elevadas en las 19:45 y su final en las 21:26. Es una ventana de síntomas de 101 minutos que empieza antes de que la página exista.
El expediente no se cerró hasta las 22:36:20, aproximadamente 171 minutos después de su apertura. Ese periodo incluye investigación, identificación, recuperación parcial, observación y confirmación. No debe presentarse entero como tiempo de errores elevados, porque contradice el límite posterior del proveedor.
Quedarse solo con 101 minutos tampoco describe la decisión de una empresa cliente. Entre las 21:26 y el inicio de la monitorización había que comprobar que la mejora se mantenía. Entre las 22:20 y la resolución todavía existía un intervalo explícito de vigilancia. Una cola de trabajos no tiene por qué liberarse en cuanto termina retrospectivamente el síntoma.
La recuperación debe medirse donde termina la tarea
Una organización puede usar la página verde como señal inicial y no como autorización automática. Primero prueba un número pequeño de solicitudes con el mismo modelo, tamaño de contexto, streaming y herramientas de producción. Después abre tráfico por etapas y vigila latencia, errores terminales, antigüedad de la cola y tasa de finalización del proceso de negocio.
El ámbito de cuatro superficies exige indicadores separados. Una solicitud breve a la API puede funcionar mientras una sesión larga de Claude Code o un flujo Cowork sigue inestable. Del mismo modo, una interfaz puede sufrir degradación aunque una integración directa continúe operativa. El control debe imitar la carga real.
Los reintentos necesitan límites e idempotencia. Si una respuesta se pierde después de producir un efecto, repetir sin control puede duplicar acciones. Un plan de contingencia también debe decidir qué trabajos toleran otro modelo o proveedor: cambiar puede alterar calidad, precio, ventana de contexto, herramientas y tratamiento de datos.
La coincidencia con GitHub no identifica al proveedor
GitHub abrió a las 20:07 UTC una incidencia de Copilot sobre proveedores de modelos. Comunicó errores mayores en peticiones a proveedores específicos o externos y posibles fallos o degradación para algunos usuarios. A las 21:51 indicó que el proveedor externo había resuelto el problema y que el tráfico de Copilot se había recuperado.
El reloj coincide parcialmente con Anthropic, pero GitHub no publicó nombre de proveedor, lista de modelos ni causa. Un producto puede depender de más de un proveedor. Dos plataformas también pueden sufrir incidentes separados durante el mismo intervalo. La correlación temporal no permite escribir que Anthropic causó la degradación de Copilot.
El registro de GitHub sirve como frontera editorial: demuestra cómo una dependencia de modelo puede aparecer en una plataforma aguas abajo, pero no completa la identidad de esa dependencia. Una cadena pública más transparente debería nombrar al proveedor o aportar otro mecanismo de correlación.
El informe posterior debe añadir tasa, distribución y acción correctiva
La página de Claude sí deja información valiosa. Identifica un nivel crítico, una cobertura multi-modelo, cuatro superficies y una transición ordenada de interrupción grave a parcial, operativa, monitorización y resolución. Conserva además dos relojes que impiden exagerar la duración del síntoma.
Lo que falta determina la evaluación de resiliencia. Un informe posterior debería publicar tasa máxima y media de error terminal, volumen de solicitudes, resultado antes y después de reintentos, regiones y organizaciones afectadas, y diferencias entre API, interfaz, Code y Cowork. También debería identificar la capa que falló, la mitigación aplicada y el control que reduce la recurrencia.
Hasta entonces, la conclusión responsable es limitada y material a la vez. Claude sufrió una incidencia crítica y transversal con 101 minutos de errores observados. La respuesta pública necesitó cerca de 171 minutos para llegar a resolución. Sabemos dónde apareció y cuándo se recuperó; no sabemos cuántas operaciones se perdieron ni por qué. Ese denominador ausente es el principal riesgo informativo.