Codex 最近大家又开始讨论了,听隔壁部门讲,賊省token,而且GPT-5.2-Codex 编码模型确实好用。但国内开发者面对一个现实问题:它只能连 OpenAI 的模型。
因为我们部门一直在用Claude code,且有智谱 GLM 的 coding 套餐,想直接喂给 Codex 用,行不行?行,但不能「直连」------中间需要加一个协议转换层。
很多人第一反应是掏出 CC Switch,毕竟这工具专门干切换模型这事儿。但你会发现,CC Switch 对 Claude Code 管用,对 Codex 却不灵。
CC Switch:能做什么,做不了什么
CC Switch大家都很熟悉了。专门管理各种 AI 编码工具的配置------API Key、Base URL、MCP Server、系统提示词等等。一键切换 Claude Code、Codex、Gemini CLI 的 provider。
对于 Claude Code 来说,CC Switch 确实够用。因为 GLM 提供了 Anthropic 兼容接口(/api/anthropic),你只需要把 ANTHROPIC_BASE_URL 指过去,Claude Code 就能直连 GLM。
但 Codex 不一样。Codex 强制使用 OpenAI 的 Responses API 协议(POST /v1/responses),而 GLM 只认 Chat Completions 协议(POST /v4/chat/completions)。
所以今天我们就聊一个事,那就是你既想用国内的模型,但是它又没有/v1/responses API协议的情况,该怎么搭配Codex使用
CC Switch 能帮你改 URL,但改不了协议。你把 Codex 的 Base URL 指向 GLM,Codex 发一个 Responses API 请求过去,GLM 直接返回 404。

