Ошибка 529 в Claude: что значит и что делать прямо сейчас

Ошибка 529 значит, что серверы Anthropic в эту секунду не справляются с потоком запросов и временно отклоняют новые. Причина не в вашем интернете, не в аккаунте и не в формулировке сообщения. В чате или Claude Code обычно хватает паузы и повтора, в API нужен ретрай с задержкой.

Разработчикам знакома другая картина: в тестах всё работало, потом пришёл трафик, и в логах посыпались 529 Overloaded и редкие 500. Часть этих ошибок чините вы. Часть лежит на стороне Anthropic, и ваша задача лишь грамотно повторить запрос. Весь фокус в том, чтобы понимать, что есть что: бесконечный ретрай 400 просто жжёт деньги и поднимает вас в три ночи впустую. Этот гид раскладывает каждую ошибку Claude API по нужной полке и даёт рабочий код.

Что значит ошибка 529 Overloaded?

529 означает, что серверы Anthropic временно перегружены и не могут принять ваш запрос прямо сейчас. Дело не в ключе, не в квоте и не в промпте: дело в суммарной нагрузке на платформу в эту конкретную секунду. По документации Anthropic 529 называется статусом «Overloaded», и правильная реакция: отступить и повторить чуть позже.

Это самая частая ошибка на «голом» Anthropic API. Всплески приходятся на часы пик и на первые дни после релиза новой модели. Если 529 повторяется у вас вечером по Москве, когда в США рабочий день, это согласуется с общим всплеском, но расписания пиков Anthropic не публикует. В такой момент вы не выделены системой, просто попали в очередь вместе со всеми.

Поскольку ошибка временная и серверная, повторять запрос правильно. Но повторять сразу и агрессивно значит усугублять затор для всех, включая себя. Видна она везде по-разному: в API это код 529, в Claude Code текст «API Error: Repeated 529 Overloaded errors», в веб-чате claude.ai сообщение о перегрузке вместо ответа.

В API ответ выглядит так:

{
  "type": "error",
  "error": {
    "type": "overloaded_error",
    "message": "Overloaded"
  }
}

Причина → решение для 529:

• Причина: перегрузка платформы целиком, обычно в часы пик или сразу после запуска модели.
• Решение: экспоненциальный бэкофф с джиттером (код ниже), ограничение параллелизма, перенос несрочной работы на ночь или в Batch API.
• Управление в клиенте: используйте ограниченную очередь, снижайте параллелизм и возвращайте явную ошибку после исчерпания повторов. Доступ через шлюз не создаёт дополнительную ёмкость.

Честная оговорка: заголовка, который скажет, когда перегрузка спадёт, нет. В отличие от 429, 529 редко несёт полезный retry-after. Так что расписание бэкоффа остаётся единственным вашим рычагом. Не выбрасывайте джиттер: без него все клиенты мира повторяют запросы в один такт и воссоздают всплеск.

Что делать, если 529 вылетел прямо сейчас

1. Подождите 10-30 секунд. Обычно перегрузка короткая, и повтор через полминуты проходит.
2. Повторите запрос без правок. Текст сообщения ни при чём, переписывать его не нужно.
3. Не жмите отправку раз за разом. Серия быстрых повторов не ускоряет ответ и добавляет нагрузку.
4. Если ошибка держится дольше нескольких минут, откройте status.claude.com. Там отдельные строки для claude.ai, Claude API и Claude Code, видно, идёт ли инцидент.
5. Смените модель, если интерфейс это позволяет. По справке Claude Code ёмкость считается по моделям, так что бывает перегружена одна модель, а соседняя отвечает.

В Claude.ai

Вместо ответа появляется сообщение о перегрузке. Обновление страницы само ничего не чинит, но следующая отправка после него и есть повторный запрос. Если экран пустой и никакого текста об ошибке нет, дело скорее в сети или браузере: у 529 есть явное сообщение или код.

В Claude Code

Claude Code повторяет запрос сам и только потом показывает ошибку. По справке Anthropic, число повторов по умолчанию 10, его задаёт CLAUDE_CODE_MAX_RETRIES. Если ошибка всё же на экране:

