Лимиты GPT-6 Astra в OpenAI API: RPM, TPM, ошибки 429 и 503

Если вы готовите GPT-6 Astra к рабочей нагрузке, одной цифры «запросов в минуту» недостаточно. Публичная таблица OpenAI зависит от уровня использования API и режима обработки, а фактические ограничения конкретного проекта нужно проверять в Limits и по заголовкам ответа. Кроме того, модель открывается поэтапно: отсутствие доступа не следует диагностировать как исчерпанный RPM или TPM. Официальный идентификатор модели в API — gpt-6-astra.

Ниже приведены официальные значения для Standard, проверенные 4 сентября 2026 года. Они дают отправную точку для расчёта пропускной способности, но не заменяют данные вашей организации и проекта.

Публичные лимиты GPT-6 Astra для Standard

Карточка модели GPT-6 Astra указывает следующие ограничения:

RPM — число запросов в минуту, TPM — число токенов в минуту. Эти два ограничения действуют одновременно. Например, небольшой запрос может упереться в RPM, а умеренное число запросов с длинным контекстом — в TPM. Большое значение в одной колонке не компенсирует исчерпание другой.

Согласно руководству по лимитам, Batch queue измеряется не заданиями и не запросами. Это суммарное число входных токенов во всех ожидающих заданиях Batch API для данной модели. После завершения задания его токены перестают занимать очередь. Поэтому 1 500 000 для Tier 1 нельзя читать как 1 500 000 пакетных заданий или как суточную квоту.

Таблица описывает публичные ограничения Standard. В руководстве по Fast OpenAI отдельно уточняет, что Standard и Fast для одной модели используют общий лимит, а быстро растущий трафик в Fast всё равно подчиняется ограничению на темп наращивания нагрузки. Однако наличие строки в публичной таблице не доказывает, что Fast или сама модель уже доступны вашему проекту.

Сначала проверьте доступ, затем квоту

В журнале изменений OpenAI API выпуск GPT-6 Astra для API датирован 3 сентября 2026 года. При этом официальная страница модели по состоянию на 4 сентября всё ещё описывала поэтапное открытие доступа. Эти утверждения не противоречат друг другу: API может быть выпущен публично, пока разрешение выдаётся организациям и проектам постепенно.

Если первый вызов Astra не проходит, разделите две проверки:

1. Есть ли у проекта доступ к модели. Проверьте, доступна ли Astra именно организации и проекту, которым принадлежит API-ключ. Появление модели в документации, ChatGPT или локальном списке конфигурации само по себе этого не подтверждает.
2. Какой лимит назначен проекту. Если доступ есть, откройте страницу Limits и найдите актуальные ограничения для нужной модели и проекта.

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

Что публичная таблица не сообщает

По состоянию на 4 сентября 2026 года официальные страницы Astra публиковали RPM, TPM и вместимость очереди Batch API, но не отдельные численные значения для:

• RPD — запросов в сутки;
• TPD — токенов в сутки;
• числа одновременно выполняемых запросов;
• отдельного ограничения длинного контекста для Astra.

Отсутствие публичной цифры не доказывает, что внутреннего или индивидуального ограничения нет. Оно означает только, что его нельзя честно вычислить по RPM, TPM, цене, размеру контекстного окна или данным другой модели. Общий справочник по лимитам предупреждает, что для длинного контекста могут действовать отдельные ограничения, и направляет разработчика в консоль. Если такой профиль назначен вашему проекту, ориентируйтесь на Limits, а не выводите его из порога цены или максимального ввода.

Заголовки ответа показывают, что заканчивается

Страница Limits отвечает на вопрос о назначенных значениях. Заголовки конкретного ответа показывают состояние текущего окна. В первую очередь сохраняйте:

• x-ratelimit-limit-requests;
• x-ratelimit-remaining-requests;
• x-ratelimit-reset-requests;
• x-ratelimit-limit-tokens;
• x-ratelimit-remaining-tokens;
• x-ratelimit-reset-tokens;
• Retry-After, если сервер его вернул.

Для некоторых запросов доступны и заголовки, относящиеся к токенам проекта. Их наличие и значения нужно читать из реального ответа, а не переносить из примера документации.

Минимальный журнал инцидента должен содержать HTTP-статус, error.type, error.code, модель, endpoint, идентификатор проекта, перечисленные заголовки и номер попытки. Не записывайте сам API-ключ и чувствительное содержимое запроса.

ts
const rateLimitSnapshot = {
  status: response.status,
  retryAfter: response.headers.get("retry-after"),
  requestLimit: response.headers.get("x-ratelimit-limit-requests"),
  requestsLeft: response.headers.get("x-ratelimit-remaining-requests"),
  requestsReset: response.headers.get("x-ratelimit-reset-requests"),
  tokenLimit: response.headers.get("x-ratelimit-limit-tokens"),
  tokensLeft: response.headers.get("x-ratelimit-remaining-tokens"),
  tokensReset: response.headers.get("x-ratelimit-reset-tokens"),
};

