Asistente de IA caído, proyecto bloqueado: el 16 de agosto y lo que queda en tu poder

El 16 de agosto de 2026, Claude Code estuvo fuera de servicio cuarenta y dos minutos. Para quien encarga software a un equipo de agentes, la pregunta posterior vale más que el incidente: según dónde vivan tus documentos y tu código, una caída de un proveedor te quita una noche o todo el trabajo.

Asistente de IA caído, proyecto bloqueado: el 16 de agosto de 2026 a las 21h58 UTC, Anthropic confirmó un incidente que afectaba a Claude.ai, Claude Code y Claude Cowork, con una degradación comunicada a las 22h07 y un restablecimiento completo a las 22h40 (BleepingComputer, 16 de agosto de 2026). Cuarenta y dos minutos durante los que nadie conseguía que se escribiera una línea.

Lo que ocurrió el 16 de agosto

El incidente empezó a las 21h58 UTC. Nueve minutos después, el proveedor comunicaba problemas de autenticación y después un rendimiento degradado; el restablecimiento completo llegó a las 22h40. La consola de administración y el acceso mediante clave seguían operativos según el mismo registro, sin que el artículo explicara por qué. Cuarenta y dos minutos una noche de agosto causan poco daño. La misma interrupción un martes de entrega, o tres horas en lugar de cuarenta minutos, plantea otra pregunta, y esa pregunta no es sobre la fiabilidad del proveedor, que nadie controla, sino sobre lo que te queda a mano cuando cae.

Al día siguiente, GitHub caía siete horas

El 17 de agosto de 2026, GitHub estuvo indisponible 7 horas y 47 minutos: el sitio, la autenticación, las API, las tareas automatizadas, las incidencias y Copilot. El proveedor publicó su análisis tres días después y descartó cualquier cambio de código o configuración: la causa era la capacidad, bajo una carga que había hecho pasar las contribuciones mensuales de 1 400 millones en abril a 2 900 millones. Dos caídas en dos días, en dos proveedores independientes, sobre los dos componentes de los que depende gran parte de los proyectos de software del mundo. Un empresario no tiene control sobre esos incidentes. Sí lo tiene sobre dónde viven sus archivos.

Lo que pierdes depende de dónde viva tu proyecto

Compara dos situaciones. Construyes en una plataforma en línea que aloja el editor, el código, la base de datos y la dirección pública: cuando cae el proveedor, ya no puedes trabajar, ni releer lo que escribiste ayer, ni mostrar el resultado a un socio, y tu aplicación en servicio cae con él. Trabajas en una aplicación instalada en tu Mac: el asistente calla, así que ya no se escribe ninguna línea de código, pero el documento de requisitos validado, la división en etapas y el historial de versiones siguen siendo legibles y modificables en tu disco. En el primer caso, la caída te quita la obra. En el segundo, te quita al trabajador, y puedes dedicar la noche a releer lo que ibas a encargar construir.

Lo que Maestro tampoco puede hacer

Ninguna herramienta fabrica texto sin un modelo. Maestro no tiene motor propio: dirige Claude Code, Codex, Cursor o Mistral Vibe, y cuando cae el proveedor elegido, la construcción también se detiene. En este terreno, una herramienta alojada conserva incluso una ventaja real. Tu aplicación en línea sigue atendiendo a tus clientes si la caída solo afecta al editor, mientras un proyecto en tu Mac espera a que alguien lo despliegue en algún lugar, y esa etapa sigue a tu cargo. La diferencia está en el material que posees, no en la disponibilidad del motor que lo produjo.

Cambiar de asistente sin cambiar de proyecto

Maestro permite elegir entre cuatro asistentes y cambiarlos en mitad de una conversación, con una suscripción o una clave guardada en el Llavero de macOS (tus proyectos no salen de tu equipo). La noche del 16 de agosto, la maniobra consistía en pasar a otro proveedor y retomar la etapa en curso, porque el brief, el documento de requisitos y la división no dependen de ninguno: son documentos en francés, no configuraciones propias de un modelo. Ese es el razonamiento que seguimos para una herramienta que pierde su motor de un día para otro. El criterio de elección depende menos de la calidad del modelo del momento que de la facilidad de cambiarlo sin perder nada.

Durante la caída, lo único que hacer

Abre la carpeta de tu proyecto y mira qué hay sin conexión: el brief, el documento de requisitos, la división en etapas, el código y el historial de versiones. Lo que puedas leer sin conexión es lo que te quedará el día de una caída larga, y la lista se hace en diez minutos. Si sale vacía porque todo vive en un proveedor, pídele hoy por escrito cómo sacar tu trabajo y guarda la respuesta con tus contratos, como describimos al hablar de qué ocurre con una aplicación cuando desaparece la herramienta. Un corte de cuarenta minutos cuesta una noche: es el momento más barato para descubrir lo que no podrías recuperar.