最近我看到一个很值得折腾的工具：OpenCodex。
它解决的是一个非常现实的问题：
你已经习惯在 Codex 里写代码、改项目、跑测试，但不同任务其实并不该永远交给同一个模型。
讨论方案时，你可能想用 Claude Fable 5。
做前端设计时，你可能想切到 Kimi K3。
查社交媒体和外部信息时，你可能更想用 Grok 系列。
真正落代码、跑命令、改仓库时，你又希望继续保留 GPT-5 / GPT-5.6 这一类执行能力。
以前的问题是，这些模型散在不同平台里。你要切窗口、换账号、复制上下文，还要担心工具调用、文件权限、项目状态丢掉。
OpenCodex 的思路很直接：别让人去搬上下文，让 Codex 通过一个本地代理去连不同 provider。
我发稿前查了一遍仓库和 NPM 包：@bitkyc08/opencodex 当前版本是 2.7.36，要求 Node 18+；GitHub 仓库是 MIT license，2026-07-24 仍有提交更新。这不是一个概念 demo，而是一个正在快速迭代的工具。
OpenCodex 官方封面：让 Codex 接入任意 LLM
● ● ●
它到底做了什么
OpenCodex 是一个本地 provider 代理。
官方 README 里的定位是：Universal provider proxy for OpenAI Codex & Claude Code。它把 Codex 的 Responses API 翻译成不同模型供应商能理解的协议。
简单说，就是在你的电脑上跑一个本地代理：
npm install -g @bitkyc08/opencodex ocx init ocx start ocx gui
然后打开：
http://localhost:10100
在浏览器管理界面里添加 provider，填 API key，或者用 OAuth 登录 Anthropic、xAI、Kimi 这类支持的账号。添加之后，模型会通过 provider 的 /v1/models 自动发现。
官方文档写得比较清楚：它支持 Codex CLI、TUI、App、SDK，也支持 Claude Code；内置 40+ provider，覆盖 Anthropic、Google、xAI、Kimi、OpenRouter、DeepSeek、Qwen、Ollama 等。
OpenCodex 官方架构图：Codex 请求先到本地代理，再路由到不同 provider
● ● ●
最关键的点：模型会出现在 Codex 选择器里
这个点很重要。
不是让你在外面再开一个聊天工具，而是让已接入的 routed models 直接出现在 Codex App 的模型选择器里。
官方 README 里也明确写到：routed models 会出现在 Codex App model picker，并且可以带 per-model reasoning effort 控制。
我现在本机的 Codex 选择器里，已经可以看到类似这样的模型项：
本机 Codex 选择器截图：路由模型已经出现在模型列表中
这意味着 Codex 仍然是你的主工作台。
仓库、文件、终端、测试、上下文都还在 Codex 里，只是你可以给不同任务换不同“大脑”。
● ● ●
为什么这件事值得关注
我一直觉得，AI 编程下一阶段拼的不是“哪个模型包打天下”，而是谁能把模型能力放进正确的位置。
一个真实项目里，至少有四类任务：
第一类是方案讨论。
你要它拆业务、识别风险、比较实现路径、指出需求里的模糊点。这类任务适合让长上下文、推理强、表达稳的模型先看一遍。
第二类是界面和交互。
不是只写一个按钮，而是判断用户怎么扫视页面，密度该多大，哪些控件该放在一起。前端设计强的模型更容易给出可用的第一版。
第三类是外部信息搜索。
比如查 GitHub、NPM、社媒讨论、产品文档、issue。这个环节需要模型愿意看原文，最好还能比较多个来源，而不是凭印象编。
第四类是执行。
落代码、改文件、跑测试、修复失败、生成可审查 diff。这个环节对工具调用、稳定性、上下文管理要求更高。
过去很多人会把这四件事都塞给一个模型。能做，但并不经济，也不总是最优。
OpenCodex 更像是把 Codex 变成一个多模型调度台。
● ● ●
可以怎么用
官方支持 provider/model 这种写法。
例如：
codex -m "anthropic/claude-opus-5" "解释这个 stack trace" codex -m "google/gemini-3-pro" "为 auth.ts 写单元测试" codex -m "ollama/llama3" "重构这个函数"
如果你配置了 Kimi、Grok、OpenRouter、OpenAI API 或本地 Ollama，也可以按对应 provider/model 路由。
更适合日常工作的方式，是把常用模型放进 Codex App 的选择器里：
OpenCodex 官方截图：Codex App 中的 routed models 与 reasoning effort
然后按任务切：
- 方案讨论：用更擅长推理和产品判断的模型。
- 前端设计：用更擅长 UI、交互和视觉结构的模型。
- 信息调研：用更擅长搜索和外部资料对照的模型。
- 最终执行：切回你最信任的 Codex 执行模型，改文件、跑测试、收口。
这不是“哪个模型替代哪个模型”，而是把模型当成团队里的不同角色。
● ● ●
它还有一个隐藏价值：保留原来的订阅能力
OpenCodex 不只是接 API key。
它还支持 ChatGPT / Codex 账户池。官方 README 提到，可以添加多个 ChatGPT / Codex 账号，在 dashboard 里刷新 5 小时、每周、30 天配额，新会话可以自动路由到使用量较低的健康账号。
这个设计对高频使用 Codex 的人很实用。
你不一定要马上把所有请求都迁走。原本订阅还能继续用，同时把某些任务切给 Anthropic、Kimi、xAI、OpenRouter 或本地模型。
对个人开发者来说，这是降成本。
对交付团队来说，这是把模型供应商风险拆开。
● ● ●
但这里有几个边界，必须说清楚
第一，OpenCodex 让模型进入 Codex 工作流，不等于你天然拥有所有模型权限。
某个模型能不能用，取决于对应 provider 是否开放、你的账号是否有权限、API key 是否可用、OAuth 是否登录成功。
第二，GPT-5.6 Sol / Terra / Luna 这类条目，官方 README 写的是 rollout-ready catalog entries，并且明确说仍受 upstream availability / preview gate 限制。
所以不要把“目录里有”理解成“你的账号现在一定能跑”。
第三，多模型调度不会自动让结果变好。
真正有价值的用法，是把任务拆清楚：
谁负责方案判断？ 谁负责资料调研？ 谁负责界面草图？ 谁负责最终执行？ 谁来验收？
如果上下文、验收标准、权限边界没有写清楚，多接几个模型只会把混乱放大。
● ● ●
我建议的安装方式
如果你想试，最简单的方式就是把 OpenCodex 仓库链接丢给 Codex：
https://github.com/lidge-jun/opencodex
然后让 Codex 帮你做这几件事：
1. 阅读 README 和安装要求； 2. 确认本机 Node 版本是否 >= 18； 3. 安装 @bitkyc08/opencodex； 4. 执行 ocx init； 5. 启动 ocx start； 6. 打开 ocx gui； 7. 添加你要用的 provider； 8. 回到 Codex 里检查模型选择器是否出现 routed models。
如果中途失败，也不要硬改配置。先让 Codex 看：
ocx status ocx sync ocx restore
官方文档也写了，ocx stop 会停止代理并恢复 Codex 原始配置；ocx restore 可以只做恢复。
这个细节让我比较放心。它不是把你的 Codex 改成一个不可逆状态。
● ● ●
真正的变化不是“模型更多”，而是“工作流变了”
以前我们讨论 AI 编程，常常问：
哪个模型最适合这一步？
现在更值得问的是：
我手里的这件事，应该交给哪个模型？
方案讨论、前端设计、社媒搜索、代码执行、测试验收，本来就不是同一种能力。
如果 OpenCodex 这类本地代理逐渐成熟，Codex 会更像一个 AI 工作台：你保留原来的项目上下文和执行环境，但可以随时切换不同模型角色。
这对企业 AI 落地尤其关键。
企业要的不是“又买了一个模型”，而是把模型放进真实流程里：谁输入、谁判断、谁执行、谁验收、出了问题谁回滚。
模型多不是重点。
能被调度、能被验证、能进入交付闭环，才是重点。
