【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载本文深入讲解 opencodexUniversal provider proxy如何决定 Codex 模型选择器picker中的模型顺序从 Codex 的priority升序排序规则、确定性字母序 tie-break到subagentModels/modelPickerOrder/selectedModels/disabledModels的各自职责以及 Dashboard「Sub-agents」与「Models」页面的排序控件。读完本文你将掌握 featured 模型置顶、路由模型字母序排列、显示级排序与完整 picker 排序的配置方法并能区分可见性过滤与排序两个容易混淆的概念。背景排序解释为何值得单独成文opencodex 通过 src/codex/catalog.ts 维护一份 Codex 可见的模型目录catalog并暴露给 Codex picker 与spawn_agent。此前三个用户触达面docs-site 文档站、GUI 的 Sub-agents 页面、GUI 的 Models 标签页都缺少对模型顺序到底由什么决定的说明导致用户误以为调整配置文件里providers对象的声明顺序或models数组的先后就能改变 picker 顺序。相关工作记录见 010_report.md最终在文档站新增了多语言文章model-ordering.md并在 GUI 两个页面加入了orderHint提示行把这一规则透明化。需要先记住的根本结论Codex 模型选择器不保留 provider 声明顺序也不保留模型数组顺序。最终顺序完全由目录条目的priority决定同优先级的路由模型则按确定性字母序排列。Codex 应用的排序规则Codex 的 models-manager 对 picker 可见的目录条目按priority升序排序并且丢弃目录数组本身的顺序。也就是说把某个条目在生成的 JSON 数组里往前提并不会让它出现在 picker 的更前面。该约束直接记录在src/codex/catalog/sync.ts的注释与实现中。因此 opencodex 控制 featured精选位置的方式是赋予更小的 priority 数值而不是依赖数组位置。除非特别说明下面给出的固定优先级与示例描述的都是没有任何合格 Codex 账户选择器account selector的目录。无选择器场景的优先级表目录条目优先级来源subagentModels[i]i0到4src/codex/catalog/sync.ts中的 featured 排名映射其他路由模型5src/codex/catalog/sync.ts中的路由条目创建列在modelPickerOrder中的非 featured 路由模型1000 isrc/codex/catalog/sync.ts中仅显示用的 picker 排名默认的原生 GPT slug9src/codex/catalog/sync.ts中的原生条目创建存在 featured 列表时未被选中的原生模型至少featured.length 100src/codex/catalog/sync.ts中的原生目录合并有账户选择器时的 stride 规则当存在N个合格选择器时featured 优先级以N为步长stride展开配置排名为i的裸原生选择会展开为选择器行优先级为i * N jj是该选择器从 0 开始的位置路由选择使用i * N精确指定选择器的选择使用i * N j。未被选中的路由行会被移出这些选择器分组。Codex 仍然只对外通告前五个 picker 可见行。5 选上限管理 API 用slice(0, 5)把subagentModels限制为五个条目见 src/server/management/agent-settings-routes.ts。这与 Codexspawn_agent表面一致——它只通告前五个模型覆盖项。这五个之外的其他模型仍可在主 picker 中保持可见并可通过其精确 id 调用。同优先级 tie 的顺序确定性字母序所有普通路由模型优先级都是5所以必须有一个 tie-breaker。在目录条目构建之前gatherRoutedModels()会先把路由模型列表按provider 名、再按model id分别做字母序排序src/codex/catalog/provider-fetch.ts。这意味着以下两个配置细节都不会改变最终顺序providers对象中键的声明顺序某个 provider 的models数组中 id 的先后顺序。随后orderForSubagents()使用稳定排序把配置好的 featured 选择按subagentModels中的顺序移到最前非 featured 模型保持先前确立的 provider/id 字母序相对顺序src/codex/catalog/sync.ts实现位于 src/codex/catalog/build-entries.ts。featured 排名在构建条目时也会被转换为0到4的优先级因此 Codex 的优先级排序会保留这段领先序列。从源码看orderForSubagents用rank映射featured.map((id, i) [id, i])并兼容三种 id 形式别名、provider/id、编码 slug未命中 featured 的条目返回Number.MAX_SAFE_INTEGER从而稳定排在末尾——这正是featured 置顶、其余保持原相对顺序的实现基础。可见性与排序是两回事selectedModels与disabledModels决定哪些路由模型被暴露它们不是排序控件。filterCatalogVisibleModels()把两者都转换为Set查询然后过滤已收集的列表绝不把数组当排名用src/codex/catalog/provider-fetch.ts实现位于 src/codex/catalog/model-visibility.ts。因此重排selectedModels或disabledModels中的元素对 picker 位置没有任何影响只会改变模型是否被包含。disabledModels与各 provider 的selectedModels始终是可见性字段项目里不存在独立的modelOrder、providerOrder或优先级映射配置项——这是一个诚实的局限。有效的 picker 排列模式在无账户选择器且 featured 列表非空时最终顺序为按subagentModels精确配置顺序排列的模型优先级0到4其余全部路由模型按 provider 再按 model id 字母序优先级5未选中的原生模型在目录合并时被压到 featured 块之下。若没有subagentModels路由模型保持在优先级5原生 GPT 条目使用其正常优先级通常为 opencodex 构建条目的9路由组仍保持 provider/id 字母序。示例假设subagentModels按此精确顺序包含五个 idsubagentModels [ gpt-5.5, opencode-go/glm-5.2, anthropic/claude-opus-4-6, gpt-5.6-sol, gpt-5.6-terra, ]picker 起始排列如下Picker 位置模型优先级出现原因1gpt-5.50第一个subagentModels选择2opencode-go/glm-5.21第二个选择即使其 provider 在anthropic之后排序3anthropic/claude-opus-4-62第三个选择4gpt-5.6-sol3第四个选择5gpt-5.6-terra4第五个选择6anthropic/claude-fable-55provider/id 字母序中第一个剩余路由 id7 起其余路由模型5先 provider 字母序再 model id 字母序路由模型之后其余原生模型featured.length 100或更高未选中的原生模型被移到 featured 块之下前五个条目即通告给spawn_agent的覆盖项其余按正常 picker 顺序继续。有账户选择器时五条上限在裸原生选择展开为选择器限定组之后应用。修改顺序的两种手段用subagentModels控制头部使用subagentModels选择并排列 Codex 同时通告给spawn_agent的头部模型。Dashboard 的Sub-agents页面可以重排裸原生与路由 id也可以用ocx agent subagents set或直接编辑 opencodex 配置来精确指定selector/native-openai-model选择Dashboard 保存后会保留这些 id包括当前不可用的选择。最多配置五个 id。注意有账户选择器时一个裸原生选择可能展开为多行选择器限定的目录条目因此配置的选择与通告的行未必一一对应。如果某个账户门控的原生模型没有合格账户支持请求会以无效模型选择失败如果存在支持账户但暂时耗尽或不可用则以可重试的速率限制失败。这两种状态永远不会被报告为无效 API key——请改选其他可用模型或等待有能力的账户配额窗口重新开放。用modelPickerOrder控制显示级排序modelPickerOrder用于对 featured 块之外的路由provider/model行做仅显示排序{ modelPickerOrder: [ tyler/deepseek-v4-flash, jd-chat/kimi-k3, jd-chat/glm-5.2 ] }列出的路由行按配置顺序出现。被省略的路由行保持其正常优先级因此会排在modelPickerOrder显示带之前——想控制相对位置就必须把每个路由行都列出来。同时出现在subagentModels中的行保持其 featured 优先级。若列表只含路由行原生行保持正常位置。要排序完整 picker请加入一个裸原生 id{ modelPickerOrder: [gpt-5.6-sol, opencode-go/glm-5.3] }列出的行按数组顺序排在最前未列出的行按自然优先级随后排列。匹配使用精确目录 idgpt-5.6-sol与openai/gpt-5.6-sol是两行。同一路由 id 的原始拼写与编码拼写都可接受精确匹配优先。空条目被忽略。账户限定的行需要在列表中使用其选择器限定 id。从源码看orderForModelPickersrc/codex/catalog/build-entries.ts通过检查列表中是否存在不含/的 slug 来判定这是否为完整排序complete模式完整模式下未列出的行按pickerOrder.length natural排名而仅路由模式下未列出的行保持在 featured 带内。sync.ts中构建条目时还会把非 featured 行的原始priority备份到SPAWN_PRIORITY_FIELD再覆盖为1000 i的显示优先级——这是显示排序不影响 spawn_agent 通告优先级的关键机制。迁移注意现有排序中的原生 id此前modelPickerOrder中的原生 id 会被忽略。现在包含裸原生 id 的既有列表会激活完整 picker 排序含 featured 行。要恢复旧的路由专用行为请移除裸原生 id。未设置、空列表与纯路由列表均保持原行为OpenCodex 的自然优先级引导候选计算不变。modelPickerOrder保留 OpenCodex 对最多五个首选候选的自然优先级计算。每一被移动的行保留其独立于原生priority的自然优先级仅改变 picker 顺序不得改变该项 OpenCodex 计算。它也不限制精确名称模型覆盖的资格原生通告列表不是 allowlist既有的认证、模型/effort 与后端约束依然生效。原生 Codex 使用原生priority在 V1 及 V2当模型覆盖暴露时选出spawn_agent通告的前五个合格 picker 可见模型。因此这通告的五个可能随 picker 顺序变化即使 OpenCodex 的首选候选不变。V1 不接收 OpenCodex 首选名册注入V2 在客户端目录状态允许时可能额外接收 OpenCodex 的自然优先级引导但该引导不会重排原生工具的通告列表。Dashboard 的 picker 预设在Models页面选择Default、A–Z by model、Group by provider或Most used snapshot然后Apply order。这会保存当前可见的路由 id 与modelPickerOrderModealphabetical、provider或most-used。Most used 在应用时读取一次全部保留用量重新加载时恢复快照不再抓取用量。新增或移除的模型不会自动重算它。手动保存的顺序包括完整/原生顺序在你显式应用替换前保持不变。Default 会清空两个 picker 字段即使没有路由模型可用。这些控件使用GET/PUT /api/subagent-modelschosen与available保留已保存的名册选择包括被禁用或缺失的模型pickerAvailable仅含合格的路由目录 id。Models 页面发送pickerOrder与pickerOrderMode从不发送models。仅名册的保存会保留 picker 设置。无效的联合更新与持久化失败会保持之前的 picker/名册状态不变。从 src/server/management/agent-settings-routes.ts 的实现看PUT /api/subagent-models对pickerOrder校验了非空字符串、去重与 trimpickerOrderMode只接受alphabetical、provider、most-used或null且pickerOrderMode必须与pickerOrder同时更新否则返回 400——这正是模式必须配对顺序的契约来源。仅路由的预设保留既有的 featured/原生优先级带。它们影响 Codex 目录与 Claude discovery 的路由组Claude 的原生前缀与显式 Desktop profile/alias 归属不变。OpenCodex 引导排名与配置的 fallback 设置保留但原生 Codex 的通告五个与推荐默认可能随显示优先级变化。保存不会重启客户端目录刷新可能仍在挂起持有旧目录的客户端可能需要重新打开。自定义路由顺序在 Models 页面选择Custom order加载全新的路由快照。将可拖动的行拖到另一行之前或使用其 Up/Down 按钮然后Save draft。featured 路由行保持在配置排名的前端且不可移动。原生行不显示这不是完整原生 picker 的预览。存活的已保存行保持相对顺序新候选跟随当前候选列表。每次保存都发送完整路由列表不改变 featured 名册。包含裸原生 id 的顺序会保持受保护直到你显式应用路由预设或 Default。仅选择不同选项不会替换它。未知的 featured 状态会阻止编辑。保存前编辑器会检查全新快照若发现变化会保留你的草稿并阻止保存直到Reload and discard draft加载当前设置。请求失败保留草稿。已接受的保存仍可能有挂起的目录刷新再次编辑前请重新加载。编辑器还要求每个路由候选都有无歧义的模型身份。若模型目录不完整请在编辑前刷新 Models 页面仅重载 picker 设置无法恢复缺失的目录身份。featured 选择精确匹配且不修剪重复选择使用其最后配置的位置规范 id 优先于原始 id。顺序解释的三个用户触达面本次工作把以上规则同时落地到三个界面详见 010_report.mddocs-site 文档站新增文章 model-ordering.md英文并同步了韩文 ko 版、中文 zh-cn 版 以及 fr/ja/ru/tr/zh-tw 等语言版本侧边栏入口位于docs-site/astro.config.mjs。GUI Sub-agents 页面gui/src/pages/Subagents.tsx在 Featured 列表上方新增orderHint提示行说明当前顺序即 picker 1-5 顺序加spawn_agent候选。GUI Models 标签页gui/src/pages/Models.tsx在模型列表上方新增orderHint说明——subagent 选择优先、随后是路由 provider/id 字母序、再到原生可见性开关仅做过滤。i18n key 在 en/ko/zh/de 中均有提供。小结与实操清单想控制 picker 头部顺序配置subagentModels最多 5 个或使用 Dashboard Sub-agents 页面重排。想控制 featured 块之外路由行的显示顺序配置modelPickerOrder需要完整排序时加入裸原生 id。想理解为什么我的配置顺序没生效因为 Codex 按priority升序排序数组顺序被丢弃路由模型按 provider/id 字母序 tie-break。想隐藏/暴露模型用selectedModels/disabledModels——它们是过滤不是排序。别忘了诚实局限目前不存在modelOrder/providerOrder/ 优先级映射配置modelPickerOrder是显示级手段不改变spawn_agent通告的自然优先级计算。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐Hetty scope优先级规则执行顺序完全指南Hetty scope优先级规则执行顺序完全指南 你是否曾在使用Hetty进行安全测试时遇到过scope规则不按预期匹配的情况明明配置了拦截规则却无法捕获网络安全应用安全AdGuardHome规则执行顺序优先级调整完全指南AdGuardHome规则执行顺序优先级调整完全指南 你是否遇到过这样的困扰明明添加了广告过滤规则却依然看到弹窗或者自定义规则与预设规则冲突导致某些网站网络后端网络安全Sinatra配置优先级规则理解设置加载顺序Sinatra配置优先级规则理解设置加载顺序 在使用Sinatra开发Web应用时正确理解配置的加载顺序至关重要。配置冲突是导致应用行为异常的常见原因本文后端Web框架创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载本文深入讲解 opencodexUniversal provider proxy如何决定 Codex 模型选择器picker中的模型顺序从 Codex 的priority升序排序规则、确定性字母序 tie-break到subagentModels/modelPickerOrder/selectedModels/disabledModels的各自职责以及 Dashboard「Sub-agents」与「Models」页面的排序控件。读完本文你将掌握 featured 模型置顶、路由模型字母序排列、显示级排序与完整 picker 排序的配置方法并能区分可见性过滤与排序两个容易混淆的概念。背景排序解释为何值得单独成文opencodex 通过 src/codex/catalog.ts 维护一份 Codex 可见的模型目录catalog并暴露给 Codex picker 与spawn_agent。此前三个用户触达面docs-site 文档站、GUI 的 Sub-agents 页面、GUI 的 Models 标签页都缺少对模型顺序到底由什么决定的说明导致用户误以为调整配置文件里providers对象的声明顺序或models数组的先后就能改变 picker 顺序。相关工作记录见 010_report.md最终在文档站新增了多语言文章model-ordering.md并在 GUI 两个页面加入了orderHint提示行把这一规则透明化。需要先记住的根本结论Codex 模型选择器不保留 provider 声明顺序也不保留模型数组顺序。最终顺序完全由目录条目的priority决定同优先级的路由模型则按确定性字母序排列。Codex 应用的排序规则Codex 的 models-manager 对 picker 可见的目录条目按priority升序排序并且丢弃目录数组本身的顺序。也就是说把某个条目在生成的 JSON 数组里往前提并不会让它出现在 picker 的更前面。该约束直接记录在src/codex/catalog/sync.ts的注释与实现中。因此 opencodex 控制 featured精选位置的方式是赋予更小的 priority 数值而不是依赖数组位置。除非特别说明下面给出的固定优先级与示例描述的都是没有任何合格 Codex 账户选择器account selector的目录。无选择器场景的优先级表目录条目优先级来源subagentModels[i]i0到4src/codex/catalog/sync.ts中的 featured 排名映射其他路由模型5src/codex/catalog/sync.ts中的路由条目创建列在modelPickerOrder中的非 featured 路由模型1000 isrc/codex/catalog/sync.ts中仅显示用的 picker 排名默认的原生 GPT slug9src/codex/catalog/sync.ts中的原生条目创建存在 featured 列表时未被选中的原生模型至少featured.length 100src/codex/catalog/sync.ts中的原生目录合并有账户选择器时的 stride 规则当存在N个合格选择器时featured 优先级以N为步长stride展开配置排名为i的裸原生选择会展开为选择器行优先级为i * N jj是该选择器从 0 开始的位置路由选择使用i * N精确指定选择器的选择使用i * N j。未被选中的路由行会被移出这些选择器分组。Codex 仍然只对外通告前五个 picker 可见行。5 选上限管理 API 用slice(0, 5)把subagentModels限制为五个条目见 src/server/management/agent-settings-routes.ts。这与 Codexspawn_agent表面一致——它只通告前五个模型覆盖项。这五个之外的其他模型仍可在主 picker 中保持可见并可通过其精确 id 调用。同优先级 tie 的顺序确定性字母序所有普通路由模型优先级都是5所以必须有一个 tie-breaker。在目录条目构建之前gatherRoutedModels()会先把路由模型列表按provider 名、再按model id分别做字母序排序src/codex/catalog/provider-fetch.ts。这意味着以下两个配置细节都不会改变最终顺序providers对象中键的声明顺序某个 provider 的models数组中 id 的先后顺序。随后orderForSubagents()使用稳定排序把配置好的 featured 选择按subagentModels中的顺序移到最前非 featured 模型保持先前确立的 provider/id 字母序相对顺序src/codex/catalog/sync.ts实现位于 src/codex/catalog/build-entries.ts。featured 排名在构建条目时也会被转换为0到4的优先级因此 Codex 的优先级排序会保留这段领先序列。从源码看orderForSubagents用rank映射featured.map((id, i) [id, i])并兼容三种 id 形式别名、provider/id、编码 slug未命中 featured 的条目返回Number.MAX_SAFE_INTEGER从而稳定排在末尾——这正是featured 置顶、其余保持原相对顺序的实现基础。可见性与排序是两回事selectedModels与disabledModels决定哪些路由模型被暴露它们不是排序控件。filterCatalogVisibleModels()把两者都转换为Set查询然后过滤已收集的列表绝不把数组当排名用src/codex/catalog/provider-fetch.ts实现位于 src/codex/catalog/model-visibility.ts。因此重排selectedModels或disabledModels中的元素对 picker 位置没有任何影响只会改变模型是否被包含。disabledModels与各 provider 的selectedModels始终是可见性字段项目里不存在独立的modelOrder、providerOrder或优先级映射配置项——这是一个诚实的局限。有效的 picker 排列模式在无账户选择器且 featured 列表非空时最终顺序为按subagentModels精确配置顺序排列的模型优先级0到4其余全部路由模型按 provider 再按 model id 字母序优先级5未选中的原生模型在目录合并时被压到 featured 块之下。若没有subagentModels路由模型保持在优先级5原生 GPT 条目使用其正常优先级通常为 opencodex 构建条目的9路由组仍保持 provider/id 字母序。示例假设subagentModels按此精确顺序包含五个 idsubagentModels [ gpt-5.5, opencode-go/glm-5.2, anthropic/claude-opus-4-6, gpt-5.6-sol, gpt-5.6-terra, ]picker 起始排列如下Picker 位置模型优先级出现原因1gpt-5.50第一个subagentModels选择2opencode-go/glm-5.21第二个选择即使其 provider 在anthropic之后排序3anthropic/claude-opus-4-62第三个选择4gpt-5.6-sol3第四个选择5gpt-5.6-terra4第五个选择6anthropic/claude-fable-55provider/id 字母序中第一个剩余路由 id7 起其余路由模型5先 provider 字母序再 model id 字母序路由模型之后其余原生模型featured.length 100或更高未选中的原生模型被移到 featured 块之下前五个条目即通告给spawn_agent的覆盖项其余按正常 picker 顺序继续。有账户选择器时五条上限在裸原生选择展开为选择器限定组之后应用。修改顺序的两种手段用subagentModels控制头部使用subagentModels选择并排列 Codex 同时通告给spawn_agent的头部模型。Dashboard 的Sub-agents页面可以重排裸原生与路由 id也可以用ocx agent subagents set或直接编辑 opencodex 配置来精确指定selector/native-openai-model选择Dashboard 保存后会保留这些 id包括当前不可用的选择。最多配置五个 id。注意有账户选择器时一个裸原生选择可能展开为多行选择器限定的目录条目因此配置的选择与通告的行未必一一对应。如果某个账户门控的原生模型没有合格账户支持请求会以无效模型选择失败如果存在支持账户但暂时耗尽或不可用则以可重试的速率限制失败。这两种状态永远不会被报告为无效 API key——请改选其他可用模型或等待有能力的账户配额窗口重新开放。用modelPickerOrder控制显示级排序modelPickerOrder用于对 featured 块之外的路由provider/model行做仅显示排序{ modelPickerOrder: [ tyler/deepseek-v4-flash, jd-chat/kimi-k3, jd-chat/glm-5.2 ] }列出的路由行按配置顺序出现。被省略的路由行保持其正常优先级因此会排在modelPickerOrder显示带之前——想控制相对位置就必须把每个路由行都列出来。同时出现在subagentModels中的行保持其 featured 优先级。若列表只含路由行原生行保持正常位置。要排序完整 picker请加入一个裸原生 id{ modelPickerOrder: [gpt-5.6-sol, opencode-go/glm-5.3] }列出的行按数组顺序排在最前未列出的行按自然优先级随后排列。匹配使用精确目录 idgpt-5.6-sol与openai/gpt-5.6-sol是两行。同一路由 id 的原始拼写与编码拼写都可接受精确匹配优先。空条目被忽略。账户限定的行需要在列表中使用其选择器限定 id。从源码看orderForModelPickersrc/codex/catalog/build-entries.ts通过检查列表中是否存在不含/的 slug 来判定这是否为完整排序complete模式完整模式下未列出的行按pickerOrder.length natural排名而仅路由模式下未列出的行保持在 featured 带内。sync.ts中构建条目时还会把非 featured 行的原始priority备份到SPAWN_PRIORITY_FIELD再覆盖为1000 i的显示优先级——这是显示排序不影响 spawn_agent 通告优先级的关键机制。迁移注意现有排序中的原生 id此前modelPickerOrder中的原生 id 会被忽略。现在包含裸原生 id 的既有列表会激活完整 picker 排序含 featured 行。要恢复旧的路由专用行为请移除裸原生 id。未设置、空列表与纯路由列表均保持原行为OpenCodex 的自然优先级引导候选计算不变。modelPickerOrder保留 OpenCodex 对最多五个首选候选的自然优先级计算。每一被移动的行保留其独立于原生priority的自然优先级仅改变 picker 顺序不得改变该项 OpenCodex 计算。它也不限制精确名称模型覆盖的资格原生通告列表不是 allowlist既有的认证、模型/effort 与后端约束依然生效。原生 Codex 使用原生priority在 V1 及 V2当模型覆盖暴露时选出spawn_agent通告的前五个合格 picker 可见模型。因此这通告的五个可能随 picker 顺序变化即使 OpenCodex 的首选候选不变。V1 不接收 OpenCodex 首选名册注入V2 在客户端目录状态允许时可能额外接收 OpenCodex 的自然优先级引导但该引导不会重排原生工具的通告列表。Dashboard 的 picker 预设在Models页面选择Default、A–Z by model、Group by provider或Most used snapshot然后Apply order。这会保存当前可见的路由 id 与modelPickerOrderModealphabetical、provider或most-used。Most used 在应用时读取一次全部保留用量重新加载时恢复快照不再抓取用量。新增或移除的模型不会自动重算它。手动保存的顺序包括完整/原生顺序在你显式应用替换前保持不变。Default 会清空两个 picker 字段即使没有路由模型可用。这些控件使用GET/PUT /api/subagent-modelschosen与available保留已保存的名册选择包括被禁用或缺失的模型pickerAvailable仅含合格的路由目录 id。Models 页面发送pickerOrder与pickerOrderMode从不发送models。仅名册的保存会保留 picker 设置。无效的联合更新与持久化失败会保持之前的 picker/名册状态不变。从 src/server/management/agent-settings-routes.ts 的实现看PUT /api/subagent-models对pickerOrder校验了非空字符串、去重与 trimpickerOrderMode只接受alphabetical、provider、most-used或null且pickerOrderMode必须与pickerOrder同时更新否则返回 400——这正是模式必须配对顺序的契约来源。仅路由的预设保留既有的 featured/原生优先级带。它们影响 Codex 目录与 Claude discovery 的路由组Claude 的原生前缀与显式 Desktop profile/alias 归属不变。OpenCodex 引导排名与配置的 fallback 设置保留但原生 Codex 的通告五个与推荐默认可能随显示优先级变化。保存不会重启客户端目录刷新可能仍在挂起持有旧目录的客户端可能需要重新打开。自定义路由顺序在 Models 页面选择Custom order加载全新的路由快照。将可拖动的行拖到另一行之前或使用其 Up/Down 按钮然后Save draft。featured 路由行保持在配置排名的前端且不可移动。原生行不显示这不是完整原生 picker 的预览。存活的已保存行保持相对顺序新候选跟随当前候选列表。每次保存都发送完整路由列表不改变 featured 名册。包含裸原生 id 的顺序会保持受保护直到你显式应用路由预设或 Default。仅选择不同选项不会替换它。未知的 featured 状态会阻止编辑。保存前编辑器会检查全新快照若发现变化会保留你的草稿并阻止保存直到Reload and discard draft加载当前设置。请求失败保留草稿。已接受的保存仍可能有挂起的目录刷新再次编辑前请重新加载。编辑器还要求每个路由候选都有无歧义的模型身份。若模型目录不完整请在编辑前刷新 Models 页面仅重载 picker 设置无法恢复缺失的目录身份。featured 选择精确匹配且不修剪重复选择使用其最后配置的位置规范 id 优先于原始 id。顺序解释的三个用户触达面本次工作把以上规则同时落地到三个界面详见 010_report.mddocs-site 文档站新增文章 model-ordering.md英文并同步了韩文 ko 版、中文 zh-cn 版 以及 fr/ja/ru/tr/zh-tw 等语言版本侧边栏入口位于docs-site/astro.config.mjs。GUI Sub-agents 页面gui/src/pages/Subagents.tsx在 Featured 列表上方新增orderHint提示行说明当前顺序即 picker 1-5 顺序加spawn_agent候选。GUI Models 标签页gui/src/pages/Models.tsx在模型列表上方新增orderHint说明——subagent 选择优先、随后是路由 provider/id 字母序、再到原生可见性开关仅做过滤。i18n key 在 en/ko/zh/de 中均有提供。小结与实操清单想控制 picker 头部顺序配置subagentModels最多 5 个或使用 Dashboard Sub-agents 页面重排。想控制 featured 块之外路由行的显示顺序配置modelPickerOrder需要完整排序时加入裸原生 id。想理解为什么我的配置顺序没生效因为 Codex 按priority升序排序数组顺序被丢弃路由模型按 provider/id 字母序 tie-break。想隐藏/暴露模型用selectedModels/disabledModels——它们是过滤不是排序。别忘了诚实局限目前不存在modelOrder/providerOrder/ 优先级映射配置modelPickerOrder是显示级手段不改变spawn_agent通告的自然优先级计算。赞分享【免费下载链接】opencodexUniversal provider proxy for OpenAI Codex Claude Code — use any LLM (Claude, Gemini, Grok, DeepSeek, Ollama…) with Codex CLI, App, SDK, and Claude Code项目地址https://gitcode.com/gh_mirrors/ope/opencodex点击查看免费下载相关推荐Hetty scope优先级规则执行顺序完全指南Hetty scope优先级规则执行顺序完全指南 你是否曾在使用Hetty进行安全测试时遇到过scope规则不按预期匹配的情况明明配置了拦截规则却无法捕获网络安全应用安全AdGuardHome规则执行顺序优先级调整完全指南AdGuardHome规则执行顺序优先级调整完全指南 你是否遇到过这样的困扰明明添加了广告过滤规则却依然看到弹窗或者自定义规则与预设规则冲突导致某些网站网络后端网络安全Sinatra配置优先级规则理解设置加载顺序Sinatra配置优先级规则理解设置加载顺序 在使用Sinatra开发Web应用时正确理解配置的加载顺序至关重要。配置冲突是导致应用行为异常的常见原因本文后端Web框架创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