Если requestsLeft близок к нулю, уменьшайте частоту и параллелизм. Если заканчиваются токены, сокращайте входной контекст и ожидаемый ответ. Когда исчерпаны оба окна, ждите более позднего времени сброса. Заголовки с нормальным остатком при продолжающейся ошибке — повод проверить тело ответа, доступ к модели, проект, биллинг и состояние сервиса, а не повод бесконечно повторять вызов.

Почему 429 и 503 требуют разных действий

HTTP-статус сам по себе ещё не даёт полной причины. Читайте его вместе с error.type, error.code и Retry-After. Официальное руководство OpenAI отдельно описывает быстрое наращивание трафика и нехватку мощности модели:

slow_down — не название любого 429. Это отдельный сигнал о темпе роста трафика. Покупка кредитов или переход на более высокий Tier не исправляет скачок нагрузки автоматически.

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

Если тело 429 указывает на состояние квоты или биллинга, ожидание минутного сброса тоже не поможет. Проверьте кредит, способ оплаты, бюджет проекта и состояние аккаунта; типовые причины ответов собраны в справочнике ошибок OpenAI. Один и тот же механизм повторов нельзя применять к исчерпанному окну, отсутствию оплаты, поэтапному доступу и 503.

Безопасный повтор ограничен по времени и числу попыток

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

ts
const maxAttempts = 6;
const baseDelayMs = 500;
const maxDelayMs = 15_000;

for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
  const exponential = Math.min(maxDelayMs, baseDelayMs * 2 ** attempt);
  const jitter = Math.random() * exponential * 0.25;
  await sleep(exponential + jitter);

  // Повторяйте только временную ошибку, которую вы уже классифицировали.
}

Этот фрагмент показывает только расчёт паузы. В рабочем коде до цикла нужно разобрать ответ, учесть Retry-After, остановиться при постоянной ошибке доступа или оплаты и не повторять запрос после отмены клиентом. Общий бюджет попыток должен учитывать повторы SDK, шлюза и самого приложения, иначе шесть попыток на каждом уровне легко превращаются в десятки вызовов.

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

• при исчерпании RPM сгладьте всплески, ограничьте параллелизм и поставьте запросы в очередь;
• при исчерпании TPM уменьшите контекст, уберите лишнюю историю и ограничьте размер ответа;
• при slow_down наращивайте нагрузку постепенно, а не только увеличивайте минутный потолок;
• при server_is_overloaded переждите временную нехватку мощности и используйте только проверенный резервный сценарий;
• при проблеме с оплатой или бюджетом исправьте состояние аккаунта вместо повторов;
• для несрочной массовой работы рассмотрите Batch API, контролируя сумму входных токенов ожидающих заданий.

Если после этого приложению всё ещё не хватает устойчивой пропускной способности, соберите фактические RPM и TPM, размеры запросов, профиль параллелизма, времена сброса и долю ошибок. Только затем запрашивайте повышение лимита. Более высокий Tier полезен для реальной устойчивой нагрузки, но не заменяет управление очередью и повторами.

Лимиты API не равны лимитам Work и Codex

OpenAI API, ChatGPT Work и Codex используют разные механизмы доступа и учёта. Уровень Usage Tier в таблице Astra — это уровень использования API, а не тариф ChatGPT. Подписка, лимит сообщений или кредиты Work/Codex не превращаются в RPM и TPM для API-проекта.

В корпоративном рабочем пространстве администратор может включить Astra для пользователей или групп в Chat, Work и Codex, но это не выдаёт доступ API-ключу. И наоборот, API-ключ с доступом к Astra не меняет окно использования подписочного продукта. Для API решающими остаются организация, проект, модель, страница Limits и ответы сервера.

Если проблема возникает в Codex при входе через ChatGPT, используйте разбор лимитов OpenAI Codex. Если Codex работает с API-ключом, сначала определите, какая система учитывает расход: это различие подробно разобрано в статье Codex API key или подписка. Не покупайте другой план, пока не установили, к какому продукту относится ограничение.

Рабочая последовательность диагностики

Когда Astra не отвечает под нагрузкой, пройдите проверки в таком порядке:

1. Убедитесь, что API-ключ принадлежит ожидаемым организации и проекту, а проект уже получил доступ к Astra.
2. Сверьте свой Usage Tier и модель с текущей страницей Limits.
3. Сохраните HTTP-статус, error.type, error.code, Retry-After и все x-ratelimit-* из реального ответа.
4. Определите, исчерпаны запросы, токены, очередь Batch или ни один из этих показателей.
5. Отделите slow_down от обычного исчерпания окна, а 503 server_is_overloaded — от любой ошибки 429.
6. Примените ограниченный повтор только к временной причине; доступ, оплату и конфигурацию исправляйте без цикла повторов.
7. Снизьте параллелизм или токеновую нагрузку, а несрочные задания перенесите в Batch API.
8. Запрашивайте повышение лимита только с измерениями, подтверждающими устойчивую потребность.

Публичные значения Astra полезны для предварительного планирования, но эксплуатационное решение всегда принимает более свежий источник: сначала Limits вашего аккаунта, затем заголовки и тело конкретного ответа. Такой порядок не только быстрее устраняет 429 и 503, но и не позволяет перепутать поэтапный доступ к модели с квотой либо применить ограничения Work/Codex к OpenAI API.