OpenAI 要把目前分开的两份额度合在一起。ChatGPT 和 Codex 的官方用量上限页面在 11 月初更新，页面说明：从 12 月开始，Plus、Pro 和 Business 计划将拥有一份统一的使用额度，由 ChatGPT 和 Codex 共享，按 token 计量。即时聊天不计入这份额度。
这句话本身很短，但对写代码的人影响很大。到目前为止，用掉写代码的额度不会影响还剩多少可以聊天。从 12 月起，会。
12 月到底改变了什么？
两点：额度池不再分开，计量单位变成 token。其他部分基本不变。你可以在 Settings → Usage 查看合并后的余额和重置时间；达到上限后，可以等重置、升级计划，或为符合条件的功能购买额度。
| 属性 | 目前 | 从 12 月起 |
|---|---|---|
| 额度适用范围 | ChatGPT 和 Codex 各自独立 | 一份额度，两者共用 |
| 计量方式 | 按产品、按模型设上限 | 按 token，取决于模型和任务复杂度 |
| 在哪里看余额 | 按产品分别查看 | Settings → Usage 里的合并余额和重置时间 |
| 额度用完后 | 等重置或更换计划 | 等重置、更换计划或购买额度 |
来源：OpenAI 官方 ChatGPT 与 Codex 用量上限页面，2026 年 11 月初更新，2026-11-06 查阅。
为什么订阅用户并不买账？
因为这次合并在一个原本就不信任的基础上落地。过去两周，订阅用户的论坛几乎变成了一串报告：额度消失得比用户自己算的快。
- 2026-11-04，r/codex 上一个 66 条评论的帖子，概括了用 Plus 计划做项目的人的担忧：如果聊天也消耗额度，写代码的时间就会被压缩。
- 2026-11-05，r/codex 上另一个 64 条评论的帖子，暴露的是合并之前就存在的问题：发帖人以为上限翻倍了，后来编辑帖子更正，说其实什么都没翻倍。如果订阅用户连现在的限制都读不懂，12 月的改动就来得最不是时候。
- 2026-11-06，r/ChatGPT 上一个 54 条评论的帖子，贴出了官方页面本身的截图，以及一位 Plus 用户认为自己的工作流会被打乱的反馈。
另一边的理由也成立，而且就写在页面上：这次改动是为了把 Work 的智能体能力带进 ChatGPT，OpenAI 表示预计大多数用户不需要比现在更频繁地等待重置。共享额度也有实际好处：不用聊天的人可以把全部额度花在代码上，不用代码的人可以把全部额度花在聊天上。
问题不在于共享这个想法。问题在于管理这个余额的计量器。
81 条异常用量报告说明了什么？
从 2026-08-27 起，Codex 仓库一直挂着一个跟踪 issue，#41220，有 81 条评论，标签是 bug 和 rate-limits。它没有断言唯一根因，而是把报告汇总在一起，指向一个不舒服的模式：用量对不上客户端自己记录的数值。
跟踪器里引用的三个例子：
- #38728：同一账号、同一个 7 天周期、同一个重置时间和同一个服务等级。计量器在周期中途加速了约 2.4 倍，之后又回到之前的范围。
- #40067：智能体本地日志合计约 939 万输入 token，官方用量档案却给同一账号记了 8,170 万。
- #37445：受控实验：客户端全部关闭 103 小时 47 分钟，用量为 0%。打开桌面应用后，每周额度被固定扣掉约 6%，退出应用后消耗停止。
这些都没有得到 OpenAI 的确认，跟踪器本身也写得很清楚。但实际结论不取决于谁对：如果决定你今天的那个数字在你这边无法审计，你花钱靠的是信任，不是预算。到 12 月，这份信任还要扩展到聊天上。
能审计自己的 Codex 用量吗？
只能部分做到。Codex 提供了三层有用的信息，但都不是官方审计工具。
- 状态栏。
/statusline命令用来配置底栏显示什么，可选项里包含主、次用量上限。/status显示当前模型、审批模式和本会话的 token 用量。 - 本地日志。每个会话都会在
~/.codex/sessions/下写入一个rollout-*.jsonl文件。这是最接近客户端所见内容的来源。 - 第三方审计。像 usage-engineer 这样的工具会读取这些日志，按天汇总用量。安装命令是
pipx install git+https://github.com/noamshorts22-prog/usage-engineer，运行命令是ue audit --by-day --days 14。
这种审计的边界和问题本身一样：服务端施加的东西，比如按模型加权、后台活动或额度核对，不会出现在本地日志里。所以两份报告可以互相矛盾，而用户并没有算错。
这对按额度付费的人有什么启示？
三点，而且都不只适用于 OpenAI。
- 共享额度把两个决定变成一个。聊天里的每一个问题，都要和下一个代码任务抢同一份余额。在同一个计划里既写代码又聊天的人，失去了原本免费的隔离。
- 按 token 计量让任务的成本对用户更不可预测。重复处理的上下文、重试、子智能体和轮询都会计入。跟踪器引用了一个案例：本地 token 总量中有 19.8% 来自唯一的动作只是等待或查询状态的回合。
- 你无法审计的计量不叫预算。那叫信任。当余额池只有一个时，计量错误就不再是账单细节，而是产品决策。
Verboo Code 的立场是什么？
Verboo Code 不按消息售卖，计划内部也不按 token 计费。每个计划价格固定。在 Junior、Pro、Max 和 Ultra 计划中，提供不限 token 的用量，模型之间变化的是速度，不是额度的价格。/usage 命令显示你所在分组的速率限制窗口、已用比例以及每个窗口的重置时间。
这并不让选择变成免费的。如果任务必须依赖某个特定的前沿模型，Verboo Code 可能不是适合它的工具。它真正解决的是 12 月那个问题：当聊天和代码共用同一个天花板，每一个学习中的提问在计划里都会产生机会成本。
如果你 12 月的难题是要在聊天和代码之间分配额度，Verboo Code 把这两件事分开：按计划固定价格，速率限制窗口在 /usage 里可见。你可以带着自己的仓库从 verboo.ai 开始。
