Если запрос к Claude API возвращает 529 overloaded_error, первое рабочее предположение должно быть таким: на стороне Anthropic есть перегрузка или дефицит мощности. Это не доказательство сломанного ключа, биллинга, личной квоты или блокировки аккаунта. Ближайшая ловушка — спутать 529 с 429 rate_limit_error. Код 429 относится к rate limit и quota, а 529 относится к capacity.
В первую минуту не меняйте всё подряд. Зафиксируйте текущее состояние Claude Status и время проверки, выполните короткий retry с jitter и жестким лимитом, уменьшите давление на вызывающей стороне, если вы управляете трафиком, и повторите тот же путь: та же модель, endpoint, владелец аутентификации и форма запроса. Если та же трасса снова возвращает 529, сохраняйте тело ошибки и request_id, затем готовьте короткую эскалацию.
Страница статуса остается только датированным сигналом. В ходе этого запуска публичный status API на 2026-04-29 11:02 UTC показывал all systems operational, но лента инцидентов всё еще содержала недавно закрытые elevated-error события за 28 и 29 апреля UTC. Зеленый статус помогает сузить ветку, но не доказывает, что ваш конкретный путь уже восстановился.
Таблица решения за минуту
Сначала прочитайте точный сигнал. Только потом трогайте ключи, план, модель, prompt или provider.
| Точный сигнал | Считать это | Первый шаг | Проверка той же трассы | Остановиться или эскалировать |
|---|---|---|---|---|
529 или overloaded_error | Перегрузка Anthropic | Проверить live status, затем capped retry с jitter | Та же модель, endpoint, auth route и форма запроса | Сохраняется после статуса, retry-бюджета и снижения давления |
429 или rate_limit_error | Лимит или quota | Проверить retry-after, лимиты и текущий credential route | Повторить после окна или исправления route | Headers и Console всё еще показывают исчерпание |
500 или api_error | Серверная ошибка | Проверить статус, сохранить request evidence, retry один раз | Тот же запрос после короткой паузы | Инцидента нет, а та же трасса падает |
504 или timeout_error | Timeout | Сократить длительность, включить streaming или разбить задачу | Та же задача после одного осознанного изменения формы | Длинный запрос всё равно истекает |
| Claude Code показывает повторные 529 | Поверхность Claude Code | После API-смысла перейти в терминальную ветку | Та же сессия и route после cooldown | Симптом держится после статуса и route-check |
Рабочий вывод: 529 сначала означает overload. Не начинайте с key rotation, plan upgrade или случайного переписывания prompt, пока точный ответ не изменился на ветку, где такие действия оправданы.
Что означает 529 в Claude API
Документация Anthropic по API errors определяет HTTP 529 как overloaded_error. В той же таблице отдельно указаны 429 rate_limit_error, 500 api_error и 504 timeout_error. Именно это разделение должно управлять восстановлением.
Главное различие — ownership. Настоящий 529 говорит, что сервис перегружен или находится под capacity pressure. Ваш клиент всё равно должен вести себя аккуратно, но первая интерпретация не должна быть «мой аккаунт исчерпал quota». Настоящий 429 указывает на request rate, acceleration limits, model limits или потолки аккаунта и provider. Код 500 требует серверного error handling и request evidence. Код 504 требует смотреть на длительность, streaming и размер задачи.
Ошибочные исправления появляются, когда команда сжимает все заблокированные запросы в одну категорию. Разработчик видит failure и применяет привычный рецепт: замедлить как при 429, заменить ключ как при auth problem или поменять provider как при доказанной route failure. Эти шаги иногда полезны, но чистый 529 начинается не с них.
request_id нужно сохранить рано. Документация Anthropic говорит, что error response включает request_id, а response headers могут содержать request-id. Когда 529 повторяется, этот идентификатор ценнее длинного рассказа о локальных экспериментах.
Безопасный цикл восстановления
Хороший обработчик 529 должен быть скучным: status check, короткий retry, снижение давления, проверка той же трассы, затем stop или escalation. Цель не в том, чтобы заставить client «стараться сильнее». Цель в том, чтобы не усиливать перегрузку и сохранить доказательства.
Начинайте с live status. Запишите результат и время в UTC или в вашей операционной зоне. Если есть active incident, не меняйте одновременно model, endpoint, auth и request size. Удерживайте форму failing request, сделайте паузу и повторите после улучшения статуса.
Если статус зеленый или инцидент не опубликован, используйте bounded retry budget. Практичный вариант включает exponential backoff, jitter, лимит попыток или лимит total elapsed time. Повторять стоит только работу, которую безопасно повторять. Read-запросы и generation attempts с caller-side дедупликацией проще, чем side-effecting workflows.
Затем уменьшайте caller pressure. Снизьте concurrency, остановите non-urgent batch jobs, включите queue backpressure или переведите второстепенную функцию в degraded mode. Это не признание вашей вины. Просто агрессивный retry во время provider overload добавляет нагрузку туда, где уже тесно.
Последний шаг — same-path verification. Сохраняйте model, route, auth owner, endpoint, region или proxy path и request shape стабильными, если только один из них не является намеренным проверочным изменением. Если вы поменяли пять переменных и следующий запрос прошел, вы уже не знаете, восстановилась ли перегрузка или запрос просто стал легче.
Производственные защиты при повторном 529
Ручной порядок нужен человеку, но сервис должен автоматизировать ту же дисциплину. Используйте retry budget, а не infinite retry. Ограничивайте attempts, total time и момент, после которого результат уже не ценен для пользователя. Chat turn, background batch и transactional workflow не должны делить одну политику.
Добавляйте jitter. Фиксированные интервалы синхронизируют запросы многих клиентов, а перегруженному API нужна обратная форма трафика. Jitter размазывает пики и делает восстановление менее резким.
Поставьте circuit breaker на повторные 529. Если доля ошибок выше вашего порога, откройте breaker, ставьте non-urgent work в очередь, деградируйте optional features и показывайте пользователю ясное сообщение без ложных гарантий. Закрывайте breaker только после малого same-path probe.
Разделяйте pressure reduction и route change. Pressure reduction означает меньше concurrency, меньшие batch windows или deferred jobs. Route change означает другую модель, endpoint, provider или auth owner. Route change может быть бизнес-решением, но он меняет evidence trail и поведение продукта.
Наблюдаемость держите простой: error type, HTTP status, model, endpoint, auth route, request size class, retry count, final outcome и request_id. Эти поля отвечают на главный вопрос во время всплеска 529: восстановилась ли та же трасса после бюджета или это всё еще provider overload?
Если 529 виден в Claude Code
Сначала примените API-смысл 529 overloaded_error. Если сообщение видно в Claude Code, терминальная поверхность добавляет свои правила, но не превращает 529 в billing issue.
Документация Claude Code описывает повторный 529 как временную capacity problem across users, говорит, что Claude Code уже повторял запрос до показа сообщения, и отделяет это от usage limit или quota wording. Поэтому терминальный сценарий лучше отправлять в руководство по Claude Code overloaded error, а не в общую страницу про billing.
Если terminal line смешивает 500, 529, 429, temporary limiting или route confusion, нужен более широкий маршрутизатор Claude Code 500 vs 529 vs rate limit. Он предназначен для моментов, когда терминал сжимает несколько веток в одну стрессовую строку.
API-командам стоит помнить о route ownership. Shell environment variable, proxy или provider wrapper могут провести запрос не тем путем, который вы хотели проверить. Если 529 появляется только на одном wrapper path, сравните тот же запрос на ожидаемой трассе, прежде чем объявлять весь Claude API недоступным.
Пакет для эскалации
Эскалация начинается после маленького упорядоченного recovery path. Значит, текущий status записан, retry был bounded, давление снижено, где возможно, и та же трасса продолжает возвращать 529.
Отправляйте компактный пакет:
- точный HTTP status и error type, включая
529 overloaded_error - полное тело ошибки и
request_id, если он есть - model, endpoint, SDK или gateway route, auth owner
- timestamped Claude Status result и релевантный recent incident note
- retry count, backoff window и использование jitter
- concurrency или batch pressure в момент failure
- minimal reproduction request shape без секретов
- business impact в одном предложении: blocked production job, degraded user flow или delayed batch
Короткость важна. Support не нужен полный список локальных экспериментов. Нужны доказательства, что ветка действительно 529, client не создал retry storm и та же трасса остается failing после разумных controls.
Часто задаваемые вопросы
Claude API 529 то же самое, что 429?
Нет. Anthropic определяет 529 как overloaded_error, а 429 как rate_limit_error. Настоящий 529 — overload first. Настоящий 429 — rate-limit branch.
529 означает, что аккаунт или billing сломан?
Не как первое объяснение. Чистый 529 overloaded_error указывает на capacity overload. Billing, key или quota становятся релевантны, только если error type меняется, route не тот, который ожидался, или есть отдельный сигнал.
Что делать, если Claude Status зеленый, но 529 остается?
Считайте зеленый статус timestamped signal, а не доказательством восстановления точной трассы. Сделайте короткий same-path retry с jitter, снизьте давление и эскалируйте с request_id, если та же model, route, auth path и request shape продолжают падать.
Сколько retry безопасно?
Нужен budget, а не универсальное число. Ограничьте attempts или elapsed time, добавьте jitter и повторяйте только safe-to-repeat work. Если ценность запроса быстро истекает, retry budget тоже должен быть коротким.
Нужно ли менять model или provider при 529?
Только как явное route decision. Если workload терпит другую модель или route, переключение может сохранить non-critical flow. Но как первый диагностический шаг оно скрывает, восстановился ли original path.
Что отправить в Anthropic support?
Отправьте error body, request_id, model, endpoint или gateway route, auth owner, status timestamp, retry timeline, pressure level и minimal reproduction. Удалите секреты и оставьте ветку очевидной.
Рабочее правило
Claude API 529 — overload-first branch. Проверяйте live status с timestamp, retry делайте только с capped jittered budget, снижайте caller pressure, проверяйте ту же трассу и эскалируйте только после повторного 529 overloaded_error с чистыми доказательствами.