• Подождите пару минут и отправьте сообщение снова. Справка Claude Code для ошибки 500 советует не вставлять длинный промпт заново, а написать try again: прежнее сообщение остаётся в диалоге.
• Выполните /model и выберите другую модель. Claude Code сам предлагает это, когда конкретная модель под высокой нагрузкой.
• Не бойтесь за лимиты: по справке, 529 не считается использованием квоты.
• Если агент оборвался посреди задачи, посмотрите git status и git diff, прежде чем запускать то же задание заново: часть правок могла уже лечь на диск.

Паузами между повторами управляют переменные окружения:

Две последние переменные работают только в свежих версиях Claude Code и не действуют при CLAUDE_CODE_RETRY_WATCHDOG=1.

Как реже ловить 529

Одна 529 раз в несколько дней это нормальная часть жизни популярного API, и переживать не о чем. Другое дело, если ошибка мешает каждый день.

Если вы работаете в чате или Claude Code, переносите тяжёлые задачи на часы, когда у вас 529 не бывает (расписания у нас нет, подберите по своим наблюдениям), переключайтесь на соседнюю модель через /model и дробите длинные задания на шаги, чтобы обрыв стоил меньше работы. При постоянных сбоях напишите в поддержку Anthropic и укажите, в какое время ошибка повторяется чаще всего.

Если вы пишете код, у вас больше рычагов: бэкофф с джиттером, потолок параллелизма и Batch API для несрочного описаны выше и ниже. Добавьте одно: наращивайте трафик постепенно. Документация Anthropic предупреждает, что резкий рост использования в организации может дать 429 из-за ограничений на ускорение, а ровная нагрузка этого избегает.

Как исправить ошибку 500 в Claude API?

500 Internal Server Error означает, что на стороне Anthropic что-то сломалось при обработке в целом корректного запроса. Вы ничего не сделали не так, и тот же запрос обычно проходит при повторе. Реакция как с 529: отступить и попробовать снова.

Разница в природе. 500 это неожиданный сбой, а 529 это ожидаемый сброс нагрузки. С точки зрения кода они обрабатываются одинаково: обе повторяемые серверные ошибки. Тело ответа всё же стоит прочитать, но ради одного поля: error.type у 500 бывает api_error или timeout_error. При api_error менять в запросе нечего: повторите с бэкоффом, а если ошибка не уходит, сохраните request_id из тела ответа (он же лежит в заголовке request-id) и приложите к обращению в поддержку. timeout_error значит, что запрос упёрся в лимит времени на сервере раньше, чем начался ответ. Для длинных запросов Anthropic советует стриминг, он разобран в разделе про таймауты ниже.

{
  "type": "error",
  "error": {
    "type": "api_error",
    "message": "Internal server error"
  }
}

Если 500 лезут раз за разом в течение нескольких минут, это уже не «временно». Проверьте страницу статуса Anthropic и собственный payload: нет ли чего-то настолько громоздкого, что задевает серверный edge-case (например, гигантских схем инструментов). Но обычно хватает одного ретрая.

А что с 503 Service Unavailable?

503 означает, что сервис временно недоступен или на обслуживании: ещё одно временное, повторяемое состояние. Сценарий тот же, что у 500 и 529: экспоненциальный бэкофф, уважение к retry-after, если он есть, и аккуратный отказ после разумного числа попыток.

Держите эту тройку в голове вместе: 529, 500, 503 = повторять. Причины разные (перегрузка, внутренний сбой, недоступность), а реакция одна. Слой ретраев должен ловить все три одной и той же логикой.

Почему возникает ошибка 429 rate limit?

429 Too Many Requests означает, что вы упёрлись в лимит. Чаще всего это лимиты скорости: запросов в минуту (RPM), входных токенов в минуту (ITPM) или выходных токенов в минуту (OTPM) для модели. Резкий рост трафика тоже может дать 429 из-за ограничений на ускорение. В отличие от семейства 5xx, эта ошибка про ваше потребление, и API обычно подсказывает, сколько ждать, в заголовке retry-after. Есть он не в каждом ответе.

