Жёсткие лимиты расходов OpenAI теперь блокируют API-запросы: что должен проверить каждый оператор шлюза

22 июля 2026 года OpenAI добавил жёсткие месячные лимиты расходов на API-платформе. Это принципиально отличается от controls для ChatGPT Enterprise, запущенных в июне: те были инструментами наблюдаемости в административных дашбордах. Июльское обновление вводит принудительное исполнение — настраиваемый месячный потолок, при достижении которого живые API-запросы начинают возвращать 429. Для команд, маршрутизирующих производственный трафик через шлюз, это новый режим отказа, для которого большинство реализаций обработки ошибок изначально не проектировалось.

Новый путь принудительного исполнения: как лимиты расходов блокируют запросы

До 22 июля платформа OpenAI предлагала spend alerts: уведомления при достижении порога, без влияния на трафик. Жёсткие лимиты расходов работают иначе:

• Когда месячные отслеживаемые расходы достигают настроенного жёсткого лимита, затронутые API-запросы возвращают 429 с кодом ошибки insufficient_quota.
• Лимит остаётся в силе до ручного повышения, удаления или сброса месячного цикла.
• Принудительное исполнение не мгновенное — расходы могут незначительно превысить настроенный порог до распространения состояния лимита.

Ключевое различие для операторов: 429-ошибки типа insufficient_quota означают, что аккаунт превысил настроенный месячный лимит. Это не rate limit 429. Правильный операционный ответ различается, а в логах эти ошибки легко перепутать.

Как сочетаются лимиты на уровне организации и проекта — и почему оба могут сработать одновременно

Лимиты расходов OpenAI действуют на двух независимых уровнях, оба можно настраивать одновременно:

• Жёсткий лимит организации: применяется ко всему API-трафику всех проектов в организации. При достижении блокирует трафик во всех проектах до повышения лимита или сброса месяца.
• Жёсткий лимит проекта: применяется только к трафику, выставляемому на счёт данного проекта. При достижении блокирует только этот проект; остальные продолжают работать — если только лимит организации тоже не достигнут.

Последствие для операторов: один API-запрос может получить 429 как от исчерпания лимита проекта, так и от лимита организации. Код ошибки (insufficient_quota) одинаков в обоих случаях. Если ваш шлюз или прокси не различает уровни, по одному лишь 429 невозможно определить: нужен ли fallback внутри проекта или заблокирована вся организация.

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

429-ошибка, которую ваша логика повторных попыток, вероятно, обрабатывает неправильно

Большинство шлюзов и прокси-реализаций обрабатывают 429-ответы через retry с экспоненциальным backoff. Для rate limit 429 это корректно — сервер временно перегружен, подождите и повторите. Для insufficient_quota 429 это некорректно — аккаунт достиг месячного бюджетного потолка, и backoff с повторными попытками не поможет. Запрос будет продолжать отказывать до повышения лимита или сброса цикла.

Тело ответа позволяет различить эти случаи:

{
  "error": {
    "message": "You exceeded your monthly spend limit.",
    "type": "insufficient_quota",
    "code": "insufficient_quota"
  }
}

Rate limit 429 несёт type: "rate_limit_exceeded" и заголовок Retry-After. insufficient_quota 429 не несёт Retry-After, поскольку задержка повтора не является решением.

Если логика повтора вашего шлюза проверяет только HTTP-статус без разбора тела ошибки, она войдёт в цикл повторов на 429 от лимита расходов, тратя дополнительный retry-бюджет на лимит, который не может разрешиться сам до следующего цикла. В многоагентной нагрузке, где десятки субагентов повторяют попытки параллельно, это быстро накапливается.

Сравнение формы запроса в обработчике ошибок шлюза:

До (недостаточно — все 429 считаются повторяемыми):

if response.status_code == 429:
    time.sleep(backoff)
    return retry(request)

После (корректно — различает повторяемые rate limit и неповторяемое исчерпание квоты):

if response.status_code == 429:
    error_code = response.json().get("error", {}).get("code", "")
    if error_code == "insufficient_quota":
        raise SpendLimitExhausted("Достигнут месячный лимит OpenAI — переключиться на резервного провайдера или уведомить оператора")
    else:
        time.sleep(backoff)
        return retry(request)

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

Что операторы должны проверить до следующего счётного периода

Жёсткие лимиты расходов — опциональная функция. Если они не настроены, трафик продолжает идти без ограничений, но вы подвержены неограниченным месячным расходам при потере управления агентом или пике трафика. Если лимиты настроены без обновления логики обработки ошибок, их срабатывание вызовет бесшумные retry-циклы или необработанные 429 в продакшне.

Чек-лист:

1. Решите, нужны ли жёсткие лимиты. Для производственных API-нагрузок лимит на уровне проекта работает как автоматический выключатель от неконтролируемых расходов агента. OpenAI рекомендует настраивать spend alerts ниже жёсткого лимита, чтобы получить уведомление до прерывания трафика.

2. Настройте лимиты на правильном уровне. Лимит организации защищает от превышения суммарного месячного бюджета. Лимит проекта изолирует риски по нагрузке или команде. Если у разных команд раздельные бюджеты, настройте оба.

3. Обновите обработчик 429 в шлюзе: добавьте ветку на error.code == "insufficient_quota", логируйте уровень (проект или организация), уведомляйте оператора и маршрутизируйте к резервному провайдеру вместо повтора.

4. Пересмотрите допущения цепочки fallback. Если OpenAI — основной или резервный провайдер, а лимит расходов сработал в середине месяца, путь fallback к OpenAI исчезает. Убедитесь, что в политике маршрутизации есть вторичный fallback, не зависящий от OpenAI при достижении бюджетных лимитов.

5. Учитывайте превышение при принудительном исполнении. Поскольку исполнение не мгновенное, небольшой объём расходов может превысить настроенное значение до распространения состояния. Не устанавливайте лимит на точной границе бюджета — оставьте буфер 5–10% для учёта задержки распространения.

Асимметрия между провайдерами, заслуживающая внимания: Anthropic в июле 2026 года ввёл обязательное истечение срока API-ключей, сделав жизненный цикл ключей самостоятельным управленческим измерением. Жёсткие лимиты расходов OpenAI делают месячный бюджет автоматическим выключателем. Оба механизма дополняют друг друга — истечение ключей управляет жизненным циклом учётных данных, лимиты расходов — переполнением бюджета, — но каждый требует отдельной политики на уровне шлюза.

Что стоит проверить или попробовать пользователям TheRouter

Если вы маршрутизируете через TheRouter с OpenAI в качестве настроенного провайдера, проверьте, включает ли конфигурация провайдера fallback-маршрутизацию при срабатывании 429 по бюджетным причинам. Код ошибки insufficient_quota теперь является отдельным сигналом, который политика маршрутизации должна обрабатывать иначе, чем rate limit 429.

Руководство по лимитам расходов: OpenAI API: Spend limits. Для управления затратами сразу по нескольким провайдерам — OpenAI, Anthropic и другим — см. документацию TheRouter.