常见问题

客户端和模型该怎么配对，才不容易出问题

结论先说：GPT 系列配 Codex CLI，Claude 系列配 Claude Code。反过来接（比如 Claude Code 接 GPT 模型、Codex 接 Claude 模型）严格说也能通，但更容易踩到本文档里这些"看着像 bug、其实是客户端行为"的坑，新手尤其容易被绕进去。

为什么：Codex 和 Claude Code 都不是通用客户端 —— 它们各自内置了针对"自家"模型的一整套假设：Codex 靠模型名判断走哪种内部模式（gpt-5.6-sol 的坑就是这么来的，跟这个网关无关，是 Codex 客户端自己的逻辑）；Claude Code 同理，对 thinking 块、工具调用格式、stop_reason 语义这些细节，都是照着 Anthropic 官方模型的行为对齐的。

网关确实能把 GPT 模型转成 Anthropic 格式给 Claude Code 用，反过来也行 —— 这正是"一个 API 接多家"这个功能本身。但转换出来的响应和模型原生说的协议之间，永远有细微差异，这些差异刚好就是 Codex/Claude Code 里那些内置假设最敏感的地方。原生配对（GPT 走 OpenAI 协议、Claude 走 Anthropic 协议）不依赖这层转换，天然更稳。

如果你就是要跨着用，遇到怪异行为（模型说没有工具、拒绝调用、格式对不上），先怀疑是不是客户端把这个模型当成了别的家族在处理，而不是先怀疑网关或者模型本身坏了。

不想手动改配置文件的话，可以用 CC Switch 这个图形界面工具管理 Codex / Claude Code 的供应商配置 —— 但要注意分开配置，别用它的"统一供应商"功能把同一个模型同步给两个客户端，那正好是这里说的反面教材。

用 Codex CLI 接 gpt-5.6-sol，模型说看不到我的文件/目录

症状：Codex 报告"没有可用的本机文件浏览或终端工具"，或者声称你的项目目录是空的、未映射，即使目录里明明有文件。

原因不在网关，在 Codex 客户端本身。 Codex 把 gpt-5.6-sol（以及同系列的 terra、luna）识别为一种特殊工作模式（"code mode"），在这种模式下 Codex 根本不会把 shell/文件工具放进请求里 —— 不是网关没转发，是客户端压根没发。模型如实回答"没有工具可用"，因为它确实没被告知有工具存在。

解决办法：换用模型广场上的 gpt-5.6-reasoning。这是网关为同一个模型设的自定义别名 —— 底层模型和 gpt-5.6-sol 完全一样，区别只是 Codex 不认识这个名字，于是退回标准模式，正常发送工具。换一下 model 配置即可，不需要改任何其他设置。

代价：Codex 会提示"model metadata not found, using fallback"，实际影响是客户端侧少数调参（比如默认上下文窗口大小）用的是通用默认值而不是这个模型的专属值，模型能力本身不受影响。

具体配置方式见 Codex CLI 示例。

为什么模型广场上同一个模型会出现好几个名字

网关会给部分模型设置别名，通常是为了绕开某个客户端对特定模型名的特殊处理（就像上面 gpt-5.6-reasoning 的例子），或者是把上游供应商的内部命名换成更好记的名字。哪个名字对应哪个真实模型、为什么要设这个别名，模型卡片的"详情"里会写明，不是随意重复的条目。

请求返回模型不存在 / 无可用渠道

说明这个模型名当前没有配置好路由，联系管理员确认该模型是否已经上线，或者换一个模型广场上标为可用状态的模型名重试。

我应该用 Chat Completions 还是 Responses 还是 Messages

看你的客户端本身对接的是哪种格式，跟调用哪个模型无关。详见接口与兼容性。