{
  "type": "error",
  "error": {
    "type": "rate_limit_error",
    "message": "Number of requests has exceeded your per-minute limit."
  }
}

Есть и 429, который повтором не лечится: месячный лимит расходов. Когда расход доходит до месячного потолка вашего уровня доступа (tier) в Anthropic API, использование встаёт на паузу до 00:00 UTC первого числа следующего месяца, если вы не запросите повышение раньше. Тип ошибки остаётся rate_limit_error, но заголовка retry-after нет, а в error.details.error_code стоит enforced_spend_limit_reached. Повторы, включая автоповторы SDK, падают, пока не вернётся доступ. Отличайте этот случай по error_code, а не по тексту сообщения, и не гоняйте его через цикл ретраев. Если вы сами задали лимит расходов для организации или workspace в консоли, при его достижении обычно приходит не 429, а 400: он разобран в следующем разделе.

Учитывайте retry-after, если он есть. Измеряйте расход токенов, кэшируйте повторяющийся контекст, где это поддерживается, и ограничивайте частоту запросов в клиенте. Доступ через шлюз не создаёт независимые квоты. Очереди и обработка квот провайдера разобраны в гиде по лимитам Claude API.

Haiku у нас есть: в каталоге claude-haiku-5.5 и claude-haiku-4.5, цены на странице моделей. Они работают в канале Premium, в канале Cheap Haiku нет.

Из-за чего появляется ошибка 400 Bad Request?

400 означает, что сам запрос некорректен: API отклонил его ещё до обработки, и повтор того же запроса будет падать каждый раз. Это баг в коде, а не временный сбой. Остановитесь, прочитайте сообщение, почините payload.

Одно исключение: 400 приходит и тогда, когда расход достиг лимита, который вы сами задали для организации или workspace в консоли. Сообщение начинается с You have reached your specified API usage limits (для workspace: You have reached your specified workspace API usage limits) и называет дату, когда доступ вернётся. Чинить тут нечего: поднимите или снимите лимит либо дождитесь этой даты.

Самые частые причины, примерно по убыванию:

Системный промпт передавайте через верхнеуровневое поле system: документация Anthropic описывает именно его. Строгое чередование user и assistant для валидного запроса не нужно: Messages API объединяет подряд идущие сообщения одной роли в один ход.

Вот 400 из-за забытого max_tokens:

{
  "type": "error",
  "error": {
    "type": "invalid_request_error",
    "message": "max_tokens: Field required"
  }
}

И корректный запрос в curl, где всё на месте:

curl https://api.claudexia.tech/v1/messages \
  -H "x-api-key: $CLAUDEXIA_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 1024,
    "messages": [
      {"role": "user", "content": "Привет, Claude."}
    ]
  }'

Поймали 400: логируйте полный error.message. Он конкретен и обычно указывает прямо на сломанное поле. Не прячьте его.

Почему ключ возвращает 401 или 403?

401 Unauthorized означает, что ключ отсутствует, повреждён, отозван или истёк. 403 Forbidden означает, что ключ валиден, но не имеет права на то, что вы запросили. Ни одна из ошибок не повторяемая: чините учётные данные или права и идите дальше.

Чек-лист для 401:

• Ключ вообще отправляется? Проверьте заголовок x-api-key (или Authorization: Bearer на OpenAI-совместимом эндпоинте).
• Не подгрузилась ли переменная окружения пустой строкой?
• Не перепутаны ли ключ и base URL? Ключ Anthropic sk-ant-… не пройдёт авторизацию на другом base URL, а ключ Claudexia sk_cdx_… нацелен на https://api.claudexia.tech.
• Пробел или перенос строки, случайно вставленный в ключ? Бывает чаще, чем кажется.

Отдельный случай: 401, сообщение которого начинается с CORS requests are not allowed for this Organization, к ключу отношения не имеет. Запрос пришёл с заголовком Origin (его добавляют браузеры), а организации Anthropic нельзя вызывать Claude API напрямую из браузера. Править сам запрос бесполезно: отправляйте его со своего backend.

