opencodex：让 Codex 与 Claude Code 接任意模型

Codex CLI 和 Codex App 绑死在 OpenAI 的模型上，Claude Code 绑死在 Anthropic 系列，Claude Desktop 也一样。想让这几个客户端跑别的模型，过去的做法要么等客户端自己开放配置项，要么自己维护一层转换脚本去改请求和响应。前一种要等，后一种每次上游协议动一下就得跟着改。opencodex 把这层转换做成了一个跑在本地的进程。

opencodex 是 TypeScript 写的本地 LLM 代理，把 Codex 的 Responses API 转成各家模型协议，让 Codex 与 Claude Code 用上任意模型。

它夹在客户端和模型服务中间。客户端照常把请求发到本地端口，代理翻译成上游听得懂的格式，再把回来的流式输出、工具调用、推理 token、图片按客户端认识的协议转回去。上游可以是 Claude、Gemini、Grok、GLM、DeepSeek、Kimi、Qwen、Ollama，也可以是任何 OpenAI 兼容端点，内置 provider 有 40 多家。

仓库地址是 https://github.com/lidge-jun/opencodex，MIT 许可证，代码以 TypeScript 为主，占 96.9%。截止 2026-09-30 抓取时，它有 16691 star、1253 fork、26 watcher、114 个开放 Issue，最近一次提交在 2026-09-30，npm 上最新版本是 v2.73.0，包名 @bitkyc08/opencodex。

这件事以前怎么做

Codex 系客户端跟 OpenAI 的协议绑在一起，Claude Code 跟 Anthropic 绑在一起。想让它们跑名单外的模型，常见路径就是等官方支持，或者自己写转换脚本，用一层适配去抹平请求结构和响应格式的差异。

多账号的麻烦在另一头。几个 ChatGPT 账号的 5 小时、每周、30 天配额各剩多少，通常靠人记；会话跑到一半想换账号，上下文容易断。仓库的事实材料里没有给出此前方案的具体形态，这两处是它要接手的事情。

换成它之后

1. 装。终端里跑 npm install -g @bitkyc08/opencodex，要求 Node 18+，Bun 运行时由这个包自带，不用另外装。
2. 起。跑 ocx start，代理和 dashboard 一起起来，默认监听 localhost:10100。要它常驻后台，用 ocx service。
3. 配。浏览器打开 http://localhost:10100，在 dashboard 里加 provider。内置 40 多家，也可以填任何 OpenAI 兼容端点，然后挑模型。ocx gui 可以随时把 dashboard 重新打开。
4. 接。Codex CLI、Codex App、Codex SDK、Claude Code、Claude Desktop、Grok Build 都指向这个代理就行，客户端那边看到的还是它自己的协议。
5. 管账号。多个 ChatGPT / Codex 账号加进账号池，dashboard 里刷 5h、weekly、30d 三档配额。路由策略有 quota、round-robin、fill-first 三种：quota 策略下新会话挑用量最低的健康账号，另外两种各按自己的规则走。也可以给账号排一个选择顺序，把比如 Codex Desktop 的登录账号留到后面再动用。
6. 桌面版。目前是 beta。macOS 13+ 拿 .dmg，已经用 Developer ID 签名并公证；Windows x64 拿 .msi，尚未代码签名，SmartScreen 会问一次；Linux x86_64 拿 .AppImage 或 .deb，托盘需要桌面环境支持 AppIndicator。

协议翻译这一层是双向的，streaming、tool calls、reasoning tokens、images 都在覆盖范围内。仓库里还有 Dockerfile 和 compose.yaml，走容器部署的可以从这两个文件入手。

怎么接进现有流程

输入是客户端发到本地 10100 端口的请求，输出是代理转发给上游 provider 的请求和回传的响应流。客户端不用改代码，代理也不碰客户端的业务逻辑。

代理需要一直挂着。命令行方式用 ocx service 让它后台常驻；桌面版带托盘，可以附着到一个已经在跑的代理上，也可以启用它自带的那个，dashboard 始终跟着代理端口走。仓库里没有说明它自带定时任务，配额刷新需要在 dashboard 里手动触发。

账号亲和这块要留意：已有的 Codex 线程默认绑在启动它的那个账号上，SSH、tmux、手机连着的长会话不会中途跳账号。配额重新评估、failover、账号排除、亲和过期，以及 401/403 和 429 的恢复流程，都可能让线程重新绑定。

账号池只该拿自己拥有、或者已经拿到明确授权的账号来用。多个账号的注册与使用要遵守上游服务商的条款，把订阅额度对外转给别人用可能违反条款，也会带来账号被封的风险。

同类项目的横向对照

选型上有一处要摆明：opencodex 的客户端面集中在 Codex 系与 Claude Code 系，如果你的入口在 Cursor、Cline、Aider 或 Copilot，那两个项目覆盖的客户端更贴你的日常，这一点 opencodex 不如它们。它的优势在账号池：要让 Codex App 和 Claude Desktop 同时接非原生模型，又要按配额自动分配账号，目前给的方案最具体。另外两个项目在给定材料里没有提到账号池，这部分是否支持需要你自己核实。

它替代不了的部分

• 它不训练也不托管模型，换掉的是客户端的模型来源，模型本身的能力仍由上游 provider 决定。
• 集中托管的多用户模式还没有。Issue 里「Centrally hosted multi-user OpenCodex with tenant isolation」仍在 roadmap 上、标着待解决，要多人共用一套代理并做租户隔离，目前没有官方方案。
• 桌面版处于 beta 阶段，Linux 托盘依赖 AppIndicator，Windows 安装包没有代码签名。
• 仓库里没有说明它覆盖上面几个客户端之外的场景。

真实用户踩过的坑集中在协议边缘。有人在会话里遇到第一次失败之后频繁的 502 upstream_server_error，报的场景是 gpt-5.6-sol 配 OpenAI，这条已经解决。Windows 上 ocx service stop 报告成功但代理并没有停，--native 开关还会破坏已有的 backend，这条也已经解决。Codex WebSocket 在一轮对话中途断掉后没有 SSE 回退，记录里 prelude-timeout 那半已修掉，整条按已解决处理。还有一条待解决的是 provenance-aware Codex CLI update manager，用来跟踪 Codex 运行时的来源。

值不值得换

下面几种情况换它划算：主力客户端是 Codex CLI、Codex App 或 Claude Code，而你要用的模型不在 OpenAI 或 Anthropic 的名单里；手上有多个 ChatGPT 或 Anthropic 账号，需要按配额给新会话自动分配，又不想让长会话中途换账号；你要的是本地代理，不打算把请求送进第三方托管的中转。

日常工作主要在 Cursor、Cline、Aider、Copilot 这类 IDE 客户端里完成的人，不该换它，去用 9router 或 dario 更贴入口。需要多人共享一套代理并做租户隔离，现在也不该选它。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 10.0 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。