我们团队每个人都开了 Plus 或 Pro(8+3)，但真正卡住我们的，反而不是钱。
卡住我们的只有两个问题：额度怎么分，原生能力怎么保住。个人账号解决的是入口，团队真正需要的是可调度的使用权。
这就是我们最后决定自建 Codex 中转的原因。
额度不是按人平均消耗的团队有 10 多个人，都在用 Codex。表面上看，每个人都有自己的 Plus 或 Pro，好像已经够用了。
但真正跑起来以后，资源不是这么消耗的。
有的人当天只是问几个问题，有的人会连续处理多个项目、多个仓库、多个上下文。轻度用户的额度还在，重度用户已经开始等 5 小时窗口恢复，甚至周窗口也会提前见底。
我们看过 2026-05-09 的个人排行，那天活跃 11 人，Token 消耗差异非常明显。排在前面的有团队负责人，也有服务端、前端、测试；靠后的成员里也有开发、测试、产品。
这张排行给我的感受很直接：AI 使用量不是按岗位平均分布的，也不是按账号平均分布的，而是按任务密度和上下文复杂度集中爆发。
所以，只靠“每个人一个 账户”，解决不了团队级 Codex 使用的峰值问题。
只走 key，会割裂原生能力另一条路是直接走 key。
这也是很多中转平台更常见的方式。调用统一，成本清晰，也更容易做资源调度。
但我们很快遇到第二个问题：很多 ChatGPT 登录下的高阶能力，就不好用了。
比如 Codex 的原生能力，ChatGPT 里的插件、小工具、小宠物，以及绘图、视频剪辑相关的插件能力。这些东西不是一个 API key 就能完整替代的。
如果全切 key，调用层是顺了，但用户体验会断。
这对我们来说不是小问题。团队每天不是只在“调用模型”，而是在 ChatGPT 和 Codex 的原生生态里完成工作。如果中转让调用变顺，却把原生能力切掉，那只是把一个问题换成了另一个问题。
所以我们把登录权和调用权拆开最后我们基于sub2API自建了一层中转。
核心思路不是重写一套系统，而是把登录权和调用权拆开。
登录仍然走 ChatGPT。每个人继续登录自己的账号，保留自己的高级功能、插件能力和原生体验。
调用层再通过自建中转处理。我们只在入口端做兼容，不动原来的登录鉴权主链，只改全局config.toml。具体做法是在base_url上增加一个字段，用来存储个人密钥。正式发起调用时，如果识别到 URL 上带了个人密钥，就自动转成密钥鉴权模式。
我把原来的标准路径定义为模式1。新路径相当于模式2：入口识别个人 key，由服务端自动转为模式1，再调用后面的链路。
这样只在入口做一次转换，后面的调用链不需要改。
这件事落地很快，原因也在这里：我们没有推翻原来的鉴权系统，只是在最小入口上做兼容。
中转解决的不是省钱问题这层中转真正解决的，不是“省几个账号钱”。
如果只为了省钱，很容易走偏，也容易踩到账号共享和合规风险。我们不是让所有人共用一个账号，而是每个人继续使用自己的账号，只是在团队层面把调用方式、资源消耗和能力边界管起来。
它解决的是两个更真实的问题。
第一，资源调度。谁重度用、谁轻度用，不能只靠订阅套餐自然分配。中转层让使用权可以被观察、被配置、被调整。
第二，能力兼容。只用 key 会丢掉 ChatGPT 原生生态，只用账号又会被个人窗口卡住。把登录权和调用权拆开，才有可能两边都保住。
我后来再看 OpenAI 的官方说明，也更能理解这个问题：Codex 的用量和计划、任务复杂度、执行方式相关。任务越大，上下文越长，每次消耗就越高。达到上限后，就只能等窗口恢复；如果需要更多本地任务，可以使用 API key。
这句话放到团队里看，就很现实：个人订阅是入口，不是团队资源系统。
使用权要能被自己把握我不是不信任第三方中转。
但当一个能力开始变成团队每天都要用的基础设施，我会倾向于把关键控制点留在自己手里。尤其是鉴权、调用、配置、日志、资源分配这些位置，它们不只是技术细节，而是团队工作流的边界。
只有使用权掌握在自己手里，安全才不是一句口号，而是一套可以调整、可以验证、可以回退的系统。
我们一开始以为问题是账号不够。后来发现，问题是账号这种分配单位太粗了。
团队真正需要管理的，不只是有没有 Pro，而是谁在什么任务里需要多少调用、用什么方式调用、出了问题能不能追踪和回退。
所以这次自建 Codex 中转，对我来说不是一个工具技巧。
它更像是一次提醒：当 AI 真的进入团队生产流程以后，买账号只是第一步。后面真正要补的，是使用权、调用权和能力边界的系统设计。
如果你的团队也在重度使用 Codex，你现在更卡的是额度不够，还是原生能力和 key 调用割裂？