一句话总结:CC Switch 是「换地址牌」,不是「翻译官」。Claude Code + GLM 协议本身兼容,换个地址就行;Codex + GLM 协议不兼容,换地址没用,得有人中间做翻译。
新方案:litellm 做协议翻译
既然 Codex 说 Responses API,GLM 听不懂,那就在中间放一个翻译:
Codex Desktop → litellm(协议翻译)→ 智谱 GLM
litellm 是一个开源的 LLM 代理网关,支持多种 API 协议互转。关键是它从某个版本开始支持了 Responses API 到 Chat Completions 的桥接模式。
安装配置 litellm
直接 pip 安装:
linux
pip install litellm
确认版本 >= 1.66.3(低于这个版本不支持 Responses API 桥接):
linux
python3 -c "import importlib.metadata; print(importlib.metadata.version('litellm'))"
输出类似:1.83.11
另外准备好你的智谱 API Key。
注意智谱有两个接口地址,别搞混了:
标准接口:open.bigmodel.cn/api/paas/v4
Coding 接口:open.bigmodel.cn/api/coding/...
买的是 coding-plan 套餐就必须用 Coding 接口地址,标准套餐用标准接口。
配置litellm
创建配置文件 ~/.claude/litellm-config.yaml:
linux
model_list:
# 给 Codex 用的条目
- model_name: glm-5.1
litellm_params:
model: custom_openai/glm-5.1
api_base: https://open.bigmodel.cn/api/coding/paas/v4
api_key: 你的智谱API-Key
注意看模型前缀是 custom_openai/ 不是 openai/。这个很关键------litellm 源码里 openai provider 被硬编码为支持原生 Responses API,用 openai/ 前缀的话 litellm 会把请求原样转发给 GLM,还是 404。custom_openai/ 没有注册 Responses API 配置,litellm 才会走翻译路径。
配置写好后启动 litellm:
linux
nohup litellm --config ~/.claude/litellm-config.yaml --port 4000 > /tmp/litellm.log 2>&1 &
验证一下是否正常:
linux
curl -s http://127.0.0.1:4000/health | python3 -c "import sys,json; d=json.load(sys.stdin); print(f'healthy: {d[\"healthy_count\"]}')
# 输出:healthy: 1
再测试 Responses API 桥接是否通:
linux
curl -s -X POST http://127.0.0.1:4000/responses \
-H "Content-Type: application/json" \
-H "Authorization: Bearer 你的API-Key" \
-d '{"model":"glm-5.1","input":"你好","stream":false}'
返回包含 output 字段的 JSON 就说明协议转换成功了。接下来配置 配置 Codex Desktop
配置Codex
Codex 的配置文件在 ~/.codex/config.toml,编辑成这样:
linux
model_provider = "custom"
model = "glm-5.1"
model_reasoning_effort = "high"
disable_response_storage = true
[model_providers]
[model_providers.custom]
name = "custom"
wire_api = "responses"
requires_openai_auth = true
base_url = "http://127.0.0.1:4000"
几个关键点:
- model 设成 glm-5.1,要和 litellm 配置里的 model_name 对上
- wire_api 保持 "responses",告诉 Codex 用 Responses API(litellm 会负责翻译)
- base_url 指向本地 litellm http://127.0.0.1:4000
然后编辑认证文件 ~/.codex/auth.json:
json
{
"OPENAI_API_KEY": "你的智谱API-Key"
}
完全退出 Codex Desktop 再重新打开,在新对话里发条消息试试。到这一步如果 litellm 配置正确,Codex 已经能收到 GLM 的回复了------但大概率你会遇到两个报错。接着看下一步。
修复 litellm 的两个 Bug(必做)
litellm 的 Responses API 桥接模式有两个已知但至今没修的 bug,不改的话根本跑不通。需要手动 patch 源码。
先找到 litellm 安装路径:
linux
python3 -c "import litellm; print(litellm.__path__[0])"
# 类似:/Library/Frameworks/Python.framework/Versions/3.12/lib/python3.12/site-packages/litellm
要改的文件是 responses/litellm_completion_transformation/handler.py。
Bug 一:client_metadata 没过滤
报错长这样:AsyncCompletions.create() got an unexpected keyword argument 'client_metadata'
Codex 发的请求里带了个 client_metadata 字段(Codex 自己用的元数据),litellm 翻译的时候没过滤,直接丢给了底层 OpenAI 客户端,客户端不认识就炸了。
打开 handler.py,找到 异步方法 async_response_api_handler 里的这段:
py
acompletion_args = {}
acompletion_args.update(kwargs)
acompletion_args.update(litellm_completion_request)
litellm_completion_response: Union[
在 await litellm.acompletion 前面插入过滤代码:
py
acompletion_args = {}
acompletion_args.update(kwargs)
acompletion_args.update(litellm_completion_request)
# --- Patch: 过滤 Responses API 专有参数 ---
for _k in ["client_metadata", "max_output_tokens",
"previous_response_id"]:
acompletion_args.pop(_k, None)
litellm_completion_response: Union[
同步方法 response_api_handler 里也有同样的代码,一样改(把 acompletion_args 换成 completion_args)。
Bug 二:非 function 类型工具没过滤
Codex 发的工具列表里有 web_search、code_interpreter、file_search 这些 OpenAI 专有工具类型,GLM 只支持 function 类型。litellm 照样没过滤。
在上一步的参数过滤代码后面,紧跟加上工具过滤:
py
# --- Patch: 过滤非 function 类型工具 ---
_tools = acompletion_args.get("tools")
if _tools and isinstance(_tools, list):
acompletion_args["tools"] = [
t for t in _tools if t.get("type") == "function"
]
litellm_completion_response: Union[
同步方法同理,把 acompletion_args 换成 completion_args。
改完后重启 litellm:
linux
kill $(lsof -i :4000 -t) nohup litellm --config ~/.claude/litellm-config.yaml --port 4000 > /tmp/litellm.log 2>&1 &
然后打开 Codex Desktop 发条消息,应该一切正常了。

总结
整理一下最终链路和涉及的文件:
Codex Desktop (Responses API) → litellm (:4000) → 智谱 GLM (Chat Completions)
涉及的配置文件汇总:
~/.claude/litellm-config.yaml --- litellm 代理配置(模型、API 地址、Key)
~/.codex/config.toml --- Codex 配置(模型、协议、代理地址)
~/.codex/auth.json --- Codex API Key
~/.zshrc --- Claude Code 环境变量(直连 GLM)
litellm handler.py --- 源码 patch(两个 bug 修复)
核心思路就一句话:协议不兼容,就加个翻译。
CC Switch 是配置管理工具,不是协议转换工具。Claude Code + GLM 协议本身兼容所以不需要翻译,Codex + GLM 协议不兼容所以必须靠 litellm 中间转一道。分清这两件事,配置起来就不会走弯路。
最后讲下
还是刚才那句话,你既想用国内的模型,但是它又没有/v1/responses API协议的情况,就是这么玩,另外多说一句,最近codex又被炒起来,大家也可以多看看,很省token,而且输出质量不受影响,毕竟并不是所有人都喜欢用Claude code 的命令行模式。
