Ordre des modèles

Le sélecteur de modèles Codex ne conserve ni l’ordre de déclaration des fournisseurs ni celui des tableaux de modèles dans la configuration opencodex. L’ordre final découle des priorités du catalogue ; les modèles routés qui partagent la même priorité sont classés selon un ordre alphabétique déterministe.

La règle Codex s’applique

Le gestionnaire de modèles de Codex trie les entrées de catalogue visibles dans le sélecteur par priority, dans l’ordre croissant. Il ignore l’ordre du tableau du catalogue : avancer une entrée dans un tableau JSON généré ne la fait donc pas remonter dans le sélecteur. L’implémentation consigne cette contrainte directement dans src/codex/catalog/sync.ts.

opencodex contrôle donc la mise en avant en attribuant des priorités plus faibles, et non en s’appuyant sur la position dans le tableau. Sauf indication contraire, les priorités fixes et l’exemple détaillé ci-dessous décrivent un catalogue sans sélecteur de compte Codex admissible. Avec N sélecteurs admissibles, les priorités mises en avant utilisent N comme pas : un choix natif non qualifié de rang configuré i se décline en lignes de sélecteur aux priorités i * N + j, où j est la position du sélecteur en base zéro ; un choix routé utilise i * N ; un choix exact qualifié par un sélecteur utilise i * N + j pour ce sélecteur. Les lignes routées non sélectionnées sont déplacées hors de ces groupes de sélecteurs. Codex continue de n’annoncer que les cinq premières lignes visibles dans le sélecteur.

Sans ordre global du sélecteur, les priorités sans sélecteur pertinentes sont :

La direction API limite subagentModels à cinq entrées avec slice(0, 5) en src/server/management/agent-settings-routes.ts. Cela correspond à la surface Codex spawn_agent, qui annonce uniquement les cinq premiers remplacements de modèle. Les modèles en dehors de ces cinq peuvent toujours rester visibles dans le sélecteur principal et appelables par leur identifiant exact.

Départage des priorités identiques

Tous les modèles routés ordinaires ont la priorité 5 ; il faut donc les départager. Avant la création des entrées du catalogue, gatherRoutedModels() trie la liste des modèles routés par nom de fournisseur, puis par identifiant de modèle, dans les deux cas par ordre alphabétique (src/codex/catalog/provider-fetch.ts).

Cela signifie qu’aucun de ces détails de configuration ne modifie l’ordre final :

l’ordre de déclaration des clés dans l’objet providers ;
l’ordre des identifiants dans le tableau models d’un fournisseur.

orderForSubagents() utilise ensuite un tri stable pour placer les choix mis en avant au début de la liste, dans le même ordre que subagentModels. Les modèles non mis en avant conservent l’ordre relatif alphabétique fournisseur/identifiant établi précédemment (src/codex/catalog/sync.ts). Le classement présenté est également converti en priorités 0 à 4 lorsque les entrées sont construites, donc le tri prioritaire de Codex préserve ce premier séquence.

La visibilité est distincte de l’ordre

selectedModels et disabledModels déterminent quels modèles routés sont exposés ; ils ne contrôlent pas leur ordre. filterCatalogVisibleModels() convertit les deux sélections en recherches dans des Set et filtre la liste recueillie sans utiliser les tableaux comme rangs (src/codex/catalog/provider-fetch.ts).

Par conséquent, la réorganisation de selectedModels ou disabledModels n’a aucun effet sur la position du sélecteur. Cela peut change uniquement si un modèle est inclus.

Ordre effectif du sélecteur

Sans sélecteur de compte éligible et sans liste de sélection non vide, l’ordre résultant est le suivant :

Modèles dans l’ordre subagentModels configuré exactement, avec des priorités 0 à 4.
Tous les modèles acheminés restants, classés par ordre alphabétique par fournisseur, puis par identifiant de modèle, en priorité 5.
Modèles natifs non sélectionnés, poussés sous le bloc sélectionné lors de la fusion du catalogue.

Sans subagentModels, les modèles routés restent en priorité 5, les entrées natives GPT utilisent leur priorité (normalement 9 pour les entrées construites par opencodex), et le groupe routé reste provider/id alphabétique.

Exemple

Supposons que subagentModels contienne ces cinq identifiants dans cet ordre exact :

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

Le sélecteur commence ainsi :

| Position dans le sélecteur | Modèle | Priorité | Motif de cette position | | — : | — | — : | — | | 1 | gpt-5.5 | 0 | Première sélection subagentModels | | 2 | opencode-go/glm-5.2 | 1 | Deuxième sélection, même si son fournisseur trie après anthropic | | 3 | anthropic/claude-opus-4-6 | 2 | Troisième sélection | | 4 | gpt-5.6-sol | 3 | Quatrième sélection | | 5 | gpt-5.6-terra | 4 | Cinquième sélection | | 6 | anthropic/claude-fable-5 | 5 | Premier identifiant routé restant dans l’ordre alphabétique fournisseur/identifiant | | 7 en avant | Modèles acheminés restants | 5 | Fournisseur par ordre alphabétique, puis identifiant du modèle par ordre alphabétique | | Après les modèles routés | Modèles natifs restants | featured.length + 100 ou supérieur | Les modèles natifs non sélectionnés sont déplacés sous le bloc mis en avant |

Les cinq premières entrées sont les substitutions annoncées à spawn_agent ; les autres suivent l’ordre normal du sélecteur. Avec des sélecteurs de compte, la limite de cinq entrées s’applique après que les choix natifs non qualifiés ont été déclinés en groupes qualifiés par sélecteur.

