lidge-jun/opencodex 是什么？

opencodex 是一个本地代理，把 Codex 的 Responses API 翻译成各家模型能听懂的话。40 多个内置提供商、账号池和组合路由是它的卖点，但账号池的合规边界需要你自己拿捏。

lidge-jun/opencodex 可以商用吗？

可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。

lidge-jun/opencodex 还在维护吗？

在维护。仓库在最近一天内有新的提交。

lidge-jun/opencodex 是用什么编程语言写的？

主要是 TypeScript（依据 GitHub 的语言统计）。

opencodex 评测：用 Claude、Gemini、DeepSeek 跑 Codex 和 Claude Code

Q: lidge-jun/opencodex 还在维护吗？

在维护。仓库在最近一天内有新的提交。

秒懂

它是什么？: opencodex 是一个本地代理，把 Codex 的 Responses API 翻译成各家模型能听懂的话。40 多个内置提供商、账号池和组合路由是它的卖点，但账号池的合规边界需要你自己拿捏。
适合谁用？: 适合两类人：一是手上捏着多个模型 API key、想在一个编辑器里切换后端的开发者，二是需要给 Codex 会话做账号级故障转移的团队。不适合把账号池当成绕开限速手段的人，README 明确写了不背书这种行为，而且路由和故障转移不保证能躲过提供商的风控。
能商用吗？: 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
还在维护吗？: 在维护。仓库在最近一天内有新的提交。
用什么语言写的？: 主要是 TypeScript（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年8月8日 · lidge-jun/opencodex

它解决的是模型锁定，不是代理性能

Codex CLI 官方只认 OpenAI 的模型，Claude Code 只认 Anthropic 的。你买了 DeepSeek 或者本地 Ollama 的算力，想在 Codex 的界面里用，官方工具不给这条路。opencodex 干的事就是在本地开一个端口，把 Codex 发出的 Responses API 请求翻译成目标提供商能接受的格式，再把流式响应、工具调用、推理 token 和图片原路翻回来。它不碰你的工作流，你还是在 Codex 里选模型、看 diff、提交。README 里那句 "The picker is stock Codex. The brain behind it isn't" 说得挺准，它换的是脑子，不是身体。

双向翻译的代理机制

整个项目是个本地代理，默认监听 localhost:10100。Codex 和 Claude Code 把请求发给它，它负责把 Responses API 的协议翻译成 Anthropic Messages API、Gemini 的格式或者其他 OpenAI 兼容端点的格式。翻译不是单向的，工具调用和推理 token 要能从目标模型那边传回 Codex 的会话上下文，图片也要能双向走。README 特别提到 streaming 和 tool calls 是双向的，这说明它不是在边界上做简单的请求转发，而是维护了一套协议映射。这套映射的完整程度直接决定你能不能用上目标模型的全部能力，比如某些模型不输出 reasoning tokens，代理得知道怎么处理这个空缺。

两条启动路径：人用和 agent 用

安装就一条命令：npm install -g @bitkyc08/opencodex，Node 要求 18 以上，Bun 运行时会随 npm 包一起装好，不用单独装。启动分两种方式，ocx start 是前台跑，ocx service 是后台跑。人用的话，打开 http://localhost:10100 在网页 dashboard 里配置提供商和模型，40 多个内置提供商之外还能填任意 OpenAI 兼容端点。给 agent 用的话，ocx init 会交互式地写 ~/.opencodex/config.json 并接好 Codex。注意 ocx init 不会启动代理，而 ocx provider add 和 ocx combo set 这类命令必须连到活着的代理上，连不上就非零退出。所以顺序是先 start 再 init，或者反过来也行，但 headless 命令必须在代理活着的时候跑。

账号池：路由是卖点，合规是雷区

账号池是 opencodex 最重的一个功能。你可以往 dashboard 里塞多个 ChatGPT 或 Codex 账号，代理会刷新每个账号的 5 小时、每周和 30 天配额。新会话默认路由到用量最低的健康账号，已有线程保持对起始账号的亲和，这样长时间跑在 ssh 或 tmux 里的会话不会中途跳账号。但配额重新评估、故障转移、账号被排除、亲和过期、401/403 和 429 恢复都会让线程重新绑定账号。README 里有一大段免责声明，说账号池只用于路由和运维韧性，不保证能躲过提供商的限速、封禁或暂停，也不背书用多账号绕限速。这个功能对团队管理多个合法账号有用，但你要是冲着绕风控去的，文档已经把责任推回给你了。

