Codex 接入 DeepSeek API：省钱的替代方案实测
Codex 好用，但它的模型调用是有成本的，重度使用一个月下来账单不算便宜。DeepSeek 的 API 价格低一截，而且兼容 OpenAI 的接口协议，这就给"用 Codex 的壳、跑 DeepSeek 的模型"留了操作空间。这个思路我在生产脚本和日常辅助编码上已经跑了一个多月，能省是真省，但坑也是真有几个。
这篇文章讲清楚三件事：为什么要接（含成本测算）、怎么配置（环境变量和配置文件两条路）、以及跑起来之后会遇到的报错和效果差异。价格数字都是会变的，我标了（以官方定价为准），你配置前最好去官网看一眼当天价。截图同样用占位符，你按步骤跑一遍，预期输出都写在代码块里。
为什么要接：先算一笔账
选模型说白了就是算性价比。Codex 默认走 OpenAI 的模型，DeepSeek 走自己的 API，两边都是"输入 token + 输出 token"计费。把同类定位的模型放在一起看，差距大概是这样（价格经常调整，以官方定价为准）：
| 对比项 | OpenAI 同档模型 | DeepSeek 模型 |
|---|---|---|
| 输入价格（每百万 token） | 明显偏高 | 明显偏低 |
| 输出价格（每百万 token） | 明显偏高 | 明显偏低 |
| 缓存命中价格 | 有优惠档 | 有优惠档 |
| 计费粒度 | 按 token | 按 token |
价格数字我不写死，因为一个月一个样。但你记住结论就行：DeepSeek 的输入价格通常是 OpenAI 同档的十分之一量级，输出也低不少。对一个每天跑几百次调用、一次任务吃几十万 token 的 Codex 重度用户，这个差价能差出几十倍。轻度用可能无所谓，一天几百个来回的用法，差距就真实了。
举个具体例子就直观了。假设一个中等任务消耗 200 万输入 token、5 万输出 token，按当时的官方定价，OpenAI 同档模型大概在 60 元量级，DeepSeek 大概在 6 元量级（具体数字以官方定价为准）。单次看没感觉，但一天跑 30 个这样的任务，一个月下来就是两位数的量级差。把两边官网价摆在一起算一遍，该接谁不言自明。
【此处需补真实截图：DeepSeek 官网计价页与 OpenAI 官网计价页的对比截图（标注截图日期）】
配置方法：环境变量和配置文件两条路
Codex 通过环境变量或配置文件指定"走哪个 API"。两条路都讲，建议用配置文件，持久生效，不用每次开终端都 export。
方法一：环境变量（临时用）
# Linux / macOS 临时生效exportOPENAI_BASE_URL="https://api.deepseek.com/v1"exportOPENAI_API_KEY="你的DeepSeek密钥"codex原理很简单：Codex 默认把所有 API 请求发到 OpenAI 的域名，OPENAI_BASE_URL把地址改掉，OPENAI_API_KEY换成 DeepSeek 的密钥。这两项一配对，Codex 就把请求发到 DeepSeek 了。
Windows 下环境变量设置不一样，PowerShell 里用：
$env:OPENAI_BASE_URL ="https://api.deepseek.com/v1"$env:OPENAI_API_KEY ="你的DeepSeek密钥"codex方法二：配置文件（推荐）
Codex 的配置文件在~/.codex/config.toml。用 DeepSeek 的话，长这样：
# ~/.codex/config.toml model_provider = "deepseek" # 默认模型供应商指定为 deepseek model = "deepseek-chat" # 默认模型名（以 DeepSeek 官方文档为准） [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY" # Codex 从这里读密钥配好后，把密钥写进环境变量，或者有些版本支持写进~/.codex/auth.json里对应的字段（字段名以官方文档为准）。
exportDEEPSEEK_API_KEY="sk-你的DeepSeek密钥"codex写配置文件有个好处：来回切模型不用改代码。想临时切回 OpenAI，把model_provider那一行注释掉重启即可。
验证与常见报错
配置完别急着干活，先跑个最小验证：
codexexec"回复 OK"# 预期输出：OK# 如果返回内容正常，说明链路通了【此处需补真实截图：codex 用 DeepSeek 成功回应的终端截图】
不通的话，报错集中在下面几种，对号入座：
| 报错现象 | 常见原因 | 处理方式 |
|---|---|---|
| 401 Unauthorized / Invalid API key | 密钥错误或没配env_key | 检查密钥、确认环境变量名和配置文件里的env_key一致 |
| 404 / model not found | 模型名不对 | 核对deepseek-chat、deepseek-reasoner等模型名（以官方文档为准） |
| timeout / connection error | 网络不通或域名写错 | 检查base_url是否拼写正确、是否有代理拦截 |
| 一直弹登录界面 | 环境变量没生效或配置未加载 | 重启终端；确认model_provider拼写正确 |
| 请求成功但回答很怪 | 模型能力边界 | 降级预期，简单任务用它，复杂任务切回原模型 |
其中"模型名不对"是我踩过最多的一次。DeepSeek 开放平台里模型名有两个版本，旧名和最新名并存过一段时间，写错就 404。务必以当天官网文档为准。
验证链路有个更稳妥的顺序：先不经过 Codex，直接用 curl 测 DeepSeek API 通不通，排除 Codex 配置的干扰：
curl-XPOST https://api.deepseek.com/v1/chat/completions\-H"Content-Type: application/json"\-H"Authorization: Bearer 你的DeepSeek密钥"\-d'{"model":"deepseek-chat","messages":[{"role":"user","content":"回复 OK"}]}'# 预期输出：一段 JSON，其中 choices[0].message.content 为 "OK"curl 通了再回 Codex 里跑，如果还报错，问题基本就定位在 Codex 配置侧，而不是网络或密钥侧。这个"先排除下层、再查上层"的思路，排查任何 API 对接问题都通用。
效果对比：质量、速度、适用场景
换模型不是免费午餐，能力差异要心里有数。我连续用了一个多月的体感如下（这是主观感受，不同任务差异很大）：
| 维度 | 实测体感 | 说明 |
|---|---|---|
| 代码生成质量 | 够用，有差距 | 常规函数、脚本、重构没问题；极复杂架构设计会需要你多把关 |
| 推理速度 | 大体可用 | 长任务偶尔比原模型慢，跟当天服务负载有关 |
| 中文理解 | 好 | DeepSeek 的中文场景体验不差 |
| 复杂长任务 | 偶尔掉链子 | 多文件大改动时，中途需要你纠正方向的情况多一点 |
实际跑起来，我一般把"能明确描述、边界清晰"的任务——修 bug、补测试、写文档、改配置——交给 DeepSeek 接管的 Codex；真正纠结的架构级改动，还是切回原模型。省钱的正确姿势不是全量替代，而是分层使用。
拿我的实际任务分布看，占比最高的是三类：补注释和文档、写测试用例、解释报错信息。这三类共同特点是边界清晰、上下文需求小，DeepSeek 的表现和原模型差距很小，但价格差距很大。真正需要谨慎的是架构设计、跨文件重构、安全相关代码审查——这几类我基本不交给便宜模型，风险不值得省。分层使用一个月下来，总体效果没打折，账单倒是肉眼可见地降了。
如果你拿不准自己的任务该不该切过去，教一个简单的判断方法：把最近十次用 Codex 的任务按"描述清楚程度"打个分，八分以上的基本都可以交给 DeepSeek，六分以下的留着用原模型。描述越清楚，模型能力差距对结果的影响越小，这个规律在绝大多数任务上成立。
进阶：按项目切换供应商
配置文件方案的好处是可以定义多个 provider，随时切换。一个完整的config.toml长这样：
# ~/.codex/config.toml model_provider = "deepseek" model = "deepseek-chat" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY" [model_providers.openai] name = "OpenAI" base_url = "https://api.openai.com/v1" env_key = "OPENAI_API_KEY"切换时改model_provider这一行重启即可，也可以按任务粒度临时切：
# 简单任务走 DeepSeekcodexexec"给 README 补使用说明"# 重要重构临时切回原模型codexexec--modelopenai"重构 auth 模块，保持接口不变"（--model参数名以官方文档为准）
什么时候别用这个省钱方案？代码含机密的环境、对输出质量要求极高的任务、团队强制统一工具链的场景，就别为了省几十块钱给自己添堵。我见过最亏的用法：把复杂的跨模块重构也压到便宜模型上，来回返工三天，省下的费用还不够半天人工成本。省钱的正确逻辑是"低成本任务才用低成本模型"，而不是"所有任务都用低成本模型"。
除了省那笔 API 钱，这个方案还有两个隐性收益。一个是不依赖订阅额度——OpenAI 订阅版有使用限额，第三方 API 按量计费没有次数焦虑；另一个是可脚本化——接进去之后可以写脚本批量跑任务，走 CI 也没问题，这是订阅账号做不到的。
注意事项
接入第三方 API 有几件事必须提前知道。
代码会离开你的机器。你项目里的代码会被发送到 DeepSeek 服务器做推理。公司代码、含密钥的仓库、未公开的项目，先问清楚合规性再决定，这个没有商量余地。
接口兼容性不是百分之百。Codex 依赖 OpenAI 的部分特有行为（比如某些工具调用格式、流式输出的细节），DeepSeek 兼容 OpenAI 协议，但细节不可能一模一样。偶尔会遇到功能降级或行为异常，这是预期的，不是 bug。
稳定性要自己扛。第三方 API 偶尔有服务波动、限流，接口也可能变动。重要的自动化流程，建议加好重试和降级逻辑。
费用结构不同。DeepSeek 便宜，但缓存命中、并发限制这些细节跟 OpenAI 不一样，跑量大之前先小规模验证一下计费是否符合预期。
降级预案要备好。第三方 API 偶尔会挂，高峰期也可能排队。重要的自动化流程里，至少留一个 fallback——脚本捕获连接失败的异常，自动切回 OpenAI 的 key 重试一次，能避免半夜任务静默失败。写代码时把这段降级逻辑备好，比祈祷服务稳定靠谱。
密钥管理别大意。DEEPSEEK_API_KEY别写死在配置文件里提交到仓库，放到环境变量或密钥管理工具里。配置文件里的env_key只是告诉 Codex"去哪个环境变量取"，不是让你把明文 key 写进config.toml。
结论
Codex 接 DeepSeek，本质是用接口兼容换成本空间。配置本身十分钟搞定，麻烦主要在"理解模型差异、管好预期"。我的建议是：个人项目、高调用量、对成本敏感的场景，放心接；企业项目先过合规；复杂任务保留切回原模型的能力。省钱和省心之间，这个方案算是提供了一个还不错的平衡点。
