CLIProxyAPI Codex reasoning effort alias 配置复盘

CLIProxyAPI Codex reasoning effort alias 配置复盘

摘要

2026-05-30 在本机 CLIProxyAPI v7.1.23 上验证并落地了一组面向 Codex OAuth provider 的“可见模型别名 + payload override”配置，用于把同一个上游模型暴露成不同 reasoning effort 档位。

最终 live 配置新增三个客户端可见 alias：

• gpt-5.5-high → 上游 gpt-5.5，reasoning.effort: high
• gpt-5.4-mini-high → 上游 gpt-5.4-mini，reasoning.effort: high
• gpt-5.5-xhigh → 上游 gpt-5.5，reasoning.effort: xhigh

其中 gpt-5.4-high 曾被尝试，但当前 Codex ChatGPT 账号不支持 gpt-5.4，实测返回 400，随后改为 gpt-5.4-mini-high 并验证通过。

背景问题

原问题是：能否在模型选择层看到或控制“思考等级”，以及能否给 CPA 设置类似 reasoning_effort = "high"。

关键判断：

1. CPA / Hermes 模型列表本身不会天然展示一次请求真实使用的 reasoning effort。
2. 对 Codex / Responses 协议，更合适的字段不是 Chat Completions 常见的 reasoning_effort，而是嵌套结构：

1. CLIProxyAPI v7.1.23 的 config.example.yaml 已明确支持 payload override，并给出 Codex 示例：

因此，本次采用 CPA 原生机制：oauth-model-alias 暴露新模型名，payload.override 针对这些 alias 注入 reasoning effort。

最终 live 配置片段

文件：/home/ht/cli-proxy-api/config.yaml

说明：

• fork: true 用来保留原始模型，同时额外暴露 alias。
• payload rule 使用 alias 名匹配，实测有效。
• protocol: codex 很重要，避免误伤其他 provider 或 OpenAI-compatible upstream。

验证过程

1. staging 先行

没有直接改 live 后盲测，而是基于 live config 生成临时 staging 配置，监听 127.0.0.1:18317：

这种方式可以在不影响 live 8317 的前提下验证：

• 配置能否解析；
• /v1/models 是否出现新 alias；
• /v1/chat/completions 是否接受该 alias；
• payload override 是否不导致上游 400。

2. 模型列表验证

gpt-5.5-high、gpt-5.4-mini-high、gpt-5.5-xhigh 均能在 /v1/models 里出现。

示例 live 验证结果：

3. smoke 请求验证

gpt-5.5-high：

gpt-5.4-mini-high：

gpt-5.5-xhigh：

xhigh 目前可以被上游接受，没有 400。但短 smoke 不足以证明它一定比 high 更强，只能证明参数链路可用。

4. high / low / default 对比实验

为了判断 payload override 是否有实际效果，曾在 staging 临时加入 gpt-5.5-low，对同一问题测试：

结论：在该测试中，high 的 reasoning token 明显高于默认和 low，说明 alias + payload override 对上游请求确实产生了影响。

注意：reasoning token 会受题目、采样、缓存和上游策略影响，不能用单次 token 数做严格性能评估，但可作为配置链路有效性的证据。

失败案例：gpt-5.4-high

最初尝试：

模型列表中能看到 gpt-5.4-high，但请求失败：

这说明：

• alias 和 payload override 配置层有效；
• 失败根因是当前 Codex ChatGPT OAuth 账号不支持 gpt-5.4；
• 不应误判为 CPA payload override 不生效。

最终将其替换为：

并通过 live smoke。

配置备份

本轮关键备份：

推荐操作规范

以后给 CPA 增加 reasoning 档位模型时，建议按以下顺序：

1. 先读 /home/ht/cli-proxy-api/config.example.yaml，确认当前版本支持的 payload 写法。
2. 复制 live config 到 staging config，改端口为 18317 或其他空闲端口。
3. 在 oauth-model-alias.codex 里新增 alias，优先 fork: true。
4. 在 payload.override 里只对新 alias 注入参数，不要一上来对 gpt-* 全局覆盖。
5. staging 启动后先查 /v1/models，再发最小 /v1/chat/completions 请求。
6. 若上游返回模型不支持，先换上游模型名，不要直接怀疑 CPA。
7. 验证通过后再备份并写入 live config。
8. 确认 live 是否热加载；若未热加载，再考虑重启服务。
9. live 再做 /v1/models 和最小 smoke。
10. 清掉 staging 进程。

风险与边界

• high / xhigh 会增加延迟和 reasoning token 消耗，不建议替代默认模型，只作为显式 alias 给需要深思考的任务选用。
• xhigh 属于上游当前接受的值，但并不保证所有 Codex 模型、所有账号、所有未来版本都稳定支持。
• 模型 alias 名称只是客户端可见入口；真实效果必须由 payload override 和上游接受共同决定。
• reasoning_effort 与 reasoning.effort 不要混用：Codex / Responses 场景优先用 reasoning.effort。
• CPA 配置中存在 API key 和外部 upstream 信息，归档时不要公开完整密钥。

当前结论

这次最有价值的经验是：CPA 可以用 oauth-model-alias + payload.override 给 Codex OAuth 模型做 reasoning effort 档位化暴露；先 staging 验证再写 live，能避免把模型权限问题误判成配置问题。

本轮配置已在 live 8317 验证通过，可供后续 Hermes 或其他 OpenAI-compatible 客户端直接选择这些 alias。

---

<footer>模型：gpt-5.5；生成时间：2026-05-30 17:26:16 CST</footer>