Combo 和子代理：把路由规则变成配置

Combo 是另一个值得注意的设计，它把一个虚拟模型 ID 映射到多个提供商上，支持故障转移和加权轮询。比如你定义一个 combo 叫 main，里面 70% 流量走 Claude，30% 走 Gemini，Claude 挂了就全量切到 Gemini。子代理功能则针对 Codex 的子代理选择器，可以让不同子代理跑在不同模型上，还支持 v1/v2 表面控制和回退链。这两个功能合起来的意思是，你不需要在代码里写死模型选择逻辑，路由策略是配置项，改的时候只动 dashboard 或者配置文件。对于有多个模型订阅、想按成本或质量分流的人来说，这比手动切换 API key 实用得多。

平台覆盖和它隐含的维护成本

macOS 用 launchd，Linux 用 systemd 用户单元，Windows 用 Task Scheduler 或者可选的 WinSW 原生服务。Windows 上不用 WSL，这是个实在的便利。但跨三个平台、三种服务管理器，意味着每个平台的安装和排障路径都不一样。npm 安装时如果脚本被拦截，Bun 运行时装不上，你得去翻安装文档。版本节奏很快，最近一个月内从 v2.34.0 推到 v2.36.0-preview，预览版里包含内存所有权补丁和运行时 GC 改进。对生产环境来说，追 preview 版本要谨慎，但等稳定版又可能错过内存相关的修复。这个项目的维护节奏是活跃的，代价是你得跟着它的发布频率走。

替代方案和它的本质区别

同类工具里最常被拿来比的是 LiteLLM 或者直接写一个 OpenAI 兼容的本地网关。LiteLLM 的路线是统一出口，你把自己的服务接到它上面，它再转发到几百个提供商，侧重的是 API 层的标准化。opencodex 的路线是反向的，它适配的是 Codex 和 Claude Code 这两个特定客户端的协议，你不需要改客户端，代理去迁就客户端的方言。另一个区别是账号池，LiteLLM 管的是 API key 和预算，opencodex 管的是 ChatGPT 账号的配额刷新和会话亲和，这是两种完全不同的资源抽象。选哪个取决于你的入口是什么，你主要用 Codex 和 Claude Code 就选 opencodex，你写自己的应用要接多家模型就选 LiteLLM 那类网关。

许可证和你能拿到的边界

项目是 MIT 许可证，这是最宽松的那一类，商用、改源码、闭源分发都不受限制。npm 包名是 @bitkyc08/opencodex，跟 GitHub 仓库名 lidge-jun/opencodex 不完全一致，装的时候别搞错。文档站是 opencodex.me，README 里链接齐全。一个务实的提醒：代理的翻译层做得再完整，也不等于目标模型的所有能力都能透传。某些模型特有的参数或者输出格式，代理没映射的话就丢了。文档说支持流式、工具调用、推理 token 和图片，但没列全每个提供商的支持矩阵，真要上生产，先拿你打算用的那个模型跑一遍工具调用和长上下文，确认翻译层没丢东西。

编辑结论

适合两类人：一是手上捏着多个模型 API key、想在一个编辑器里切换后端的开发者，二是需要给 Codex 会话做账号级故障转移的团队。不适合把账号池当成绕开限速手段的人，README 明确写了不背书这种行为，而且路由和故障转移不保证能躲过提供商的风控。想用之前先验证三件事：你的 Node 版本在 18 以上，npm 安装时 Bun 运行时没有被脚本策略拦掉，以及你用的提供商是否允许通过第三方代理转发流量。账号池的线程亲和、配额刷新和 401/403 恢复逻辑都依赖 dashboard 里的实时状态，headless 环境里要先确认代理真的在跑，否则 ocx provider add 这类命令会直接非零退出。

官方来源

社区笔记