Codex遇上DeepSeek，省钱了，但先别高兴太早
OpenAI的Codex原本只认自家的Responses API，DeepSeek那边只提供Chat Completions API，两个接口鸡同鸭讲。一个叫codex-deepseek-bridge的桥接工具冒出来，在中间做协议翻译，让Codex以为还在跟OpenAI聊天，实际上背后已经换成DeepSeek的模型在跑。这玩意儿省钱的诱惑力太强了，但中间的水比你想象的要深。
这个桥接工具到底解决了什么问题
2026年初开始，Codex逐步放弃了旧的Chat Completions接口，全面转向/v1/responses。DeepSeek官方API走的是/v1/chat/completions路线。以前在配置文件里写wire_api = "chat"就能搞定的事，现在直接报错不干活。
这种不兼容直接导致以前那种改个配置就能切换模型的路子彻底废了。社区里一堆人拿着config.toml改来改去，最后发现Codex根本不认DeepSeek的接口格式，直接卡死在连接阶段。
codex-deepseek-bridge这个项目就是在这个背景下冒出来的。作者自己也在Reddit上承认，以前用LiteLLM做转发太笨重了，索性周末从头写了一个专门做Responses到Chat翻译的轻量级桥接层。
这个桥接的流程大概是这样的：Codex发出的请求先打到本地代理，代理把/v1/responses格式转成/v1/chat/completions发给DeepSeek，DeepSeek返回的数据再被重新打包成Codex能认的格式传回去。整个过程对Codex来说是完全透明的，它根本不知道自己对面站的是DeepSeek。
Tool Calling是怎么被救活的
光做协议转发其实不难，难的是把Tool Calling也保住。普通转发很容易翻车，最常见的报错就是Tool Call丢失或者Function Call格式不对。
问题出在消息链的维护上。Codex那边的工具调用走的是Responses API的那套逻辑，DeepSeek这边只认Chat Completions的格式，中间差了好几个字段。如果只是简单地把请求体转发了事，DeepSeek返回的tool调用结果Codex压根不认。
桥接的做法是自己在本地维护一个Assistant→Tool→Assistant的消息链结构。Codex发过来的工具调用请求被拆开，转成DeepSeek能理解的chat格式，等DeepSeek把结果返回之后，再重新组装成Codex期望的response格式。
这样做的好处是文件操作、Shell执行、MCP服务这些依赖工具调用的功能都能正常工作。坏处是只要Codex或者DeepSeek任何一边改了API格式，桥接这边就得跟着打补丁。
Reasoning缓存这个坑你躲不掉
DeepSeek的推理模型会在返回内容里带一个reasoning_content字段，存的是模型思考过程的内部推理链。很多客户端拿到这个字段之后直接扔了，根本不会存下来。
下一轮请求发过去的时候问题就来了。Codex那边的对话上下文里缺少了推理内容，DeepSeek收到请求之后发现格式不对，直接甩一个400 Bad Request回来，报错信息写着Missing reasoning_content。
桥接的做法是在本地把每一轮的reasoning_content缓存下来，下次发请求的时候自动补回消息链里。这样Codex那边看到的就是完整的多轮对话历史，DeepSeek收到的也是符合它格式要求的完整请求。
流式输出和MCP兼容是怎么做到的
流式输出这块，DeepSeek那边本身支持SSE Streaming，桥接只需要把Codex的流式请求转成DeepSeek的流式请求，再把返回的流式数据重新封装一遍就行。效果就是在Codex界面里依然能看到Thinking...Generating...这种渐进式反馈，不用干等着全部生成完再一次性吐出来。
MCP兼容性算是这个桥接的一个卖点。作者在GitHub上专门强调MCP Servers、Plugins、Agent Tools这些都不需要修改，从Codex的角度看自己仍然连的是OpenAI，中间多了一层本地代理完全不影响MCP的工作。
这玩意儿到底适合谁
第一类人是已经在用Codex CLI或者Codex App，但不想继续付OpenAI那套高价模型费用的。DeepSeek-V4-Pro和DeepSeek-V4-Flash的价格跟OpenAI比起来差了一个数量级以上，对于大量写代码的场景来说省钱效果非常明显。
第二类人是喜欢Codex的Agent能力和工具生态，但更喜欢DeepSeek的价格的。Codex的优势在于它的插件系统、MCP集成、还有各种开箱即用的工具支持，DeepSeek的优势在于便宜，桥接把这两个优势拼在一起。
第三类人想搭建Codex→DeepSeek→MCP→本地工具这套完整开发工作流的。这套链路跑通了之后，可以用极低成本跑一个带工具调用的编程Agent，对于个人开发者或者小团队来说性价比很高。
省钱是真的，但有些坑你得知道
桥接只能解决协议兼容问题，解决不了模型能力差异。复杂代码规划任务里GPT-5.5和Claude Opus通常还是比DeepSeek强。这不是桥接的锅，是模型本身的差距。
再一个这项目是社区方案，不是官方出的。Codex那边API一改或者DeepSeek这边接口一升级，桥接就得跟着修。Reddit上已经有人反映MacBook M1上跑这个桥接遇到了invalid JSON body的报错，作者在评论区说提交issue被限制了，问题暂时还没解决。
还有一个小问题是多轮Tool Call和长上下文场景下可能还有一些兼容边角问题没覆盖到。随着Codex版本不断升级，新的适配需求肯定会冒出来。
本质上就是个协议翻译器
Codex只会说OpenAI的Responses API，DeepSeek只听得懂Chat Completions API。codex-deepseek-bridge在中间当翻译，让两边能聊起来，同时尽量保住Tool Calling、MCP、Reasoning和流式输出这些关键功能。
对于想用DeepSeek的成本跑Codex工作流的人来说，这是目前社区里最实用的一类桥接方案。虽然有一些边角兼容问题要处理，但比起自己从头折腾LiteLLM或者9router要省心多了。不过也别指望它能抹平模型本身的能力差距，协议能翻译，智商翻译不了。
一句话总结：codex-deepseek-bridge在Codex和DeepSeek之间搭了一座协议翻译桥，让你能用DeepSeek的低价跑Codex的工作流，Tool Calling和MCP都能保住，但别指望它能抹平模型智商差距。