El 27 de julio Claude Opus 5 registró un pico de errores de inferencia en todos sus canales: API, Claude Code y Claude Cowork. Anthropic abrió el incidente a las 11:27 UTC y lo cerró a las 12:30 UTC, confirmando el retorno a los niveles normales de funcionamiento.

Para quien usa Opus 5 en producción, una hora de errores intermitentes no es un detalle. Un agente que trabaja de forma autónoma en decenas de llamadas secuenciales u orquestadas se detiene a mitad del task, deja estados inconsistentes y produce resultados parciales que alguien tiene que limpiar a mano. Los frontier models son la dependencia más frágil del stack: cuando fallan, la única opción de contingencia de la herramienta que has construido es esperar.

Tres días antes contábamos la llegada de Opus 5 como modelo predeterminado en los planes enterprise de Anthropic, presentado para duplicar el rendimiento al mismo costo. Un incidente operativo de este tipo, resuelto rápidamente, es normal para un servicio cloud. El punto es otro: quién automatiza procesos en estos modelos debe tratar su disponibilidad como una variable aleatoria, con monitoreos activos en las tasas de error y lógica de reintentos, sin dar nada por sentado.

El playbook correcto para gestionar esta falibilidad ya existe y es el control de calidad cuando la IA hace mucho trabajo: muestrear los outputs, interceptar problemas temprano y no confiar ciegamente en la respuesta del modelo.

En detalle

La página de estado de Anthropic describe el incidente de forma concisa: el pico de errores afectó a claude.ai, la API, Claude Code y Claude Cowork en bloque. Fue un problema sistémico que involucró el frontier model en el momento en que procesaba las solicitudes, no una degradación selectiva de un endpoint menor.

No conocemos la causa técnica del bug. Anthropic no proporcionó detalles en el post-mortem, y la página de estado se limita a confirmar la resolución. El hilo en Hacker News (101 puntos, 73 comentarios) recopila reportes de usuarios que vieron fallar llamadas API repetidamente, con errores intermitentes que dificultaban entender si el problema estaba en su propio código o en el servicio upstream. Este es un patrón clásico de los incidentes en cloud: el consumidor pierde tiempo debuggeando su propia integración antes de darse cuenta de que la plataforma está degradada.

El contexto operativo importa. Opus 5 se convirtió en pocos días en el modelo predeterminado para muchos workflows agentivos, llevando a Anthropic a reducir el 80% del system prompt de Claude Code porque el modelo necesita menos instrucciones defensivas. Cuando un modelo pasa de novedad a infraestructura de producción en tan poco tiempo, la tolerancia a sus defectos cae drásticamente. Un equipo que migró sus agentes a Opus 5 la semana pasada se encuentra hoy teniendo que agregar capas de resiliencia que no había previsto.

La implicación práctica es construir sistemas que no se rompan cuando el modelo falla, sin abandonar los frontier models. Esto significa monitorear las tasas de error de las APIs con umbrales de alerta, tener reintentos con backoff exponencial para errores transitorios, y prever un mecanismo de fallback a un modelo secundario para tareas no bloqueantes. También significa registrar cada output para poder reconstruir qué funcionó bien y qué quedó incompleto después de un fallo a mitad de chain.

El límite de lo que sabemos es claro: el incidente duró una hora y no hay indicaciones de corrupción silenciosa de resultados. Los frontier models tienen una fragilidad operativa comparable a una base de datos gestionada, con un año de vida en el escenario operativo frente a los décadas de hardening de una RDS. Quién construye sobre ellos debe tener en cuenta la curva de madurez.