server_is_overloaded на gpt-6-astra: ошибка привязана к аккаунту и не проходит сама

⚡ Суть спора

На OpenAI Community открыта ветка автора RE-217: ошибка «Selected model is at capacity» с кодом server_is_overloaded повторяется на модели gpt-6-astra. Автор формулирует две претензии сразу — сбой привязан к конкретному аккаунту и сам не проходит. Ветка набрала 18 комментариев и 1231 просмотр при нуле голосов.

🗣 Что говорят участники

Сразу оговорка, без которой материал был бы враньём: тексты 18 комментариев в редакцию не переданы. Поэтому ниже — разбор того, что заявлено в заголовке и постановке, без цитат, ников и без приписывания кому-либо позиций. Кто именно и что ответил в ветке, из переданных материалов восстановить нельзя.

Формулировка заголовка содержит три отдельных утверждения, и проверяются они по-разному. «Repeated» — про воспроизводимость: ошибка возвращается снова и снова. «Account-specific» — про привязку к аккаунту, а не к модели целиком. «Never auto-recovers» — про отсутствие самовосстановления. Если верно третье, то ретраи и backoff сами по себе проблему не снимут — это уже не транспортный сбой.

Дальше начинается внутреннее противоречие, вокруг которого такая ветка обычно и строится. Код server_is_overloaded по названию серверный: он говорит про перегрузку на стороне сервиса. А поведение, описанное автором, аккаунтное: другие пользователи модели в это же время, по логике жалобы, работают. Либо перегрузка выборочная и задевает часть маршрутов, либо дело в конфигурации и лимитах конкретного аккаунта — и тогда «capacity» в тексте ошибки вводит в заблуждение.

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

Отдельно стоит держать в голове, чего в переданных материалах нет вовсе: ни ответа поддержки, ни ссылки на статус-страницу, ни одного приложенного лога с request-id. Без них любой разбор остаётся на уровне гипотез.

⚖️ Где сходятся, где расходятся

Общего знаменателя в переданных материалах нет — и выдавать за него что-то было бы подменой. Позиции участников не переданы, поэтому утверждать «сообщество считает» нельзя: есть постановка задачи от автора и счётчик комментариев.

Настоящая точка конфликта — в диагнозе, а не в лечении. Ошибка с серверным кодом ведёт себя как аккаунтная, и пока эти две версии не разведены экспериментом, спор идёт о том, чей это сбой: инфраструктуры или конфигурации обращений. Практический вывод из ветки один — без request-id и сравнения двух аккаунтов разговор не сдвинется.

🧪 Что проверить самому

1. Прогнать один и тот же промпт с двух аккаунтов или проектов и одним ключом — так проверяется версия про «account-specific».
2. Сравнить в одном скрипте gpt-6-astra и соседние доступные модели: если падает только одна, дело в маршрутизации на модель, а не в аккаунте.
3. Логировать ответ целиком — HTTP-статус, retry-after, request-id, org/project id, метку времени. Без request-id поддержке нечего сопоставлять.
4. Прогнать backoff с джиттером минут на 10–20: если код ошибки не меняется и retry-after не приходит, «never auto-recovers» подтверждается уже на вашей стороне.
5. Сверить статус-страницу и свой тир/лимиты в момент сбоя: расхождение «страница зелёная, а ошибка стабильная» — самый сильный аргумент в тикете.

🔗 Источники

OpenAI Community — Repeated "Selected model is at capacity" (server_is_overloaded) on gpt-6-astra — account-specific, never auto-recovers

Дисклеймер: это пересказ обсуждения, а не проверенные редакцией факты. Мнения принадлежат участникам, цифры — тем, кто их привёл.