Для 403 ключ работает, но доступа нет: например, вы запросили модель, которой нет у вашего аккаунта или тарифа, или дёрнули эндпоинт за пределами прав. Прочитайте сообщение: в нём названо ограничение.

{
  "type": "error",
  "error": {
    "type": "authentication_error",
    "message": "invalid x-api-key"
  }
}

Что такое ошибка 413 Request Too Large?

413 с типом request_too_large означает, что тело запроса превысило предел в байтах. У Anthropic это 128 MB для Messages API, 256 MB для Batch API и 500 MB для Files API. К токенам и контекстному окну эта ошибка отношения не имеет: если один только ввод не помещается в окно модели, API отвечает 400 invalid_request_error с сообщением «prompt is too long». В исходном виде повторять такой запрос бесполезно: его нужно ужать.

Типичные триггеры и решения:

• Переполнение контекста (приходит как 400, не 413): вы вышли за лимит ввода модели. Подрежьте историю, суммируйте старые ходы, разбейте задачу. Тактики «лёгкого» payload разобраны в посте про экономию на Claude API.
• Огромные изображения или PDF (здесь и бывает 413): с большим числом картинок или тяжёлыми документами запрос может упереться в лимит байтов раньше, чем в лимит токенов. Уменьшайте картинки и делите большие документы перед отправкой.
• Разросшаяся история чата: в цикле диалога обрезайте или суммируйте ранние сообщения, а не добавляйте их бесконечно.

Если вы регулярно упираетесь в лимит размера, это сигнал к редизайну: переходите на ретрив (отправляйте только релевантные фрагменты), а не вываливайте всё в каждый вызов.

Как обрабатывать таймауты и ошибки соединения?

Под словом «таймаут» скрываются три разные вещи, и обрабатывать их надо по-разному.

1. Клиентский таймаут. SDK ждёт ответ 10 минут по умолчанию. Если время вышло или соединение оборвалось, он бросает исключение (APITimeoutError в Python, APIConnectionTimeoutError в TypeScript), и HTTP-кода у этого случая нет вовсе.
2. Ответ 504 с типом timeout_error. Запрос не уложился во время обработки на стороне Anthropic. Тот же timeout_error приходит и с другими кодами, например с 500, когда запрос упёрся в лимит времени сервера до начала ответа.
3. 408 Request Timeout. Обычный HTTP-код. В перечне ошибок Anthropic его нет, но SDK повторяет 408 по умолчанию, и в коде ниже он тоже в списке повторяемых.

Все три повторяемые, но слепо повторять один и тот же долгий запрос мало толку. Для длинных ответов Anthropic рекомендует стриминг (для очень долгих задач ещё Batch API): токены начинают приходить сразу, и сеть реже обрывает ожидание по простою. Выставьте и разумный клиентский таймаут: слишком короткий оборвёт валидные длинные ответы, слишком длинный подвесит воркер на зависшем соединении.

import anthropic

# Явный таймаут; стримим, чтобы не словить таймаут по простою
client = anthropic.Anthropic(timeout=120.0)

