Если Claude API возвращает HTTP 529 с типом overloaded_error, сначала считайте это веткой перегрузки Anthropic, а не вашим лимитом 429. Откройте Claude Status, остановите плотный цикл повторов, уменьшите параллельные вызовы и повторяйте запрос только с ограниченным экспоненциальным backoff и jitter. Во время проверки не меняйте одновременно endpoint, модель, workspace, ключ, прокси и библиотеку клиента; иначе владелец сбоя станет неразличимым.
| Сигнал ответа | Вероятный владелец | Первое действие | Когда остановиться |
|---|---|---|---|
HTTP 529 + overloaded_error | Емкость Anthropic | Проверить статус, замедлить повторы, поставить новую работу в очередь | После исчерпания бюджета повторов |
HTTP 429 + rate_limit_error | Лимит вашей организации или workspace | Читать headers лимитов и снижать давление | До reset или изменения лимита |
| HTTP 500 или 504 | Внутренняя ошибка или timeout обработки | Проверить статус, отправить малый контрольный запрос | Эскалировать при устойчивом повторении |
| Claude Code показывает repeated 529 | Claude Code уже выполнил автоматические повторы | Проверить статус, подождать, временно сменить модель | Не считать это расходом quota |
Правило ремонта узкое: 529 можно повторять, но медленно, с потолком и снижением давления. Немедленный цикл, ротация ключей или сценарий для 429 обычно ухудшают диагностику.
529 является веткой перегрузки, а не веткой quota
В справочнике ошибок Anthropic ветка 529 отделена от лимитов организации. 429 означает rate limit, 500 означает внутреннюю ошибку API, 504 означает timeout, а 529 означает временную перегрузку API. Поэтому первый шаг другой. Для 429 нужно читать лимитные headers и ждать reset. Для 529 нужно проверить состояние сервиса, удержать один стабильный путь запроса и ограничить повторные попытки.
Статусная страница важна не только как красный или зеленый индикатор. На 2026-04-30T13:42:00+08:00 публичный Statuspage API показывал компонент Claude API как operational, но в истории того же дня и предыдущего дня были инциденты. Для перегрузки это нормальная картина: общий компонент может уже восстановиться, а конкретная модель, региональный путь, gateway или автоматизация могут еще давать короткие окна 529.
Сохраните полный response body, HTTP status, error type, request_id, модель, endpoint, workspace, маршрут провайдера и локальное время. Если позже запрос пройдет, эти данные покажут, что помогло: ожидание, снижение concurrency, меньший payload или смена маршрута.
Первые пять минут: стабилизируйте путь запроса
Начните с фактов. Скопируйте тело ответа и headers, запишите request id, модель, endpoint, workspace, provider route, размер входа, уровень concurrency и timestamp с timezone. Откройте Claude Status и проверьте, затронут ли Claude API, Claude Code или отдельная модель. Если между вашим приложением и Anthropic есть Zapier, Make, прокси или hosted agent, зафиксируйте этот слой отдельно.
Затем отправьте маленький запрос по тому же пути. Оставьте тот же API key, organization, модель, endpoint и client library. Уменьшите prompt до короткого известного запроса и ограничьте max output. Если малый запрос проходит, а production burst падает, ремонт находится в shaping трафика. Если малый запрос тоже возвращает 529, больше похоже на емкость или давление маршрута.
Нужен stop rule. Для foreground запроса обычно достаточно трех-пяти попыток с backoff и jitter. Для batch работы можно ждать дольше, но job должен вернуться в durable queue, а не занимать worker и продолжать бить endpoint. После бюджета повторов покажите временное состояние capacity и сохраните evidence.
Повторяйте медленно и с жестким потолком
529 retryable только в том смысле, что тот же запрос может пройти после восстановления емкости. Это не приглашение делать больше немедленных попыток. Политика должна распределять нагрузку, защищать worker и не скрывать owner ошибки.
hljs tsfunction classifyClaude(status: number, type?: string) {
if (status === 529 || type === "overloaded_error") return "slow_retry";
if (status === 429 || type === "rate_limit_error") return "wait_for_limit";
if (status === 500 || status === 504) return "server_or_timeout";
return "do_not_retry_blindly";
}
Главное — потолок. Пользовательский запрос может сделать несколько попыток и вернуть временную ошибку. Batch worker может сохранить job, next retry time и attempt count. Streaming UI должен сказать, что путь модели временно перегружен, а не зависать без объяснения.
Не смешивайте 529 с ремонтом 429. Документация по rate limits говорит, что 429 может иметь retry-after и rate-limit headers. При 529 reset вашего аккаунта обычно не является главным сигналом; расписание строится на вашем backoff и состоянии сервиса.
Снижайте давление без потери диагностики
Снижение давления полезно только тогда, когда оно не ломает эксперимент. Уменьшите worker concurrency, отключите speculative fan-out, поставьте новые задачи в очередь, сократите context и убедитесь, что SDK и внешний wrapper не создают два агрессивных retry слоя. Если SDK уже повторяет transient failures, внешний код должен иметь еще более строгий предел.
Для долгих задач используйте streaming или asynchronous queue. Streaming снижает путаницу с idle timeout, а очередь не дает короткому capacity spike остановить все foreground запросы. Prompt caching помогает с account-side token pressure и burst behavior, особенно для 429, но не гарантирует исчезновение 529.
Смена модели — это continuity tactic. Она допустима, когда product contract разрешает другой уровень качества. Если ответ обязан прийти от исходной модели, правильнее ждать и повторить позже, чем незаметно менять модель и выдавать другой результат.
Перед эскалацией проверьте тот же путь
Самая чистая проверка — same-path small-load test. Оставьте key, organization, workspace, endpoint, model, client library, proxy и network path неизменными. Сначала отправьте маленький запрос, затем production форму с меньшей concurrency. Пара результатов отделяет provider pressure от размера запроса, burst pattern и wrapper layer.
Ведите отдельный overload log. В нем должны быть request id, status, error type, model, endpoint, workspace, provider route, attempt, delay, input token estimate, output cap и final disposition. В документации Anthropic request id указан как полезный идентификатор для поддержки. Эскалация с request ids, timestamps, status snapshot и same-path reproduction намного сильнее, чем общий скриншот ошибки.
Эскалируйте при устойчивом, широком и воспроизводимом симптоме. Если падает только Zapier, Make или proxy, а прямой вызов проходит, начинайте с этой платформы. Если прямые маленькие запросы тоже получают 529 при чистой статусной странице, отправляйте support evidence. Если есть активный инцидент, сохраняйте доказательства и дайте очереди дождаться восстановления.
Claude Code, gateways и automation platforms
Claude Code имеет собственное поведение. Его reference говорит, что server errors, overloaded responses, timeouts, temporary throttles и dropped connections автоматически повторяются до показа ошибки. Поэтому repeated 529 в терминале уже прошел несколько попыток. Следующий шаг — status, ожидание или временная смена модели для продолжения работы, а не вывод о том, что исчерпан Console quota.
Gateway и automation продукты добавляют новую ветку. Zapier, Make, proxy или hosted agent могут replay, delay или transform error. Разделяйте upstream Anthropic status и wrapper status. Если платформа показывает только generic failure, добавьте logging исходного HTTP status и Anthropic error type. Без этого 529, 429, timeout и wrapper quota выглядят одинаково.
Устойчивый production pattern — небольшая state machine: classify error, check service status, retry with cap, reduce pressure, queue deferred work, preserve request evidence. Это надежнее, чем менять ключи, сразу крутить loop или молча снижать качество модели.
Production checklist
| Контроль | Зачем при 529 | Реализация |
|---|---|---|
| Error classifier | Не смешивает 529, 429, 500 и 504 | Проверять HTTP status и error type |
| Capped jittered retry | Не создает retry storm | Разные бюджеты для foreground и batch |
| Concurrency limits | Worker не просыпаются одновременно | Лимит по model, endpoint и provider route |
| Durable queue | Защищает пользовательский путь | Хранить next retry time и attempt |
| Same-path probe | Показывает, проходит ли малый запрос | Не менять key, workspace, model и route |
| Request id logging | Делает support actionable | Сохранять body field и header |
| Status observation | Отделяет incident от local pressure | Записывать checked time и component |
Часто задаваемые вопросы
Claude API 529 расходует quota?
Сначала обрабатывайте 529 как capacity branch, а не как quota branch. Claude Code reference прямо отделяет repeated 529 от пользовательского usage limit. Для direct API все равно проверяйте Billing и Usage отдельно, но не применяйте 429 playbook к overloaded_error.
Можно ли сразу повторить overloaded_error?
Нет. Нужны backoff, jitter и жесткий ceiling. Немедленные повторы увеличивают нагрузку именно в тот момент, когда сервис просит клиентов замедлиться.
Смена модели является исправлением?
Это способ продолжить работу. Он подходит только там, где допустим другой model quality. Если требуется исходная модель, ждите и повторяйте позже.
Какие данные нужны support?
Request ids, timestamps с timezone, model, endpoint, workspace, provider route, status-page state, retry schedule и результат одного маленького same-path запроса.
