现状
main 分支内置的模型元数据只有 4 个文件、共 12 条:
文件
条目
assets/codex-models.json
gpt-5.5 / gpt-5.4 / gpt-5.4-mini / gpt-5.3-codex / gpt-5.2 / codex-auto-review(6)
assets/gpt56-model-metadata-compat.json
gpt-5.6-sol / terra / luna(3)
assets/astra-model-metadata-compat.json
gpt-6-astra(1)
assets/deepseek-model-metadata.json
deepseek-v4-flash / deepseek-v4-pro(2)
除 OpenAI 官方与 DeepSeek 外,所有主流模型(Kimi、Qwen、GLM、豆包、MiniMax、小米 MiMo、Grok、Gemini、StepFun、Mistral、NVIDIA、gpt-oss 等)没有任何内置元数据 。
影响
用户把这些模型名填进 model / 模型列表时:
上下文窗口被写低 :全部回落 gpt-5.5 模板的 272000——kimi-k3(真实 1M)、qwen3.8-max(1M)、MiniMax-M3(1M)、doubao-seed-evolving(1M)等全部中招,只能靠用户逐个手填 [1M] 后缀或每模型窗口补救
UI 显示裸 slug :Codex 界面显示 kimi-k3 而非 "Kimi K3",无描述、无思考档位(reasoning efforts)、无 Fast 档标记
输出上限 / 模态事实缺失 :max_output_tokens、input_modalities 等供应商字段全部没有
社区配置存在致命坑 :元数据缺失迫使用户粘贴社区流传的 model.js / JSON,其中 Kimi / Qwen / MiniMax 系广泛使用 apply_patch_tool_type: "function"——经源码核验(openai/codex 0.144+ 的 ApplyPatchToolType 枚举仅剩 Freeform),该值会导致 codex 整份 model_catalog_json 解析失败 、静默回落官方模型列表,用户自定义的窗口与元数据全部失效,且无任何报错提示
建议方案
内置主流供应商元数据 (15 家共 56 条,数据均已按官方文档核实):
供应商
条目
代表模型(真实窗口)
DeepSeek
5
deepseek-v4.1-flash、deepseek-flash(1M / 384K 输出)
Kimi
8
kimi-k3(1M)、kimi-k2.8-preview(1M)
Qwen
9
qwen3.8-max(1M)、qwen3-coder-plus(256K 原生 / YaRN 1M)
智谱 GLM
7
glm-5.3(1M)、glm-5.3-flashx(1M,200 tok/s)
豆包/火山
5
doubao-seed-evolving(1M)
MiniMax
3
MiniMax-M3(1M)、MiniMax-M2.7(204800)
小米 MiMo
4
mimo-v2.6-pro / flash(1M)
xAI Grok
3
grok-4.7 / 4.6(500K,low→xhigh 四档)
Google Gemini
4
gemini-3.8-flash、gemini-3.1-pro(1M / 64K 输出)
阶跃 StepFun
2
step-5-preview(1M)
Mistral / NVIDIA / Meta Muse / Thinking Machines / gpt-oss
6
mistral-medium-3.5、nemotron-3-ultra、muse-spark-1.3、inkling、gpt-oss-120b
接入 catalog 生成查找链 :compatibility_metadata_entry 增加供应商查找——slug 命中即把供应商事实(display_name / 思考档位 / 模态 / 输出上限)克隆进 catalog;未显式配置窗口时采用供应商真实窗口(与 [Question]: 供应商配置里配置模型的上下文窗口长度真的起作用了吗 #2191 语义一致:max_context_window 保留官方上限)
slug 匹配大小写不敏感 :供应商 Model Key 大小写不统一(如智谱官方 GLM-5.3-FlashX),上游 API 对大小写宽容,本地精确匹配会漏配
粘贴导入的 metadata 优先级保持更高 ,与现有导入机制完全兼容
本机验证数据
codex 0.147 debug models 实测:含 "function" 的 catalog 整份解析失败(unknown variant),全部 freeform 时正常加载
真实 Codex++ 切换 → ~/.codex catalog → Codex 桌面版 UI 全链路验证通过(UI 正确显示 "Kimi K3")
现状
main 分支内置的模型元数据只有 4 个文件、共 12 条:
assets/codex-models.jsonassets/gpt56-model-metadata-compat.jsonassets/astra-model-metadata-compat.jsonassets/deepseek-model-metadata.json除 OpenAI 官方与 DeepSeek 外,所有主流模型(Kimi、Qwen、GLM、豆包、MiniMax、小米 MiMo、Grok、Gemini、StepFun、Mistral、NVIDIA、gpt-oss 等)没有任何内置元数据。
影响
用户把这些模型名填进
model/ 模型列表时:[1M]后缀或每模型窗口补救kimi-k3而非 "Kimi K3",无描述、无思考档位(reasoning efforts)、无 Fast 档标记max_output_tokens、input_modalities等供应商字段全部没有apply_patch_tool_type: "function"——经源码核验(openai/codex 0.144+ 的ApplyPatchToolType枚举仅剩Freeform),该值会导致 codex 整份model_catalog_json解析失败、静默回落官方模型列表,用户自定义的窗口与元数据全部失效,且无任何报错提示建议方案
compatibility_metadata_entry增加供应商查找——slug 命中即把供应商事实(display_name / 思考档位 / 模态 / 输出上限)克隆进 catalog;未显式配置窗口时采用供应商真实窗口(与 [Question]: 供应商配置里配置模型的上下文窗口长度真的起作用了吗 #2191 语义一致:max_context_window保留官方上限)GLM-5.3-FlashX),上游 API 对大小写宽容,本地精确匹配会漏配本机验证数据
debug models实测:含"function"的 catalog 整份解析失败(unknown variant),全部freeform时正常加载~/.codexcatalog → Codex 桌面版 UI 全链路验证通过(UI 正确显示 "Kimi K3")