with client.messages.stream(
    model="claude-sonnet-5",
    max_tokens=4096,
    messages=[{"role": "user", "content": "Напиши длинный отчёт."}],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

Ошибки соединения должны попадать в ту же корзину ретраев, что и 529/500/503/504. Код ниже их ловит.

Полный справочник по кодам статуса

Держите эту таблицу рядом с обработчиком ошибок. Колонка «Действие» это вся суть: временное повторяем, остальное чиним. В таблице коды из документации Anthropic и два кода, которые SDK тоже повторяет: 408 и 503.

Экспоненциальный бэкофф с джиттером: ретрай для продакшена

Это тот самый код, который нужен любой интеграции с Claude. Он повторяет временные ошибки (429, 500, 503, 504, 529, 408, таймауты, обрывы), ждёт не меньше retry-after, добавляет джиттер, чтобы клиенты не синхронизировались, и, что самое главное, не повторяет ошибки, которые суть ваш баг (400, 401, 403, 413), а также 429 про месячный лимит расходов.

SDK умеет повторять запросы сам: по умолчанию он делает два повтора при обрыве соединения, 408, 409, 429 и ответах 5xx, с короткой экспоненциальной паузой и с учётом retry-after. Если оставить это включённым и обернуть вызов своим циклом на 6 попыток, выйдет до 18 HTTP-запросов: каждая попытка цикла сама повторится дважды. Поэтому в примерах повторы SDK отключены на вызов (with_options(max_retries=0) в Python, { maxRetries: 0 } в TypeScript). Если вам хватает двух повторов SDK, свой цикл не нужен: поднимите max_retries или maxRetries у клиента.

Python:

import random
import time

import anthropic

RETRYABLE_STATUS = {408, 429, 500, 503, 504, 529}
SPEND_LIMIT_CODE = "enforced_spend_limit_reached"


def is_spend_limit(e: anthropic.APIStatusError) -> bool:
    body = e.body if isinstance(e.body, dict) else {}
    details = (body.get("error") or {}).get("details") or {}
    return details.get("error_code") == SPEND_LIMIT_CODE


def pause_seconds(attempt: int, retry_after: str | None, base: float, cap: float) -> float:
    try:
        wait = float(retry_after) if retry_after else None
    except ValueError:
        wait = None
    if wait is not None:
        return wait + random.uniform(0, min(1.0, wait * 0.25))
    return random.uniform(0, min(cap, base * 2**attempt))


def call_with_retry(
    client: anthropic.Anthropic,
    *,
    max_attempts: int = 6,
    base_delay: float = 1.0,
    max_delay: float = 60.0,
    **kwargs,
) -> anthropic.types.Message:
    for attempt in range(max_attempts):
        try:
            # SDK по умолчанию повторяет сам дважды; попытки считает цикл, поэтому отключаем
            return client.with_options(max_retries=0).messages.create(**kwargs)
        except anthropic.APIConnectionError:
            if attempt == max_attempts - 1:
                raise
            retry_after = None
        except anthropic.APIStatusError as e:
            # Не повторяем ошибки, которые вы сами создали, и лимит расходов: чините запрос или лимит.
            if (
                e.status_code not in RETRYABLE_STATUS
                or is_spend_limit(e)
                or attempt == max_attempts - 1
            ):
                raise
            retry_after = e.response.headers.get("retry-after")
        time.sleep(pause_seconds(attempt, retry_after, base_delay, max_delay))
    raise RuntimeError("unreachable")

TypeScript:

import Anthropic from "@anthropic-ai/sdk";

const RETRYABLE = new Set([408, 429, 500, 503, 504, 529]);
const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));

type ErrorBody = { error?: { details?: { error_code?: string } } };

const isSpendLimit = (err: Anthropic.APIError) =>
  (err.error as ErrorBody | undefined)?.error?.details?.error_code ===
  "enforced_spend_limit_reached";

function pauseMs(
  attempt: number,
  retryAfter: string | null | undefined,
  baseDelay: number,
  maxDelay: number,
): number {
  const seconds = retryAfter ? Number.parseFloat(retryAfter) : Number.NaN;
  if (Number.isFinite(seconds)) {
    const wait = seconds * 1000;
    return wait + Math.random() * Math.min(1000, wait * 0.25);
  }
  return Math.random() * Math.min(maxDelay, baseDelay * 2 ** attempt);
}

export async function callWithRetry(
  client: Anthropic,
  params: Anthropic.MessageCreateParamsNonStreaming,
  { maxAttempts = 6, baseDelay = 1000, maxDelay = 60000 } = {},
): Promise<Anthropic.Message> {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    try {
      // SDK по умолчанию повторяет сам дважды; попытки считает цикл, поэтому отключаем
      return await client.messages.create(params, { maxRetries: 0 });
    } catch (err) {
      const last = attempt === maxAttempts - 1;
      let retryAfter: string | null | undefined;

      if (err instanceof Anthropic.APIConnectionError) {
        if (last) throw err;
      } else if (err instanceof Anthropic.APIError && err.status) {
        // 400/401/403/413 и лимит расходов: пробрасываем сразу.
        if (!RETRYABLE.has(err.status) || isSpendLimit(err) || last) throw err;
        retryAfter = err.headers?.get("retry-after");
      } else {
        throw err;
      }

      await sleep(pauseMs(attempt, retryAfter, baseDelay, maxDelay));
    }
  }
  throw new Error("unreachable");
}