Modification de l’ordre

Utilisez subagentModels pour choisir et ordonner les premiers modèles que Codex annonce également à spawn_agent. La page Sous-agents du tableau de bord peut réorganiser les identifiants natifs non qualifiés et les identifiants routés. Utilisez ocx agent subagents set ou modifiez la configuration OpenCodex pour définir des choix exacts de la forme <selector>/<native-openai-model> ; le tableau de bord conserve ces identifiants déjà enregistrés, même indisponibles. Configurez au maximum cinq identifiants. Avec des sélecteurs de compte, un choix natif non qualifié peut se décliner en plusieurs lignes de catalogue qualifiées par sélecteur ; les choix configurés et les lignes annoncées ne correspondent donc pas nécessairement un à un.

Utilisez modelPickerOrder pour ordonner uniquement l’affichage des lignes routées <provider>/<model> au-delà de ce bloc mis en avant :

{
  "modelPickerOrder": [
    "tyler/deepseek-v4-flash",
    "jd-chat/kimi-k3",
    "jd-chat/glm-5.2"
  ]
}

Les lignes routées indiquées apparaissent dans l’ordre configuré. Une ligne absente du tableau conserve sa priorité normale et reste donc devant la bande d’affichage de modelPickerOrder ; indiquez toutes les lignes routées dont vous souhaitez contrôler l’ordre relatif. Une ligne également présente dans subagentModels conserve sa priorité de mise en avant. Une liste contenant uniquement des identifiants routés conserve la position normale des lignes natives.

Pour ordonner tout le sélecteur, incluez un identifiant natif non qualifié :

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

Les lignes indiquées apparaissent d’abord dans l’ordre du tableau, puis les lignes absentes selon leur priorité naturelle. La correspondance est exacte : gpt-5.6-sol et openai/gpt-5.6-sol désignent deux lignes distinctes. Pour une ligne qualifiée par un compte, indiquez son identifiant complet, sélecteur inclus. Les formes brute et encodée du même identifiant routé sont acceptées, avec priorité aux correspondances exactes. Les entrées vides sont ignorées.

Migration : identifiants natifs dans les listes existantes

Auparavant, les identifiants natifs dans modelPickerOrder étaient ignorés. Une liste existante contenant un identifiant natif non qualifié ordonne désormais tout le sélecteur, y compris les lignes mises en avant. Supprimez ces identifiants pour conserver l’ancien comportement limité aux lignes routées. Les listes absentes, vides ou uniquement routées conservent leur comportement ; le calcul des candidats pour les consignes d’OpenCodex selon les priorités naturelles reste inchangé.

modelPickerOrder préserve le calcul d’OpenCodex qui retient jusqu’à cinq candidats préférés pour les consignes aux sous-agents, selon leur priorité naturelle. Chaque ligne déplacée conserve cette priorité séparément de son priority natif ; changer uniquement l’ordre du sélecteur ne doit pas modifier ce calcul. Cela ne restreint pas l’admissibilité d’un modèle désigné par son nom exact : la liste annoncée n’est pas une liste d’autorisation. Les contraintes d’authentification, de modèle, d’effort et de backend restent applicables.

Codex natif utilise le priority natif pour annoncer les cinq premiers modèles admissibles et visibles dans le sélecteur via spawn_agent, en V1 et en V2 lorsque les substitutions de modèle sont exposées. Ces cinq modèles peuvent donc changer avec l’ordre du sélecteur, même si les candidats préférés d’OpenCodex restent identiques. La V1 ne reçoit aucune injection de liste préférée d’OpenCodex. La V2 peut recevoir en plus des consignes fondées sur les priorités naturelles si l’état du catalogue client le permet ; ces consignes ne réordonnent pas la liste annoncée par l’outil natif.

disabledModels et selectedModels de chaque fournisseur restent des champs de visibilité, pas des contrôles d’ordre. Il n’existe aucun paramètre distinct modelOrder, providerOrder ou de carte de priorité.

Préréglages du sélecteur

Dans Models, choisissez Par défaut, A–Z par modèle, Par fournisseur ou Instantané des usages, puis appliquez l’ordre. Les identifiants routés actuellement disponibles et modelPickerOrderMode (alphabetical, provider, most-used) sont enregistrés. Les usages conservés sont lus une seule fois lors de l’application ; un rechargement ou un changement de modèles ne recalcule rien. Un ordre personnalisé ou natif complet reste intact jusqu’à une application explicite. Par défaut efface les deux champs même sans modèle disponible.

GET/PUT /api/subagent-models conserve les choix enregistrés désactivés ou absents dans chosen et available ; pickerAvailable contient les identifiants routés admissibles. Models envoie pickerOrder et pickerOrderMode, jamais models. Une sauvegarde du roster seul conserve l’ordre. Entrée invalide ou échec de sauvegarde préserve l’état précédent.

Les plages prioritaires et natives restent en place. Les préréglages affectent le catalogue Codex et les groupes routés de la découverte Claude, sans modifier le préfixe natif Claude ni les profils Desktop explicites ou la propriété des alias. Les rangs de guidage OpenCodex et les réglages de repli sont conservés ; les cinq choix annoncés nativement par Codex et le défaut recommandé peuvent changer. Aucun client n’est redémarré ; une actualisation peut rester en attente et nécessiter de rouvrir le client.