Selected model is at capacity: что делать, если агент пишет, что модель перегружена

Коротко

Что значит «selected model is at capacity»?

Полный текст обычно такой: «Selected model is at capacity. Please try a different model». В переводе - выбранная модель перегружена, попробуй другую. Подсказка внутри самой ошибки, и с неё стоит начать.

На корпоративном практикуме по Codex эта ошибка вылезла у нескольких человек почти одновременно, прямо посреди настройки агента. Участник группы задал вопрос, который напрашивается сам: «это значит, у нас лимиты кончаются или что?» Мы открыли раздел использования. Остаток - 100%.

Я тогда объяснил группе так: бывает, что у самой компании какая-то модель перегружена, и агент начинает писать «выберите другую модель».

Что важно запомнить. Ошибка приходит со стороны сервиса. Лимит, подписка и настройки компьютера тут ни при чём. Поэтому чинить у себя в этот момент нечего.

У OpenAI такая перегрузка доходила и до публичного инцидента. 16 июня 2026 года статус-страница несколько часов показывала инцидент с ровно этим названием: «Codex "Selected Model is at Capacity" Error», затронуты были десктопное приложение, веб, API, CLI и расширение для редактора кода.

Как выглядит день, когда сбоят сразу несколько нейросетей и компании официально признают ошибки, я разбирал в посте «Сегодня снова штормило нейросети».

Как отличить перегрузку модели от кончившегося лимита?

В обычном API это вообще две разные ошибки с разными кодами. В справочнике кодов ошибок OpenAI лимит - это код 429 (слишком частые запросы или кончились кредиты), а перегрузка модели - 503, «модель временно перегружена», и совет там один: подождать и повторить. В приложении коды не показывают, но различие между лимитом и перегрузкой то же.

Вот таблица, по которой я разбираю ситуацию с группой за минуту:

Где смотреть остаток. В документации Codex сказано: текущие лимиты - в разделе использования в настройках, а в консольной версии их показывает команда /status. Там же совет: если расход выше ожиданий, стоит подумать о модели поменьше или о более узкой задаче.

Одна оговорка. Статус-страница OpenAI честно пишет, что доступность там считается в целом по всем тарифам и моделям. Зелёная страница не гарантирует, что твоя конкретная модель прямо сейчас свободна. Инцидент с таким названием на странице подтверждает перегрузку, а его отсутствие ничего не доказывает.

Что делать, если модель перегружена?

Порядок действий:

1. Скопируй промпт

   Текст задачи - в заметки или в файл. Если придётся начинать заново, он под рукой.

2. Подожди две-три минуты и повтори

   Перегрузка бывает короткой. Я так и говорил группе: оставьте, подождите, чуть позже он должен подхватиться.

3. Загляни в раздел использования

   Остаток есть - значит, дело не в лимите. Остатка нет - значит, лимит, и ждать надо сброса.

4. Переключись на запасную модель

   Модель уровнем ниже в том же списке. Для настройки и простых рабочих задач её может хватить.

5. Если не работает и запасная - займись другим

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

На том практикуме ошибка обошлась группе примерно в десять минут. Смена модели помогла, но не везде: у части людей ошибка продержалась дольше, и им оставалось ждать. Это нормально, и это ещё одна причина держать в голове шаг «займись другим».

Reconnecting и сбои сети: когда виновата связь

ИИ-агент держит долгую сессию: читает файлы, отправляет запросы, ждёт ответов. Если соединение рвётся, приложение показывает reconnecting и пытается восстановить связь. Иногда рядом всплывает и надпись про нагрузку на модель, и тут легко перепутать.

На том же практикуме переподключение в какой-то момент поймали многие сразу. Wi-Fi в зале работал нормально, поэтому я предположил проблему в общем канале и прокси: весь зал одновременно гонял агента через один выход в интернет. Это было предположение, а не подтверждённый диагноз. Чуть раньше кто-то спросил, что за предупреждение висит в окне, и мой ответ был короткий: тут сбои сетью бывают.

Что мы сделали, и это я советую повторять. Задачи, которые уже запущены, оставили работать. Сами ушли в теорию про память агента, а к результатам вернулись, когда всё отработало. Время группы не простаивало.

Если переподключение постоянное, это повод для разговора с IT. Перед практикумом или внедрением стоит заранее проверить доступ к сервисам агента с нескольких машин одновременно.

Почему агент просит подтверждение на каждом шаге?

Первые задачи с агентом нередко выглядят как зависание. Человек ждёт результата, а агент ждёт человека: внизу висит запрос с кнопкой «разрешить». На практикуме это заняло пару минут у всей группы, пока я не сказал простую вещь: надо ему разрешить.

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

И ещё одно. Запрос разрешения бывает хорошим знаком. Когда мы проверяли правила безопасности агента, правильным результатом как раз был вопрос: «можно ли открыть этот файл?» Спросил - значит, правила работают.

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

Какие свои ошибки выглядят как сбой сервиса?

Промпт в старом чате. Проверочный промпт для правил безопасности нужно запускать в новом чате, иначе проверка теряет смысл: в старом чате агент видит, как только что сам записал эти правила. На практикуме несколько человек запустили его в том же чате, и мне пришлось повторить три раза. Отсюда вывод для материалов: слова «новый чат» ставлю прямо в заголовок промпта, мелкой строки над ним мало.

Это частный случай общей гигиены. Чем длиннее чат, тем больше в нём лишнего, и тем хуже агент держит задачу. Подробно - в статье про гигиену контекстного окна.

Настройка без перезапуска. У части группы интерфейс был на английском. Язык меняется в общих настройках, но не всегда сразу: я предположил, что изменение применится после перезапуска приложения. А ещё внешний вид приложения у ведущего и у зала отличался: приложение обновляется, и у разных людей оно может выглядеть по-разному.

Если ни одна строка таблицы выше не подходит и агент просто крутится на одном месте, это уже другая проблема. Как её распознать и выйти из круга, я писал в материале агент ходит по кругу.

Запасная модель: строка, которую стоит записать заранее

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

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

Для работы в одиночку правило то же. Основная модель - для сложных задач, запасная уровнем ниже - для перегрузок и для рутины. Сверку таблиц, переименование файлов, черновик письма часто можно отдать ей: документация Codex как раз советует при высоком расходе брать модель поменьше. Как выбрать режим под задачу, я разбирал в статье чат, «Работа» или Codex.

Частые вопросы

Главный вывод

Многие ошибки агента читаются по тексту сообщения за минуту, если знать пять сторон: сервис, тариф, сеть, приложение и ты. Паника начинается, когда всё сваливается в одно «сломалось». Разложил по сторонам - и сразу видно, ждать, переключаться или нажать кнопку.

Практический шаг: прямо сейчас запиши себе одну строку - какая модель у тебя основная и какая запасная. В следующий раз ошибка займёт секунды.

У тебя такие ошибки чаще оказываются перегрузкой сервиса или кнопкой подтверждения, которую никто не заметил?