Пара решений, которые стоит понимать. Полный джиттер (случайное значение в [0, delay]) лучше фиксированных экспоненциальных пауз гасит синхронные ретраи: об этом ещё годы назад писал инженерный блог AWS, и это до сих пор так. Но применяется он только к паузе, которую вы считаете сами. Если сервер прислал retry-after, это нижняя граница: раньше повтор не пройдёт, поэтому джиттер к ней лишь прибавляется. Ограничитель max_delay не даёт бэкоффу разрастись до абсурдных пауз. А разделение повторяемых и неповторяемых кодов ровно то, что не даёт 400 крутиться вечно.

Как шлюз влияет на ошибки 529?

Шлюз меняет эндпоинт и аккаунт, через которые работает приложение. Это не создаёт дополнительную ёмкость и не гарантирует исчезновение ошибок перегрузки провайдера. Обрабатывайте 529 Overloaded как возможный сбой и ограничивайте повторы для временных ошибок.

Claudexia позволяет выбрать для ключа Premium или Cheap и разрешить резервный Premium для Cheap по правилам провайдера. Перед отправкой запросов проверьте доступность модели и канала. Доступность и политики провайдера продолжают действовать; настройки ключа не гарантируют отдельный пул ёмкости, автоматическую смену маршрута или подавление upstream-ошибок 529. Клиент должен обрабатывать эти сбои.

Переключиться можно правкой в одну строку: те же SDK, те же формы запросов.

import anthropic

# Тот же SDK Anthropic, направленный на шлюз.
client = anthropic.Anthropic(
    api_key="sk_cdx_your_key",
    base_url="https://api.claudexia.tech",
)

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Привет"}],
)

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic({
  apiKey: "sk_cdx_your_key",
  baseURL: "https://api.claudexia.tech",
});

Для Claude Code та же замена делается двумя переменными окружения:

export ANTHROPIC_BASE_URL="https://api.claudexia.tech"
export ANTHROPIC_API_KEY="sk_cdx_ВАШ_КЛЮЧ"

Установка Claude Code под Windows, macOS и Linux расписана в статье «Claude Code в России 2026». Ошибки перегрузки Anthropic при этом никуда не деваются, поэтому правила ретраев выше остаются в силе.

Есть и OpenAI-совместимый эндпоинт, так что Cursor, Claude Code и OpenCode подключаются без изменений. Оплата за токены, без подписки. В канале Premium на 10 ноября 2026 Sonnet 5.5 стоит $0,52 за 1M токенов на входе и $1,98 на выходе, Opus 5.5 стоит $0,86 и $3,30. У Anthropic Sonnet 5.5 стоит $2 и $10, Opus 5.5 стоит $4 и $20. Цены меняются, свежие смотрите на странице моделей. Для дешёвых массовых задач в каталоге есть gpt-5.6-luna. Платить можно через СБП, российскими картами, криптой (USDT/BTC/ETH) или MTS. Детали в разделе цены и справочнике API, а региональный разбор в посте доступ к Claude из России в 2026.

Частые вопросы

Виноват ли я в ошибке 529 Overloaded?

Нет. Код 529 означает перегрузку у провайдера, а не ошибку в вашем запросе, ключе или квоте, поэтому проверять интернет и переустанавливать клиент бессмысленно. Ограничивайте повторы в клиенте, используйте бэкофф с джиттером и снижайте параллелизм во время всплеска. Доступ через шлюз не гарантирует запасную ёмкость или подавление ошибки; после исчерпания повторов верните явный отказ.

Сколько длится перегрузка?

