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

> 2026-11-10 · AI Release · @ai_release1

> #AI #API #OpenAI

### ⚡ Суть спора На 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 **Дисклеймер:** это пересказ обсуждения, а не проверенные редакцией факты. Мнения принадлежат участникам, цифры — тем, кто их привёл.

[Источник](https://community.openai.com/t/repeated-selected-model-is-at-capacity-server-is-overloaded-on-gpt-6-astra-account-specific-never-auto-recovers/1407677)