hello!大家好!
我从 Codex 发布初期就开始使用了。当时由于预算有限,我既无力承担 20x 的高阶套餐,甚至连 5x 套餐也难以负担,只能勉强维持一个 Plus 订阅。
随着需求增长,单个 Plus 账号已无法满足我的使用量,于是我开始转向第三方中转服务。然而,随着 OpenAI 对低价账号打击力度的加大,中转服务的价格一路飙升。最终,我还是回归了官方渠道,并同时订阅了多个 Plus 账号以满足使用需求。
重度使用 Codex Plus 时,每周的额度往往很快耗尽。为了缓解这一问题,我曾尝试使用各类 CLI 工具及知名的 CC Switch 来辅助切换账号,并借此度过了一段过渡期。
然而,频繁地打开终端或通过 CC Switch 切换账号,再重启 Codex 的过程很快便令我感到厌倦。于是,我开始寻求一种更高效的解决方案。
在寻找解决方案之前,我把我的需求捋了一遍:
几个账号一起认证登录,不要手动登出登入;
新会话自动挑余量最多的账号,实现负载均衡;
已在跑的会话不要动,长任务中途换账号效果不佳;
每个账号的用量状态能一眼看到,不需要逐个登录去查,满足一下个人查看额度的需求。
如上所述,我真正需要的是在“个人”与“官方服务”之间建立一层管理机制,而目前的官方客户端并不提供此项功能。
前几天刷 GitHub,正好刷到一个对上这个需求的项目:lidge-jun/opencodex。

这是一个本地驻留代理,所有 Codex 请求均经由它进行中转,并根据逻辑自动分发至指定的账号与模型。
装好之后,再逐个添加账号。它有两个行为,正好对上我的需求。
现有会话将固定在原账户上。会话会绑定至启动它的账户,并在后续轮次中持续复用。即使在 SSH 或 tmux 等长会话场景下,也不会出现中途被切换账户的情况。
新会话将自动路由至负载最低的账户。系统会对比 5 小时、每周这三两时间窗口的用量,并选取压力最大的指标作为参考。当活跃账户达到阈值后,新会话将自动分配给余量充足的合格账户。
这两条规则相辅相成,有效解决了核心痛点:在高峰期,系统能够将压力均衡分配至多个账户;同时,对于正在进行的会话,又确保了其持久性,避免了中途切换带来的干扰。
仪表盘还能一键刷新所有账户配额,三个窗口的用量一屏看完,不用再逐个登录。
正好我手头还有 DeepSeek 和 SuperGrok,也一起添加进来!
在仪表盘中开启 Codex Auth 后,即可添加池账户,并可查看下一会话所分配的账户。若关闭自动切换功能,系统将始终锁定并使用当前账户。
另一个体现功底的细节是:当凭证失效时,系统会将账户标记为“需重新认证”,而非静默替换;当收到 429 配额限制响应时,账户会进入冷却状态,后续任务将自动切换至资源池中的其他可用账户。
该报错时即报错,因为代理后台擅自替换凭证反而会带来不可控的风险。
其他工具很多是「有存在感」的:要你记得打开,或者记得反复切换。
而 Opencodex 其最大的优势在于:使用体验极其自然,几乎察觉不到它的存在。
模型选择器依然沿用 Codex 原生逻辑,命令调用与日常操作保持一致,会话及历史记录位置也未作变动。当某个账号达到使用上限时,系统会自动平滑切换至下一个可用池;若非仪表盘中留有请求日志,我甚至察觉不到系统已完成了接力。
我的直观感受是:将多个账号的配额整合在一起,体验如同拥有了一个无限额度的账号。这正是我所追求的理想状态——让工具隐于后台,使我能专注于任务本身。
想看后台在发生什么,打开 opencodex 的仪表盘:provider、账户配额、实时请求日志都非常完整,如果需要可以随时查看。
切换账号仅仅是我的入门需求;OpenCodeX 的核心优势在于它彻底开放了模型选择权。
它支持同时接入多家供应商,包括 Anthropic、Google、xAI、DeepSeek、GLM、Kimi、OpenRouter,以及本地的 Ollama。任何兼容 OpenAI 标准的端点均可接入,README 中列出的内置提供商已超过 40 家。配置完成后,所有模型将统一呈现在同一个选择器中。
我目前同时接入了 DeepSeek 和 OpenCode Go 套餐路由的一系列模型。使用时,只需在选择器中按需切换,体验与原生模型无异,甚至还能针对特定模型调节推理强度(reasoning effort)。