Обычно от нескольких секунд до нескольких минут. Точного срока Anthropic не называет, а заголовка с временем восстановления у 529 почти не бывает. Затяжная перегрузка оформляется инцидентом на status.claude.com, так что при ошибке дольше нескольких минут смотрите туда.

Помогает ли обновление страницы claude.ai?

Само по себе нет. Но следующая отправка сообщения после обновления это и есть повторный запрос, так что косвенно помогает так же, как пауза и повтор.

Чем 529 отличается от случая, когда Claude просто молчит?

У 529 есть явное сообщение об ошибке или код статуса. Пустой экран без текста чаще означает проблему сети или браузера, и API Anthropic тут ни при чём.

Стоит ли менять провайдера из-за периодических 529?

Разовые 529 не повод. Если перегрузка стала ежедневной помехой, надёжнее поменять устройство клиента: очередь, бэкофф, потолок параллелизма и резервная модель, которую вы подключаете сами в своём коде. Шлюз перегрузку Anthropic не устраняет.

Стоит ли повторять ошибку 400 Bad Request?

Никогда. 400 означает, что payload некорректен, поэтому идентичный повтор падает идентично: вы лишь потратите вызовы. Прочитайте error.message: он обычно называет сломанное поле и чините его. Классика: забытый max_tokens, невалидный JSON или prefill последнего сообщения assistant на модели, которая его не поддерживает. Исключение из «никогда» одно: 400 из-за лимита расходов, который вы задали сами, проходит снова после того, как вы подняли лимит или наступила названная в сообщении дата.

В чём разница между 429 и 529?

Ошибка 429 относится к квотам провайдера: учитывайте retry-after, если он есть, и снижайте нагрузку клиента. Исключение: 429 с enforced_spend_limit_reached означает месячный лимит расходов, и повтор его не снимет. Ошибка Anthropic 529 означает перегрузку платформы. Для временных сбоев используйте ограниченные повторы с бэкоффом; если сбой продолжается, верните ошибку. Шлюз не гарантирует переключение на другой пул ёмкости. Управление в клиенте разобрано в гиде по лимитам.

Почему 429 не проходит после повторов?

Скорее всего, это месячный лимит расходов, а не лимит скорости. Смотрите на error.details.error_code: значение enforced_spend_limit_reached значит, что доступ встал на паузу до 00:00 UTC первого числа следующего месяца или до повышения лимита. Опирайтесь именно на error_code: у других ответов 429 заголовка retry-after тоже может не быть, так что по его отсутствию лимит расходов не отличить. Повторы, включая автоповторы SDK, до возобновления доступа будут падать.

Сколько раз повторять перед тем, как сдаться?

Для временных ошибок 5–6 попыток с ограниченным экспоненциальным бэкоффом это разумное значение по умолчанию: хватает переждать короткий всплеск, не подвешивая запрос на минуты. Считайте именно HTTP-попытки: SDK по умолчанию сам повторяет запрос дважды, так что цикл из шести вызовов без max_retries=0 даст до 18 запросов. Всегда ограничивайте паузу на попытку (например, 60 секундами) и отдавайте вызывающему понятную ошибку после исчерпания ретраев, чтобы зависший запрос не выдавался за успех.

Почему я получаю 401, хотя ключ вроде правильный?

Обычные подозреваемые: переменная окружения подгрузилась пустой строкой; пробел или перенос строки, вставленный в ключ; не тот заголовок (x-api-key против Authorization: Bearer); или несовпадение ключа и base URL: ключ sk-ant-… не пройдёт авторизацию на не-Anthropic base URL, а ключ sk_cdx_… должен идти на https://api.claudexia.tech. Логируйте длину и префикс ключа (но никогда не значение целиком), чтобы быстро это ловить. Если запрос уходит из браузера и сообщение начинается с CORS requests are not allowed for this Organization, ключ ни при чём: отправляйте запрос со своего backend.

Ограничивайте повторы в клиенте и отличайте временные сбои провайдера от некорректных запросов. Проверяйте доступность модели и канала; доступ через шлюз не гарантирует исчезновение ошибок перегрузки. Начните с быстрого старта. С вопросами по интеграции напишите нам или в Telegram.