OpenAI разделил 429 для ограничений: что 'slow_down' и 'server_is_overloaded' означают для вашей политики повторных запросов

2 сентября OpenAI опубликовал небольшую запись в changelog, которая выглядит рутинно. Это не так. Изменение разделяет то, что раньше было одним неоднозначным HTTP 429, на два семантически разных ответа — и это разделение существенно влияет на логику повторных запросов в шлюзах и маршрутизацию трафика под нагрузкой.

Старое поведение: один код ошибки для двух принципиально разных проблем

До этого изменения, получив 429, вы не знали: вы упёрлись в ограничение скорости (ваш трафик слишком быстрый), или столкнулись с временной перегрузкой модели (на стороне OpenAI что-то перегружено). Обе ситуации возвращали одинаковый HTTP-статус с одинаковым телом ошибки.

Это вынуждало большинство реализаций повторных запросов применять единую стратегию экспоненциального отката вне зависимости от причины. Снизить свою пропускную способность, потому что вы превышаете лимит скорости? Правильно. Снизить пропускную способность, потому что инфраструктура OpenAI временно перегружена, а вам нужно просто подождать секунду и повторить с прежней скоростью? Это делает вас медленнее, чем нужно, и увеличивает очередь запросов.

На практике большинство библиотек — LiteLLM, встроенная логика повторов в OpenAI Python SDK, большинство пользовательских middleware — обрабатывали обе ситуации одинаково.

Как выглядит разделение сейчас

429 с кодом slow_down — скорость ваших запросов растёт слишком быстро. Правильная реакция: замедлиться и выдержать паузу перед возобновлением. Если в ответе есть заголовок Retry-After, ждите не меньше указанного времени. Если заголовка нет, используйте экспоненциальный откат. После паузы не возвращайтесь сразу к прежней скорости — наращивайте постепенно.

503 с кодом server_is_overloaded — инфраструктура вывода OpenAI временно перегружена. Это транзитивное состояние, обычно проходящее за секунды или несколько минут. Правильная реакция: короткий откат с ожиданием, что после успешного повтора можно вернуться к полной скорости запросов. Это не означает, что ваш трафик слишком быстрый.

Оба ответа могут содержать заголовок Retry-After. Если он есть — это жёсткий минимум: не повторяйте запрос раньше. Если его нет — используйте свою кривую отката.

Что ломается в существующей логике повторных запросов

Проблема в том, что большинство реализаций повторных запросов в шлюзах ориентируются только на HTTP-статус. Видят 429 — применяют откат. Видят 5xx — либо быстро завершают с ошибкой, либо применяют ту же логику, что и для 429. Новый случай 503 server_is_overloaded требует повтора с коротким ожиданием — не быстрого завершения с ошибкой и не длительного ограничения скорости.

Ментальная модель, которая теперь должна жить в вашем слое повторных запросов:

Если ваш клиент сейчас трактует все 429 как «снизь скорость», а все 503 как «завершить с ошибкой или повторить так же, как 429», после этого изменения у вас есть ложные срабатывания в обе стороны.

Как Anthropic и Google решают ту же проблему — и где OpenAI находится по сравнению с ними

Для контекста: Anthropic использует статус 529 для перегрузки модели, отделяя его от 429 на уровне HTTP. Это чище — ваш HTTP middleware может различить эти ситуации без разбора тела. Компромисс: 529 — нестандартный статус, которого нет в RFC, и некоторые шлюзы на него реагируют непредсказуемо.

Google Gemini API возвращает 429 ResourceExhausted в обоих случаях (квота и мощности), но включает в тело структурированный объект @type: google.rpc.ErrorInfo с полем reason (RATE_LIMIT_EXCEEDED или CONCURRENCY_LIMIT_EXCEEDED). Но только если вы разбираете тело в стиле gRPC, чего большинство REST-клиентов не делают.

DeepSeek V4 ввёл пиковое/непиковое ценообразование в этом году и выдаёт 429 с кодом too_many_requests как для квоты, так и для мощностей, без дополнительного разграничения в теле ошибки.

Подход OpenAI — оставить 429 для ограничений скорости, повысить перегрузку модели до 503 с именованным кодом в теле — нечто среднее. Лучше, чем трактовать всё как 429, стандартнее, чем 529 Anthropic, но всё ещё требует разбора тела, чтобы отличить server_is_overloaded от настоящего сбоя сервиса.

Последствие для слоя маршрутизации

Если вы используете TheRouter или любой AI-шлюз для маршрутизации трафика между провайдерами, это меняет то, когда ответ должен становиться сигналом для перераспределения нагрузки. slow_down 429 от OpenAI означает, что вы должны замедлить запросы к OpenAI. server_is_overloaded 503 означает временную нехватку мощностей у OpenAI — это легитимный сигнал для перенаправления запроса к резервному провайдеру, если ваш бюджет задержки не позволяет ждать.

Раньше оба случая выглядели одинаково в логах шлюза, и вы были вынуждены выбирать одну из интерпретаций. Теперь их можно обрабатывать по-разному:

• slow_down → соблюдать ограничение скорости; продолжать маршрутизировать к OpenAI, но с меньшей интенсивностью
• server_is_overloaded → при необходимости переключаться на резервного провайдера или немедленно ставить в очередь повтора; не снижать квоту скорости на канале OpenAI

Что нужно проверить в клиенте и шлюзе прямо сейчас

1. Проверьте обработку HTTP-статусов в вашей библиотеке повторных запросов. Если она завершает с ошибкой на любом 503, то теперь будет падать на транзитивных скачках мощностей OpenAI вместо того, чтобы повторить запрос.

2. Проверьте, разбираете ли вы тело ошибки вообще. Если ваш код видит response.status === 503 и бросает исключение без чтения error.code, вы никогда не увидите server_is_overloaded.

3. Если у вас есть логика, опирающаяся на коды ошибок в теле, добавьте server_is_overloaded как повторяемое условие — рядом с существующей обработкой 429.

4. Логируйте код вместе со статусом. Раздельная агрегация «429 rate_limit», «429 slow_down» и «503 server_is_overloaded» даст вам гораздо более чёткую картину в периоды высокой нагрузки.

OpenAI пометил это как незначительное обновление. На деле — это первый раз, когда две эти ситуации стали различимы на уровне API, и правильно написанная логика повторных запросов важнее всего именно тогда, когда вы уже под нагрузкой.