命令行里也可以用 -m 直接指定:
codex -m "anthropic/claude-opus-5" "解释这个 stack trace"
codex -m "ollama/llama3" "重构这个函数"
当省略 provider/ 前缀时,系统会自动路由至默认提供商,或根据模型名称模式进行匹配(例如,claude- 开头的模型将路由至 Anthropic,gpt- 开头的模型将路由至 OpenAI)。
Claude Code 也具备同样的功能。使用 ocx claude 启动时,其选择器逻辑与原生保持一致,用户可根据需求自由选择模型。

启用此服务后,您可以在各类 CLI 工具的模型切换列表中看到并使用您添加的所有模型,随心所欲。即使在 Claude Code 中使用 DeepSeek,体验也如同官方原生支持一般,完美契合您的使用习惯。

认证方式多种多样:xAI、Anthropic 及 Kimi 支持 OAuth 登录,可实现 Token 自动刷新;此外,也支持通过转发 Codex 登录、直接粘贴 API Key 或引用环境变量(${ENV_VAR})进行配置。
在使用一段时间后,我发现了它的另一重身份:整台机器的本地网关。
OpenCodex 在本地 127.0.0.1:10100 提供统一的 API 入口。任何支持自定义请求地址的软件——无论是编辑器插件、自研脚本还是第三方客户端——均可将请求交由其处理,从而实现对同一供应商及账户池的复用。
这意味着本地工具无需再分别配置 API Key 或路由规则;只需在网关完成一次配置,即可实现全局共享。对于喜欢折腾工具的用户而言,这一设计极为实用。
以 AI 翻译软件为例,若需接入 OpenAI 服务,通常需要配置专属 API Key。此时,用户可以直接使用 OpenCodex 网关替代官方服务。鉴于目前许多软件已支持自定义 AI 服务商,这种应用方式具有非常广泛的适用性。
先说清楚,这类需求的方案不止一个。
再次介绍 CC Switch,一个开源跨平台桌面应用,统一管理 Claude Code、Codex、Gemini CLI 等工具的供应商配置,一键切换 provider,还带 MCP 和 Skills 管理。
OpenCodex 采取了截然不同的路径:通过常驻代理、账户自动接力,以及将模型直接集成至原生选择器,一旦配置完成,几乎可以实现无感使用。我个人更倾向于后者——我希望将模型切换的工作完全交给工具处理,从而彻底摆脱对此类琐事的关注。
类似思路的工具还有好几个,萝卜青菜各有所爱,选择自己喜欢的就好!
安装就两条命令,需要 Node 18+:
npm install -g @bitkyc08/opencodex
ocx start
ocx start 会启动代理,并打开 http://localhost:10100 的仪表盘;添加 provider、选模型、管账户都在网页里完成。随时可以跑 ocx gui 重新打开。想后台常驻、开机自启,用 ocx service。
几个常用命令:
ocx status:看代理是否在运行
ocx account list:查看账户和用量,脱敏显示
ocx stop:停掉代理,并把 Codex 恢复成原始配置
最后一点尤为值得一提:在停止运行 OCX 后,Codex 的表现如同从未安装过 OpenCodex 一般——既无残留配置,也无僵尸进程。对于这类会修改客户端配置的工具而言,能够实现“干净退出”至关重要。
没有人希望软件卸载后仍留有冗余文件,正如没有人喜欢 macOS 在用户目录中留下 .DS_Store 文件一样 😆。
安装时如果遇到 bundled Bun runtime is missing,说明 npm 拦截了安装脚本。用 npm install -g --allow-scripts=bun @bitkyc08/opencodex 重装,别加 --ignore-scripts。
若您打算尝试使用 OpenCodex,请先注意以下几点:
OpenCodex 是一个社区驱动的开源项目,与 OpenAI、Anthropic 等官方机构无任何关联。请注意,部分服务提供商(尤其是 Anthropic)可能会对通过第三方代理路由 API 流量的账户采取限制措施。正如 README 文档中所明确声明的:使用风险需由用户自行承担。
回顾这一需求,初衷其实很简单:摆脱繁琐的账号切换,无需担忧配额耗尽,并能根据需求自由选择模型。
OpenCodex 将这三个痛点整合为一个常驻本地代理:通过自动轮询账号池和聚合多供应商接口,使其成为整台机器的统一网关。如果你也厌倦了在多个账号间频繁切换,花十分钟尝试一下非常值得。
AI 的发展实在太快,也许这个方案再过一段时间就过时,到时候如果有更好的方案,我还会分享出来给大家!
