Порядок моделей

Селектор модели Codex не сохраняет порядок объявления провайдеров или массивов моделей в конфигурации opencodex. Итоговый порядок определяется приоритетами каталога, а маршрутизируемые модели с одинаковым приоритетом упорядочиваются детерминированно по алфавиту.

Правило, которое применяет Codex

Менеджер моделей Codex сортирует видимые в селекторе записи каталога по priority по возрастанию. Порядок массива каталога при этом отбрасывается, поэтому перемещение записи ближе к началу сгенерированного JSON-массива не передвигает её ближе к началу селектора. Это ограничение зафиксировано прямо в реализации, в src/codex/catalog/sync.ts.

Поэтому opencodex управляет размещением избранных моделей, назначая более низкие приоритеты, а не полагаясь на позицию в массиве. Фиксированные значения в этой таблице и пример ниже относятся к конфигурации без подходящих селекторов аккаунтов. При наличии N селекторов каждая выбранная bare native-модель с настроенным рангом i разворачивается в строки с приоритетами i * N + j, где j — позиция селектора с нуля. Выбранная routed-строка получает i * N, а точный account-qualified native-id — i * N + j для своего селектора. Codex по-прежнему объявляет только первые пять видимых строк picker’а. Невыбранные routed-строки сдвигаются за пределы этих selector-групп.

Приоритеты без селекторов:

Таблицы приоритетов и пример ниже описывают режим без сортировки всего селектора.

Запись каталога	Priority	Источник
subagentModels[i]	i (от 0 до 4)	Карта рангов избранных в src/codex/catalog/sync.ts
Остальные маршрутизируемые модели	5	Создание маршрутизируемых записей в src/codex/catalog/sync.ts
Нативные GPT-слаги по умолчанию	9	Создание нативных записей в src/codex/catalog/sync.ts
Невыбранные нативные модели при непустом списке избранных	Не менее featured.length + 100	Слияние нативного каталога в src/codex/catalog/sync.ts

API управления ограничивает subagentModels пятью записями через slice(0, 5) в src/server/management/agent-settings-routes.ts. Это соответствует поверхности Codex spawn_agent, которая объявляет только первые пять переопределений модели. Модели вне этой пятёрки по-прежнему могут оставаться видимыми в основном селекторе и вызываться по точному id.

Как упорядочиваются равные приоритеты

Все обычные маршрутизируемые модели имеют приоритет 5, поэтому им нужен дополнительный критерий. Прежде чем записи каталога будут построены, gatherRoutedModels() сортирует список маршрутизируемых моделей по имени провайдера, а затем по id модели — в обоих случаях по алфавиту (src/codex/catalog/provider-fetch.ts).

Это означает, что ни одна из следующих деталей конфигурации не влияет на итоговый порядок:

• порядок объявления ключей в объекте providers;
• порядок id в массиве models провайдера.

Затем orderForSubagents() стабильной сортировкой перемещает настроенные избранные модели в начало — в том же порядке, что и в subagentModels. Неизбранные модели сохраняют установленный ранее относительный алфавитный порядок «провайдер/id» (src/codex/catalog/sync.ts). При построении записей ранг избранных также преобразуется в приоритеты от 0 до 4, поэтому сортировка Codex по приоритету сохраняет эту ведущую последовательность.

Видимость и порядок — разные вещи

selectedModels и disabledModels решают, какие маршрутизируемые модели будут показаны; порядком они не управляют. filterCatalogVisibleModels() преобразует оба списка в Set для поиска и фильтрует собранный список, не используя массивы как ранги (src/codex/catalog/provider-fetch.ts).

Как следствие, перестановка элементов в selectedModels или disabledModels не влияет на позицию в селекторе. Она может изменить только сам факт включения модели.

Итоговая схема селектора

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

1. Модели точно в настроенном порядке subagentModels, с приоритетами от 0 до 4.
2. Все остальные маршрутизируемые модели, упорядоченные по алфавиту сначала по провайдеру, затем по id модели, с приоритетом 5.
3. Невыбранные нативные модели, сдвинутые ниже блока избранных при слиянии каталога.

Без subagentModels маршрутизируемые модели остаются с приоритетом 5, нативные GPT-записи используют обычный приоритет (для записей, построенных opencodex, обычно 9), а группа маршрутизируемых моделей сохраняет алфавитный порядок «провайдер/id».

Пример

Предположим, subagentModels содержит эти пять id именно в таком порядке:

subagentModels = [
  "gpt-5.5",
  "opencode-go/glm-5.2",
  "anthropic/claude-opus-4-6",
  "gpt-5.6-sol",
  "gpt-5.6-terra",
]

Селектор начинается так:

Позиция в селекторе	Модель	Priority	Почему она здесь
1	gpt-5.5	0	Первый выбор в subagentModels
2	opencode-go/glm-5.2	1	Второй выбор — даже при том, что его провайдер по алфавиту идёт после anthropic
3	anthropic/claude-opus-4-6	2	Третий выбор
4	gpt-5.6-sol	3	Четвёртый выбор
5	gpt-5.6-terra	4	Пятый выбор
6	anthropic/claude-fable-5	5	Первый из оставшихся маршрутизируемых id в алфавитном порядке «провайдер/id»
С 7-й	Остальные маршрутизируемые модели	5	По алфавиту по провайдеру, затем по id модели
После маршрутизируемых	Остальные нативные модели	featured.length + 100 или выше	Невыбранные нативные модели перемещаются ниже блока избранных

