背景
OpenCodex 1.2.0(macOS app),接入 DashScope(阿里云百炼)Responses 兼容端点,添加自定义模型(如 qwen3.8-max)。
上游 /v1/responses 实测接受 "reasoning": {"effort": "max"}(返回 200),但 Desktop 模型选择器里该模型只能选到 low/medium/high,无法选 max/xhigh。
根因(读 dist 源码确认)
dist/services/catalog_sync.js 的兜底逻辑:provider 或 registry 没有显式发布推理档位时,catalog 默认只给 low/medium/high 三档。而 dashscope 等兼容端点的 /models 接口不返回推理档位信息,于是自定义模型永远落在三档上,max/xhigh 在到达上游之前就被裁剪。
当前只能手动改三个文件(未文档化)
~/.opencodex/custom_model_catalog.json — 在模型条目的 supported_reasoning_levels 数组里追加 {"effort": "max"}
~/.codex/models_cache.json — 同步修改相同字段
~/.opencodex/providers.json — 把模型条目从字符串改成对象形式:{"id": "qwen3.8-max", "reasoning_levels": "low,medium,high,xhigh,max"}(该形式会被 splitConfiguredModel → providerMetadataEntry 读取链路采纳,可防止后续 sync 覆盖回三档)
三处都改完后端到端验证通过:gateway 以 effort=max 转发,上游 200,不再降档。
建议
- 在 provider/模型配置表单上增加可选的「支持的推理档位」多选(low/medium/high/xhigh/max),写入 providers.json 并自动同步到 catalog/cache;
- 或者至少正式支持并文档化 providers.json 中模型条目的
reasoning_levels 对象形式(目前只能靠读 dist 源码才知道这个格式);
- catalog sync / cache 重建时保留用户显式声明的档位,不要回退到默认三档。
环境
- OpenCodex 1.2.0(/Applications/OpenCodex.app),macOS
- Provider:DashScope compatible-mode,Responses 端点
- 模型:qwen3.8-max(实测上游接受 max)
背景
OpenCodex 1.2.0(macOS app),接入 DashScope(阿里云百炼)Responses 兼容端点,添加自定义模型(如
qwen3.8-max)。上游
/v1/responses实测接受"reasoning": {"effort": "max"}(返回 200),但 Desktop 模型选择器里该模型只能选到 low/medium/high,无法选max/xhigh。根因(读 dist 源码确认)
dist/services/catalog_sync.js的兜底逻辑:provider 或 registry 没有显式发布推理档位时,catalog 默认只给low/medium/high三档。而 dashscope 等兼容端点的/models接口不返回推理档位信息,于是自定义模型永远落在三档上,max/xhigh在到达上游之前就被裁剪。当前只能手动改三个文件(未文档化)
~/.opencodex/custom_model_catalog.json— 在模型条目的supported_reasoning_levels数组里追加{"effort": "max"}~/.codex/models_cache.json— 同步修改相同字段~/.opencodex/providers.json— 把模型条目从字符串改成对象形式:{"id": "qwen3.8-max", "reasoning_levels": "low,medium,high,xhigh,max"}(该形式会被 splitConfiguredModel → providerMetadataEntry 读取链路采纳,可防止后续 sync 覆盖回三档)三处都改完后端到端验证通过:gateway 以
effort=max转发,上游 200,不再降档。建议
reasoning_levels对象形式(目前只能靠读 dist 源码才知道这个格式);环境