ENZOMEGA.
Clipping 微信公众号

Codex官方全线支持第三方模型接入，包括Codex App、CLI和SDK

by 鲁工 原文 ↗
Created: 2026-06-18
#公众号文章

公众号名称：AI编程实验室

作者名称：鲁工

发布时间：2026-06-18 11:01

大家好，我是鲁工。

把各种国产模型接入Claude Code已经不是啥新鲜事，我之前主推的ccmr就是干这个事的，主打一个轻量级的模型网关。接入国产模型后，可以使用全球顶级的Coding Harness工具再搭配上国产模型量大便宜的特点，可谓一举两得。

但Codex今年以来疯狂发力，在Coding市场声量上一度反超Claude Code。随着Codex用户越来越多，把各种量大管饱的国产模型接入Codex，也是目前一大刚需。
这事得从一条推文说起。OpenAI的Tibo（@thsottiaux）昨晚在X上句话：Codex的App、CLI、SDK，都可以用开源模型，不只是OpenAI自家的。

结合Codex现在的自定义provider配置来看，只要对方提供Codex能适配的兼容接口，我们就不一定非得用GPT-5.5，DeepSeek、GLM、Qwen、Kimi、MiniMax这些第三方模型都可以接入Codex。

这篇就把这条路从头走一遍：配置怎么写、两个坑怎么填、现在哪些模型能直连、哪些还得绕路。

先一句话讲清原理：接第三方模型，本质就是在～/.codex/config.toml里加一段provider配置，告诉Codex去哪个地址、用哪个协议、拿哪个key。Codex App和CLI本身共享同一套配置层，SDK这边本质也是调本地Codex runtime或app-server，通常也会调用CODEX_HOME下的配置。

动手前有几个点得先清楚，不然后面可能会踩坑。

配置文件在～/.codex/config.toml，这是用户级配置。provider这类key只能写在这里，写进项目目录里的.codex/config.toml会被直接忽略。

一个provider就是一组连接信息：名字、base_url（接口地址）、env_key（放 key 的环境变量名）、wire_api（用哪套协议跟模型对话）。后面要填的就是这几样。

还有几个ID是Codex内置保留的，自定义provider不能占用，主要是openai、ollama、lmstudio、amazon-bedrock这些，给国产模型起名时避开它们就行。

比如我这里以Qwen为例。在config.toml里加这么一段，就完成了一个provider的登记：

[model_providers.qwen]
name = "Qwen 通义千问 (DashScope)"
base_url = "https://dashscope.aliyuncs.com/api/v2/apps/protocols/compatible-mode/v1"
env_key = "DASHSCOPE_API_KEY"
wire_api = "responses"

配好之后填写模型API-key：

export DASHSCOPE_API_KEY="<你的Key>"

想临时切到某个模型，不用改文件，命令行直接覆盖：

codex -c model='"qwen3.7-max"' -c model_provider='"qwen"'

要特别注意wire_api这个参数。wire_api是告诉Codex用哪套协议跟模型通信，过去填
wire_api
chat
/v1/chat/completions

但从我手上codex-cli 0.140.0这版看，wire_api = "chat"已经变成硬错误。官方在GitHub讨论里给的理由是，旧的chat/completions协议一直拖累Codex上新功能、维护成本太高，从2025年初他们就转向了新的Responses API。现在自定义provider这块，稳妥写法就是让服务支持Responses接口（/v1/responses），wire_api填responses。

问题就来了。很多国产模型最早做的都是Chat Completions兼容，Responses兼容这块不是每家都同步补齐。

现在能明确看到Responses接口的，至少有Qwen、MiniMax以及阶跃星辰的Step模型。

Qwen这边，阿里云百炼专门做了OpenAI Responses兼容接口，注意要用新的api/v2/apps/protocols/compatible-mode/v1路径。MiniMax这边，官方文档也已经有POST /v1/responses，MiniMax-M3可以按Responses方式调用。所以这两家理论上都可以按新版Codex的要求直连，具体稳定性还要看工具调用和流式返回细节。MiniMax-M3接入配置如下：

model = "MiniMax-M3"
model_provider = "minimax"
model_context_window = 512000

[model_providers.minimax]
name = "MiniMax"
base_url = "https://api.minimaxi.com/v1"
experimental_bearer_token = ""
wire_api = "responses"

DeepSeek官方文档当前主推的是OpenAI/Anthropic兼容调用，OpenAI侧示例还是/chat/completions。智谱GLM、Kimi、小米MiMo的公开文档里，主接口也都是Chat Completions或Anthropic兼容。这类模型要接Codex，关键在于不能直接拿一个Chat endpoint硬塞给 wire_api = "responses"。

想用这些只有Chat Completions的模型，也不是没办法，核心就是在中间加一层，把Codex发的Responses请求转成模型听得懂的Chat Completions。最省心的是用现成工具，比如cc-switch。想在Codex里用DeepSeek这种Chat Completions格式的第三方模型，可以先走这类代理方案。

想自己搭也行，社区有mimo2codex、va-ai-api-bridge这类翻译代理，把Codex的Responses请求实时转成Chat Completions，代理跑起来后把对应provider的base_url改成本地代理地址即可。

前面接的都是云端API。如果你想在本机跑开源模型，Codex文档里还留了条更省事的路：--oss。它内置了ollama和lmstudio两个本地provider，不用手写model_providers，直接启动就行：

codex --oss-m<你的本地模型名>

也可以在config.toml里把默认本地provider定下来，--oss不带参数时就用它：

oss_provider="ollama"# 或 "lmstudio

前提是本机已经用Ollama或LM Studio把模型拉下来并启动服务，本地机器算力也顶得住。这里也补充一条更新：我之前担心本地模型会同样卡在Responses上，但现在Ollama官方文档已经写明从v0.13.3起支持/v1/responses，LM Studio文档也明确说Codex可用，因为它实现了OpenAI兼容的POST /v1/responses。实际体验还要看本地服务版本、模型大小和工具调用能力，但起码不用等官方协议更新了。

总的来看，虽然有一些小问题，但Codex这波确实上大分了，OpenAI也算是Open了一波。

如果觉得有用，点个赞或者在看，也方便更多朋友看到。

感谢您阅读我的文章。我是鲁工，九年AI算法老兵，AI全栈开发者，深耕AI编程赛道与AI科研赛道。

>/ 作者：鲁工

内容效果不满意？点此反馈

输入关键词开始搜索