如果你经常用 Codex 做开发、改代码、跑批量任务，应该很容易遇到一个现实问题：官方订阅或高强度 API 使用的成本并不低。尤其是团队多人使用、长上下文频繁调用、每天都有大量自动化任务时，费用会很快堆上去。
于是很多人会想到：能不能把 Codex 背后的模型换成 DeepSeek 这类更便宜的 API？
答案是：可以尝试，但不是简单把 base_url 改成 DeepSeek 就完事。真正关键的地方在于——Codex 新版本主要按 OpenAI Responses API 的方式工作，而 DeepSeek 目前常见接口是 Chat Completions API。两边协议不完全一致，直接硬连通常会报错。
核心思路：中间加一层协议代理
目前比较常见的做法，是在本机跑一个轻量代理，例如社区里的 codex-bridge 方案：
- Codex 仍然以 Responses API 的方式请求本地代理；
- 本地代理把请求转换成 DeepSeek API 能理解的 Chat Completions 格式；
- DeepSeek 返回结果后，代理再转换回 Codex 需要的响应结构；
- Codex 客户端仍然保持原来的使用方式，包括新版客户端、命令行、部分工具调用流程。
也就是说，Codex 看到的是“兼容 OpenAI Responses 的本地服务”，DeepSeek 看到的是“正常的 Chat Completions 请求”。中间的协议差异由代理消化。
为什么不是直接改配置？
直接把 Codex 的接口地址改成 DeepSeek API，问题通常出在三处：
1. 接口路径不同 Codex 新版本常用 /v1/responses，DeepSeek 常用 /v1/chat/completions。
2. 工具调用结构不同 Codex 侧的工具调用、消息组织方式和 Chat Completions 并不完全一致。
3. 登录和密钥逻辑不同 Codex 客户端有自己的认证习惯，有时还会强制走 OpenAI 登录逻辑。要稳定使用第三方 API，通常需要配置成本地 API Key 模式，或者借助切换工具管理不同供应商。
所以，真正稳定的方案不是“把地址换掉”，而是“让 Codex 继续按它熟悉的协议说话，再由代理翻译”。
大致配置流程
不同系统和工具版本会有差异，但整体流程通常是这样：
1. 安装 Node.js 18 或更高版本； 2. 下载或克隆 codex-bridge 这类协议代理项目； 3. 在代理的 .env 文件里配置 DeepSeek API Key 和模型列表； 4. 启动本地代理，例如监听在 http://127.0.0.1:4000/v1； 5. 修改 Codex 配置，把模型供应商指向本地代理； 6. 使用 API Key 登录模式，让 Codex 不再强制打开官方 OAuth 登录； 7. 在 Codex 里切换到代理暴露出来的 DeepSeek 模型。
配置完成后，Codex 的调用链大致是：
Codex 客户端 → 本地 codex-bridge → DeepSeek API → 本地代理 → Codex 客户端如果端到端测试能正常返回内容，说明协议代理、密钥、模型和网络都已经打通。
成本能省多少？
“省 90%”这个说法要看具体模型、调用量和任务类型，不能一概而论。但大方向是成立的：DeepSeek API 的单位价格通常明显低于高强度使用官方高级模型的成本。
更适合用 DeepSeek 承担的场景包括：
- 批量改小文件；
- 常规代码解释；
- 简单 Bug 定位；
- 日常脚本生成；
- 重复性文本处理；
- 对极限推理质量要求不高的任务。
不太建议完全替代的场景包括：
- 复杂架构重构；
- 高风险生产代码自动修改；
- 需要极强工具调用稳定性的长链路任务；
- 依赖官方模型特殊能力的远程操作或多模态流程。
更稳妥的做法是：把 DeepSeek 当作“低成本工作马”，把官方模型留给关键任务。
这个方案最大的价值
它不是单纯为了便宜，而是把 Codex 拆成两层：
- 前端工作流继续用 Codex；
- 后端模型可以按任务切换。
这样就可以做到：
- 简单任务走便宜模型；
- 复杂任务再切回官方模型；
- 保留 Codex 新版客户端和命令行体验；
- 避免为了省钱去降级旧版本；
- 给团队内部做更灵活的模型路由。
这也是它比“直接换一个 AI 编程工具”更有吸引力的地方：不用重建整个工作流，只替换模型入口。
风险和注意点
这个玩法适合有一定折腾能力的人，不太适合完全零基础用户。主要风险有几个：
1. 协议代理可能不完整 工具调用、流式输出、错误码映射都可能出现兼容问题。
2. Codex 版本更新可能打破兼容 Codex 如果调整 Responses API 细节，本地代理也需要跟进。
3. 第三方模型能力边界不同 DeepSeek 性价比高，但不等于在所有任务上都和官方模型完全一致。
4. API Key 安全要注意 .env、配置文件、日志里都不要泄露密钥，也不要把带密钥的项目提交到 Git。
5. 不要直接在生产仓库盲跑 第一次接入建议先用测试项目验证，再逐步放到真实工作流里。
推荐使用方式
如果你想长期使用，建议按“三档模型策略”来配置：
- **DeepSeek 快速模型**：处理简单编辑和低风险任务；
- **DeepSeek 推理模型**：处理中等复杂代码任务；
- **官方 Codex / OpenAI 模型**：处理关键改动、复杂调试和高价值任务。
这样既能把日常成本降下来，也不会为了省钱牺牲关键任务的成功率。
总结
Codex 接入 DeepSeek 的关键，不是“伪装成 OpenAI API”，而是用本地代理做协议转换。这个方案可以在保留 Codex 工作流的同时，把大量日常任务迁移到更低成本的模型上。
它适合重度 Codex 用户、开发团队、自动化脚本用户，以及任何想在成本和体验之间找平衡的人。
但也要保持清醒：这不是官方原生方案，兼容性和稳定性取决于代理项目、Codex 版本和 DeepSeek 接口变化。最好的策略不是完全替换，而是按任务分流——便宜模型做大量基础工作，官方模型处理关键部分。
这样用，才是真正把钱花在刀刃上。