1. 这次更新到底改了什么从锁死到开放的转折点OpenAI Codex 这次放出来的更新核心就一句话允许用户把模型提供者换成第三方。以前 Codex CLI 基本绑死在 OpenAI 自家的模型上你想用 DeepSeek、想接本地 Ollama、想挂 Mistral只能靠各种绕路方案比如中间套一层转发服务、改环境变量硬指、或者干脆自己 fork 一份改源码。现在官方把model_providers这个配置项正式开放出来等于给了一条官方认可的接入通道。这件事的意义不在于多了一个配置项而在于工作流的自由度。我自己的日常是这样的写业务代码用 DeepSeek 因为便宜且中文注释理解好做一些涉及内部数据的重构时切到本地 Ollama 跑 Qwen 或 DeepSeek 的量化版本偶尔需要对比不同模型的输出质量时再挂一下 Mistral。以前这三套要来回切工具现在一个 Codex CLI 配置文件就能全搞定。这篇文章面向的是已经用过或准备用 Codex CLI 的开发者尤其是那些对成本敏感、对数据隐私有要求、或者单纯想折腾本地大模型的人。你不需要是配置高手但至少要会在终端里敲命令、会编辑 TOML 文件。我会把 DeepSeek、Ollama、Mistral 三条线的配置全部拆开讲包括我踩过的坑和参数怎么算。先说清楚一个前提Codex CLI 的配置文件默认在~/.codex/config.tomlWindows 下是%USERPROFILE%\.codex\config.toml。所有第三方提供者的配置都写在这个文件里通过model_providers表来定义然后在profiles里引用。理解这个结构后面所有配置都是套模板。2. 配置机制拆解model_providers 与 profiles 是怎么协作的2.1 两个核心概念提供者定义与配置档案Codex CLI 的配置逻辑分两层很多人第一次看会懵我用一个类比解释model_providers像是通讯录里面存着每个服务商的地址、密钥怎么传、走什么协议profiles像是快捷拨号你预设好几套组合用的时候--profile一喊就切过去。model_providers里每个条目至少要写这几个字段name显示用的名字随便起但建议和实际服务对应方便排查base_urlAPI 的根地址注意这里不要带/v1/chat/completions这种具体路径Codex 会自己拼env_key从哪个环境变量读 API Key比如DEEPSEEK_API_KEYwire_api协议类型目前主流是chat对应 OpenAI 兼容的 chat completions 接口profiles里则是把 provider 和具体模型绑起来model_provider引用上面定义的 provider 名字model具体模型 ID比如deepseek-chatmodel_reasoning_effort推理强度部分模型支持注意base_url结尾不要加斜杠也不要带版本路径。我见过有人写成https://api.deepseek.com/v1/结果请求变成/v1//v1/chat/completions直接 404。2.2 为什么用 TOML 而不是 JSON 或 YAMLCodex 选 TOML 是有道理的。JSON 不支持注释你配置一堆 provider 之后根本记不住哪个是干嘛的YAML 缩进敏感复制粘贴容易出错。TOML 支持注释、结构清晰、对多层级表友好特别适合这种多个 provider 多个 profile的场景。我自己的配置文件里每个 provider 上面都写了一行注释标注这个 key 什么时候申请的、额度多少、什么时候过期。这个习惯救过我好几次——有一次 DeepSeek 的 key 到期了我一看注释就知道该去续了不用一个个试。2.3 环境变量与配置文件的职责划分一个关键原则密钥永远放环境变量不放配置文件。配置文件可能被同步到 dotfiles 仓库、可能被截图分享、可能被误提交。Codex 的设计也是这个思路env_key字段只存变量名真正的值从 shell 环境读。Linux/macOS 下在~/.zshrc或~/.bashrc里加export DEEPSEEK_API_KEYsk-xxxxxxxx export MISTRAL_API_KEYxxxxxxxxWindows PowerShell 下临时设置$env:DEEPSEEK_API_KEYsk-xxxxxxxx要永久生效就写到系统环境变量里或者用setx命令。Ollama 因为是本地服务通常不需要 key但有些部署会加一层鉴权那就随便填一个占位值因为env_key字段在某些版本里是必填的。3. 三条接入路线实操DeepSeek、Ollama、Mistral 逐个拆3.1 DeepSeek 接入性价比路线的首选DeepSeek 的 API 是 OpenAI 兼容格式接入最简单。先去官网申请 API Key然后配置[model_providers.deepseek] name DeepSeek base_url https://api.deepseek.com env_key DEEPSEEK_API_KEY wire_api chat [profiles.deepseek] model_provider deepseek model deepseek-chat用的时候codex --profile deepseek 帮我重构这个函数这里有个细节值得说DeepSeek 有两个模型 IDdeepseek-chat和deepseek-reasoner。前者是通用对话模型后者是推理模型类似 o1 那种会展示思考过程的。日常写代码用deepseek-chat就够了速度快、便宜遇到复杂算法题或者需要它一步步推理的场景切deepseek-reasoner但注意这个模型响应慢、token 消耗大。我实测下来deepseek-chat在代码补全和重构任务上的表现和 GPT-4o 的差距没有价格差距那么大。对于日常 CRUD、写测试、改 bug 这类任务完全够用。真正需要顶级模型的场景比如复杂架构设计、跨文件大重构再切回官方模型。提示DeepSeek 的 API 有并发限制免费额度下 QPS 比较低。如果你在 CI 里批量调用建议加个重试逻辑或者升级到付费档。3.2 Ollama 接入本地部署的隐私路线Ollama 是本地跑大模型最省心的方案一条ollama pull就能拉模型自动处理量化、显存分配。接入 Codex 的关键是它默认监听http://localhost:11434并且提供 OpenAI 兼容接口。先确认 Ollama 服务在跑ollama serve然后拉一个适合写代码的模型。这里要展开讲一下模型选择因为这是最多人问的问题模型参数量显存需求量化后代码能力适用场景qwen2.5-coder:7b7B约 6GB强日常补全、单文件重构qwen2.5-coder:14b14B约 10GB很强多文件理解、复杂逻辑deepseek-coder-v2:16b16B约 12GB很强算法、跨语言转换codellama:13b13B约 9GB中等英文代码为主llama3.1:8b8B约 6GB中等通用对话简单代码我的建议8GB 显存选 7B12GB 以上选 14B 或 16B。别贪大模型跑不动会疯狂往内存溢出速度慢到没法用。Jetson Orin 这类边缘设备上7B 量化版是甜点。配置[model_providers.ollama] name Ollama Local base_url http://localhost:11434/v1 env_key OLLAMA_API_KEY wire_api chat [profiles.ollama] model_provider ollama model qwen2.5-coder:14bOLLAMA_API_KEY随便设个值比如ollama因为本地服务不校验。但字段不能空否则某些版本会报错。注意Ollama 的 OpenAI 兼容接口路径是/v1不是根路径。如果你写成http://localhost:11434Codex 拼出来的地址会 404。这个坑我踩过排查了半小时。关于下载慢的问题这是国内用户的普遍痛点。Ollama 的模型仓库在国外直接ollama pull经常龟速甚至断连。几个可行方案一是用国内镜像源设置OLLAMA_HOST指向镜像二是手动下载模型文件放到~/.ollama/models目录三是用一些整合包里面预置了常用模型。我不推荐第三种因为整合包版本往往滞后而且来源不明有安全风险。WSL2 里装 Ollama 是另一个常见场景。好处是能用 Linux 版的 GPU 加速坏处是 WSL2 的网络和 Windows 主机是隔离的Codex 如果在 Windows 侧跑localhost可能连不上 WSL 里的 Ollama。解决办法是在 WSL 里查 IPhostname -I然后 base_url 写那个 IP。或者干脆 Codex 也在 WSL 里跑省事。3.3 Mistral 接入欧洲模型的差异化选择Mistral 的 API 也是 OpenAI 兼容的接入方式和 DeepSeek 几乎一样[model_providers.mistral] name Mistral base_url https://api.mistral.ai/v1 env_key MISTRAL_API_KEY wire_api chat [profiles.mistral] model_provider mistral model mistral-large-latestMistral 的模型线比较丰富mistral-large-latest是旗舰codestral-latest专门针对代码优化mistral-small-latest是轻量版。写代码优先试codestral-latest它在补全任务上的表现比通用模型好一截。Mistral 的差异化在于对函数调用和结构化输出的支持比较扎实如果你在做 agent 类的开发需要模型稳定地输出 JSON 格式的工具调用Mistral 是个不错的选择。另外它的响应速度在欧洲节点上很快如果你有欧洲的业务部署延迟优势明显。4. 多 Provider 共存与切换策略4.1 一个配置文件管所有实际用起来你不会只配一个 provider。我的配置文件里同时有 deepseek、ollama、mistral、还有官方默认四个 profile 并存。切换就是--profile后面换名字的事。codex --profile deepseek 写个快排 codex --profile ollama 解释这段内部代码 codex --profile mistral 生成 API 文档如果嫌每次敲--profile麻烦可以设一个默认 profile。在配置文件顶部加profile deepseek这样不带参数时默认走 DeepSeek需要切换时再显式指定。4.2 按任务类型选模型的决策表我整理了一张自己实际在用的决策表供参考任务类型推荐 Provider理由日常 CRUD、写测试DeepSeek便宜、中文好、够用内部代码重构Ollama 本地数据不出本机复杂算法、架构设计官方模型或 Mistral Large推理能力强批量文档生成DeepSeek成本低量大不心疼函数调用/Agent 开发Mistral结构化输出稳定离线环境Ollama无网络依赖这张表不是绝对的但能帮你快速决策。核心逻辑是敏感数据走本地简单任务走便宜复杂任务走强模型。4.3 成本与延迟的权衡计算拿一个具体场景算笔账。假设你每天让模型处理 50 次请求平均每次输入 2000 token、输出 500 token。DeepSeek 的定价以我写这篇文章时的公开价格为准大约是输入每百万 token 几毛钱、输出每百万 token 一两块。50 次请求一天大概消耗 10 万输入 token 2.5 万输出 token成本在几分钱到一毛钱级别。一个月下来也就几块钱。同样的量走官方旗舰模型成本可能是 DeepSeek 的 20 到 50 倍。这就是为什么很多人把日常任务迁到 DeepSeek——省下来的钱是实打实的。Ollama 本地则是零边际成本但有硬件成本和时间成本。第一次拉模型要下载几个 GB推理速度取决于你的显卡。RTX 4090 上跑 14B 量化模型速度能到每秒几十 token体验接近在线服务但如果只有集成显卡那就别指望了7B 模型都跑得费劲。延迟方面DeepSeek 国内节点延迟通常在几百毫秒到一两秒Mistral 欧洲节点对国内用户可能一两秒起步Ollama 本地延迟最低但首 token 时间取决于模型加载冷启动可能十几秒。5. 常见问题与排查实录5.1 连接类问题速查现象可能原因排查方法404 Not Foundbase_url 路径错误检查是否多了/少了/v1401 UnauthorizedAPI Key 未设置或错误echo $DEEPSEEK_API_KEY确认Connection refusedOllama 服务没启动ollama serve或检查端口超时网络问题或模型加载慢先用 curl 直接测接口模型不存在model ID 拼写错误对照官方文档确认 ID排查的第一步永远是用 curl 直接打接口把 Codex 这层剥掉curl https://api.deepseek.com/v1/chat/completions \ -H Authorization: Bearer $DEEPSEEK_API_KEY \ -H Content-Type: application/json \ -d {model:deepseek-chat,messages:[{role:user,content:hi}]}如果 curl 通了说明是 Codex 配置问题如果 curl 也不通说明是网络或 key 的问题。这个二分法能省很多时间。5.2 我踩过的三个坑第一个坑base_url 的斜杠。前面提过但值得再强调。DeepSeek 官方文档给的 base_url 是https://api.deepseek.com但它的 OpenAI 兼容接口实际在/v1下。Codex 会自动补/v1/chat/completions吗不一定取决于版本。我的做法是显式写https://api.deepseek.com/v1然后测试。如果报 404就去掉/v1再试。不同 provider 的行为不一致只能试。第二个坑Ollama 的模型名带 tag。ollama pull qwen2.5-coder:14b拉下来的模型在 Codex 配置里 model 字段要写完整的qwen2.5-coder:14b不能只写qwen2.5-coder。少了 tag 会报模型不存在。第三个坑环境变量没生效。在终端里export了变量但 Codex 是在另一个 shell 或者 IDE 里启动的读不到。解决办法是把 export 写进 shell 配置文件然后重启终端或者用env命令显式传递。VS Code 里集成终端和系统终端的环境变量可能不同步这个要注意。5.3 性能调优的几个参数Codex 配置里还有几个参数值得调model_reasoning_effort推理强度可选low/medium/high。对推理模型有效调高会让模型想得更久但更准。日常任务用low省时间。model_max_output_tokens最大输出长度。默认值可能不够生成长文件时调大。request_timeout_ms请求超时。本地模型冷启动慢这个值要调大比如 120000两分钟。这些参数不是必须的但调好了体验会顺很多。我的建议是先用默认值跑通遇到具体问题再针对性调。6. 进阶玩法与扩展思路6.1 用 ccswitch 类工具管理多套配置如果你同时用多个 AI 编程工具比如 Codex、Claude Code、Cursor每个工具都有自己的配置文件和环境变量管理起来很乱。社区里有一些配置切换工具思路是维护多套 profile一键切换。这类工具的核心价值是把环境变量和配置文件的管理集中化避免手动改来改去。我自己没用这类工具因为我的配置不算复杂手改也就几秒钟。但如果你有十几套配置、经常在不同项目间切换值得考虑。6.2 在 CI/CD 里用第三方模型把 Codex 接第三方模型用在 CI 里比如自动 review PR、生成 changelog是个很实用的场景。关键点API Key 放 CI 的 secret 里不要硬编码加超时和重试第三方服务稳定性不如官方控制成本CI 触发频繁的话用便宜模型输出要可解析最好让模型输出结构化格式我见过有团队用 DeepSeek 做 PR 自动 review每次 PR 触发一次调用成本几乎可以忽略但能抓到不少低级错误。6.3 本地模型的量化选择Ollama 拉模型时默认会选一个量化版本通常是 Q4_K_M。这个量化级别在质量和体积之间平衡得比较好。如果你显存充裕可以手动指定 Q5 或 Q8质量更高但更占空间。反过来显存紧张就用 Q3 甚至 Q2但质量下降明显代码任务上可能开始胡言乱语。判断标准很简单跑起来不 OOM、速度能接受、输出质量够用就是合适的量化级别。不用追求最高质量本地模型本来就是图个隐私和免费质量上跟在线旗舰有差距是正常的。6.4 关于破甲和无限制的理性看待热词里出现了一些关于破甲无限制的词这里我得说句实在话任何模型都有其使用条款和内容边界试图绕过这些边界既不道德也可能违反服务协议。作为开发者我们关注的重点应该是模型在合法合规任务上的能力比如代码生成、文档撰写、数据分析。把精力花在提升这些正经能力上比折腾边界有意义得多。而且从实际效果看主流模型在正常任务上的表现已经足够好所谓的限制在写代码这个场景里几乎不构成障碍。你写个排序算法、重构个函数、生成个测试用例没有任何模型会拒绝。7. 我的实际使用体会配置这套东西最花时间的不是写配置文件而是搞清楚每个 provider 的接口细节。文档写的和实际行为经常有出入base_url 要不要带/v1、模型 ID 怎么拼、鉴权头怎么传这些只能靠试。我的建议是每接一个新 provider先用 curl 打通再写进 Codex 配置这样出问题能快速定位是哪一层的事。另一个体会是别一次配太多。我一开始把能接的都接上了结果配置文件几百行自己都记不清哪个 profile 对应哪个模型。后来精简到四个常用的每个都写清楚注释反而效率更高。工具是拿来用的不是拿来收藏的。最后分享一个小技巧给每个 profile 起名时带上用途比如deepseek-daily、ollama-private、mistral-agent比单纯用 provider 名字更直观。切换的时候一眼就知道该用哪个不用回忆。这个习惯看起来小但每天省下的那几秒思考时间累积起来很可观。
` 与 `loop()` 并发执行完全指南)