Первые пять записей — это переопределения, объявляемые spawn_agent; остальные продолжаются в обычном порядке селектора.

При наличии селекторов аккаунтов лимит в пять записей применяется после разворачивания bare native-выбора в selector-qualified группы.

Изменение порядка

Поддерживаемый способ настроить порядок ведущих моделей — переставить элементы subagentModels. Страница Sub-agents в дашборде позволяет менять порядок bare native- и routed-id. Конфигурация и ocx agent subagents set также принимают точные account-qualified id <selector>/<native-openai-model>, а дашборд сохраняет уже записанные ID, даже если они недоступны. Используйте не более пяти настроенных id. При активных селекторах одна bare native-модель может развернуться в несколько selector-qualified строк, поэтому число настроенных вариантов и объявляемых строк не обязательно совпадает.

modelPickerOrder управляет только порядком отображения в селекторе. Если список содержит лишь маршрутизируемые ID <provider>/<model>, указанные строки вне избранных попадают в отдельный диапазон отображения (1000 + i) в порядке списка. Неуказанные маршрутизируемые строки сохраняют обычный приоритет и остаются перед этим диапазоном. Строки из subagentModels сохраняют приоритет избранных, а нативные строки — обычные позиции. Укажите все маршрутизируемые строки, относительный порядок которых нужно задать.

Чтобы сортировать весь селектор, включите хотя бы один непустой ID каталога без /, например gpt-5.6-sol. Строка из одних пробелов не включает этот режим.

{
  "modelPickerOrder": ["gpt-5.6-sol", "opencode-go/glm-5.3"]
}

Указанные строки идут первыми в порядке массива, затем неуказанные — по исходному приоритету. Сопоставление учитывает точный ID каталога: gpt-5.6-sol и openai/gpt-5.6-sol — разные строки. Допускаются исходная и закодированная формы одного маршрутизируемого ID, но точное совпадение имеет приоритет над эквивалентным. Пустые строки и строки из одних пробелов игнорируются. Для строки конкретного аккаунта укажите полный ID с селектором.

Миграция: нативные ID в существующих списках

Раньше нативные ID без префикса в modelPickerOrder игнорировались. Теперь такой ID в существующем списке включает сортировку всего селектора, включая избранные строки. Удалите ID без префикса, чтобы сохранить прежнее поведение только для маршрутизируемых строк. Отсутствующий или пустой список, список из одних пробельных строк и список только с маршрутизируемыми ID работают как раньше.

modelPickerOrder сохраняет расчёт OpenCodex, который выбирает до пяти предпочтительных кандидатов для рекомендаций субагентам по исходному приоритету. У каждой перемещённой строки этот приоритет хранится отдельно от нативного priority; изменение только порядка селектора не должно менять результат этого расчёта. Оно также не ограничивает допустимость переопределения модели по точному имени: объявленный список не является списком разрешений. Существующие ограничения аутентификации, модели, effort и бэкенда продолжают действовать.

Нативный Codex использует нативный priority, чтобы объявить через spawn_agent первые пять допустимых моделей, видимых в селекторе. Это относится к V1 и к V2 с открытыми переопределениями моделей. Поэтому объявленные пять моделей могут меняться вместе с порядком селектора, даже если предпочтительные кандидаты OpenCodex не изменились. В V1 OpenCodex не внедряет список предпочтительных моделей. V2 может дополнительно получать рекомендации по исходным приоритетам, если состояние каталога клиента это допускает; эти рекомендации не меняют порядок списка, объявленного нативным инструментом.

disabledModels и selectedModels каждого провайдера по-прежнему управляют видимостью. Отдельных настроек modelOrder, providerOrder или карты приоритетов нет.

Пресеты в дашборде

На странице Models выберите порядок по умолчанию, по имени A–Z, по провайдеру или снимок использования и примените его. Сохраняются доступные маршрутизируемые ID и modelPickerOrderMode (alphabetical, provider, most-used). Сохранённая статистика читается один раз при применении; перезагрузка и изменения каталога не пересчитывают снимок. Пользовательский порядок, включая полный нативный, сохраняется до явного применения. Сброс удаляет оба поля даже при пустом списке моделей.

GET/PUT /api/subagent-models сохраняет отключённые и отсутствующие выбранные ID в chosen и available; pickerAvailable содержит допустимые маршрутизируемые ID. Models отправляет pickerOrder и pickerOrderMode, но не models. Сохранение только roster не меняет порядок; неверный ввод и ошибка записи сохраняют предыдущее состояние.

Диапазоны приоритетных и нативных моделей сохраняются. Порядок применяется к каталогу Codex и маршрутизируемым группам обнаружения Claude, сохраняя нативный префикс Claude, явные профили Desktop и владельцев alias. Ранги подсказок OpenCodex и настройки fallback не меняются, но пять вариантов, объявляемых нативным Codex, и рекомендуемая модель могут измениться. Сохранение не перезапускает клиенты; обновление может ожидать завершения, а старый каталог потребовать повторного открытия клиента.