5 августа Anthropic зафиксировала повышенные ошибки у Claude Opus 5 и части других моделей. Разбираем, что именно произошло по таймлайну статуса и какие простые меры помогут не «ронять» прод из‑за деградации LLM‑провайдера.
5 августа 2026 года у Anthropic возникли проблемы с доступностью части моделей Claude: на статус‑странице компании появились сообщения о повышенных ошибках (elevated errors) и деградации производительности. Отдельно отмечалась нестабильность Claude Opus 5 — модели, которую многие используют как «тяжёлую артиллерию» для сложных задач и агентных сценариев.
Что произошло: короткий таймлайн
По данным официальной статус‑страницы, ситуация развивалась так:
- 10:05 МСК (07:05 UTC) — Anthropic сообщила, что выявила причину повышенных ошибок на запросах к нескольким моделям (в том числе Mythos 5, Fable 5, Opus 5 и Sonnet 5) и работает над исправлением.
- 12:13 МСК (09:13 UTC) — статус обновили: работа над фиксом продолжается.
- 16:08 МСК (13:08 UTC) — компания объявила, что выкатили исправление и наблюдают восстановление.
- 17:14 МСК (14:14 UTC) — инцидент по «нескольким моделям» отмечен как решённый.
- 16:51–17:34 МСК (13:51–14:34 UTC) — параллельно шёл отдельный инцидент именно по Claude Opus 5: сперва указали, что причина ошибок найдена, затем сообщили о полном восстановлении.
Почему это важно не только разработчикам «на LLM», но и обычному бизнесу
Когда модель используется как часть процесса (например, в Claude Code, автогенерации ответов саппорта, разборе писем, заполнении карточек CRM или проверке pull request’ов), деградация выглядит не как «технологическая новость», а как вполне бытовая проблема:
- агент «не доделывает» задачи из-за ошибок и зависает на середине пайплайна;
- растёт очередь запросов и время ответа для пользователей;
- автоматизация начинает повторно слать запросы, увеличивая нагрузку и счёт;
- команда теряет доверие к инструменту и откатывается на ручной режим.
Что стоит сделать, чтобы следующий подобный сбой прошёл незаметнее
Эти шаги не требуют «сложной архитектуры», но заметно повышают устойчивость.
- Держите план “B” по моделям. Даже если в обычное время вы предпочитаете Opus 5, заранее определите, на какую модель вы готовы временно переключаться для большинства задач (пусть она хуже, но стабильнее).
- Добавьте ретраи с паузой и лимитами. Повтор запроса полезен, но только с экспоненциальной задержкой и верхним пределом попыток — иначе вы сами усиливаете проблему в момент деградации.
- Разделите “важно сейчас” и “можно подождать”. Тяжёлые фоновые задачи (например, пакетная обработка документов) лучше отправлять в очередь и выполнять с пониженным приоритетом, когда провайдер «штормит».
- Подключите проверку статуса провайдера в runbook. Внутреннее правило уровня «если доля ошибок выросла — смотрим статус‑страницу, затем включаем упрощённый режим» экономит часы хаотичных разборов.
- Логируйте не только текст ошибки, но и модель/режим/тайминг. Тогда вы быстро поймёте: деградация общая или задевает конкретную модель/инструмент/регион.
Итог
Инцидент 5 августа показал типичную картину для «агентной» эпохи: сбой провайдера LLM — это уже не редкость, а нормальный риск эксплуатации. Хорошая новость в том, что он лечится дисциплиной: понятными fallback‑сценариями, аккуратными ретраями и простыми правилами переключения режимов.
