Claude vuelve a caer: errores en varios modelos a la vez

La madrugada del lunes 24 de agosto Claude volvió a dar errores, y no en un modelo suelto: Notebookcheck informa de otra caída del servicio con fallos que alcanzaron a varios modelos a la vez. Ese matiz es el que importa si tienes la API en producción. Una incidencia localizada se esquiva cambiando de modelo dentro de la misma familia, pero una que toca a varios deja sin efecto el plan B que casi todo el mundo tiene escrito en su código.

La palabra que más pesa en la noticia no es caída, sino otra. Los cortes en las plataformas de inferencia han dejado de ser un evento excepcional para convertirse en un parámetro de diseño, igual que la latencia o el coste por millón de tokens. Anthropic publica el estado de sus servicios en status.anthropic.com, pero esa página cuenta lo que ya está roto, no lo que tu sistema hará cuando ocurra.

Qué se rompe de verdad

En la interfaz de chat una caída se traduce en un mensaje de error y un reintento manual. En un sistema automatizado el efecto es otro. Los agentes que corren sin supervisión, los hooks de Claude Code que lanzan llamadas al modelo en PostToolUse, los subagentes disparados en paralelo y los servidores MCP que hacen de puente hacia herramientas externas comparten el mismo punto único de fallo. Cuando la API devuelve 429 o 529 de forma sostenida, el resultado rara vez es un error limpio: son reintentos que reenvían el contexto entero, presupuestos de tokens que se evaporan y tareas a medias que dejan ficheros escritos, ramas abiertas y ningún commit.

Por qué el fallback entre modelos se queda corto

El patrón más extendido encadena modelos por coste: Opus 4.8 para lo difícil, Sonnet 4.6 para el grueso del trabajo y Haiku 4.5 para lo mecánico. Sirve contra la saturación puntual de un modelo concreto y no sirve de nada cuando el problema está por debajo, en la capa compartida de enrutado o de servicio. Un fallback que solo cambia el identificador del modelo dentro del mismo proveedor es, en la práctica, un fallback dentro del mismo dominio de fallo. Si el incidente alcanza a varios modelos a la vez, como describe la nota, esa cadena entera baja junta.

Para quién es esto relevante

Sobre todo para tres perfiles. El primero, equipos que han metido Claude Code en CI y ejecutan agentes en pipelines desatendidos, donde un fallo a las tres de la mañana no lo ve nadie hasta que revienta el build. El segundo, productos con el modelo en el camino crítico de una funcionalidad de cara al usuario. El tercero, cualquiera que haya montado automatizaciones internas sobre servidores MCP y las trate como infraestructura sin haberles puesto todavía las defensas de la infraestructura.

Lista corta para revisar esta semana

1. Reintentos con backoff exponencial y jitter, con número máximo de intentos y tiempo total acotado. Reintentar sin freno convierte diez minutos de caída en una factura.
2. Idempotencia en las herramientas. Si el agente repite una llamada MCP que crea un registro o envía un correo, la segunda ejecución tiene que ser inocua.
3. Circuit breaker por proveedor. Tras varios fallos consecutivos, dejar de insistir y encolar en lugar de seguir golpeando la misma puerta.
4. Separar lo interactivo de lo diferido. El trabajo por lotes puede esperar en una cola, la petición de un usuario no.
5. Degradación explícita en el producto. Un mensaje claro de que el modelo no está disponible es mejor que un spinner eterno.
6. Métricas propias de tasa de error y latencia. La página de estado del proveedor suele ir por detrás de lo que tu gráfica ya está enseñando.

Nuestra lectura

Nada de esto es nuevo para quien viene de integrar pasarelas de pago o proveedores de mensajería, y ahí está el fondo del asunto: el modelo ya es una dependencia crítica más y merece el mismo trato defensivo. Después de episodios parecidos, lo sensato es escribir el camino degradado ahora, con el servicio funcionando, y no improvisarlo durante la siguiente incidencia.