看到 ChatGPT 或 Codex 的额度突然减少,先打开 Settings → Usage;共享计划用量不等于同一任务被重复扣费。
如果用量面板还有余额,就先别急着把失败归因于“共用额度”。完整报错、当前账户与工作区、使用的模型和入口,往往比一句“被限流了”更能定位问题。
V2EX 帖子里附带的邮件开头写道:
In the coming weeks, we’ll start testing a combined experience for Chat and Work tabs in ChatGPT with a small group of users.
这段话能说明 OpenAI 正在小范围测试 Chat 与 Work 的组合体验,不能证明所有账户已经按某种倍率扣费,更不能据此推断 Codex 的具体消耗比例。现有资料转述的另一份公告称,从 12 月起,Plus、Pro 和 Business 用户在 ChatGPT 与 Codex 之间共享统一用量。两件事需要分开看,测试通知不等于正式计费规则已经对每个账户生效。
先看用量页
Settings → Usage 是目前最直接的核对入口。资料转述的公告称,这里会显示合并后的剩余额度和下次重置时间;Codex 使用页面接近上限时,也会给出限额提醒以及当前计划可用的处理选项。
团队账户还要多核对一层:个人看到的剩余量未必等于整个工作区的消耗情况,应同时确认当前查看的是个人账户还是团队工作区。现有资料提到了管理员用量视角,但没有提供完整、稳定的菜单路径,因此不要照搬旧截图,具体入口应以当前管理后台为准。
Codex CLI 是否提供可在本机核验的剩余量查询命令,也应查看当前版本的客户端帮助。现有资料没有给出可核验的命令和输出,这里不写一个无法验证的“万能命令”。
测试和计费变更不是一回事
较早的资料已经把 Codex、ChatGPT Work 和 ChatGPT for Excel 归入同一个 Agentic 使用池,同时指出普通对话不属于这个池子。 后续资料说明,ChatGPT 与 Codex 将采用统一额度,并把 Instant Chat 列为不占用共享额度的例外。
现有资料并不支持“所有 ChatGPT 功能从一开始就与 Codex 完全同额”。Agentic 和编码相关能力较早就已经存在共享计量关系;后来公告扩大并统一了 ChatGPT 与 Codex 的计划用量安排。普通聊天仍可能有自己的模型、消息或频率限制。
截至现有资料发布时点,各档共享池的具体 Token 数量、12 月的具体生效日以及完整功能映射都没有给出。是否已经对你的账户生效,最终应看 Settings → Usage,而不是只看邮件或社区截图。
共享范围不是整个 ChatGPT
几个入口的计费关系并不相同:
| 入口 | 与计划用量的关系 | 核对位置 |
|---|---|---|
| Codex | 按公告口径,计入 ChatGPT 与 Codex 的统一用量 | Settings → Usage |
| ChatGPT Work | 按对应的 Agentic 和计划用量规则计入 | Settings → Usage |
| ChatGPT for Excel | 较早资料列入共用 Agentic 使用池;当前映射以账户说明为准 | 用量页及当前帮助文档 |
| Instant Chat | 资料明确称不占用共享额度 | 当前账户是否提供该入口 |
| 普通 Chat | 不能仅因入口在 ChatGPT 内就推断共享,其他限制仍按单独说明查看 | 对应模型或功能的限制说明 |
| API | 使用独立计费记录,不与套餐剩余量混算 | API 用量与账单 |
其中,Instant 有明确例外;其他功能不能看到“ChatGPT”这个外壳就直接算进 Codex 配额。
这里的“共用”表示 Work 做完一个长任务后,随后可用的 Codex 或 Agentic 用量可能随之减少;它不表示入口不同就自动重复扣费,也没有资料依据支持“同一任务会被系统扣两次”。
额度为什么掉得忽快忽慢
统一用量按 Token 计量,但一次任务消耗多少,并不只看发了多少条消息。模型选择、任务复杂度、推理量、上下文大小、工具调用、文件规模和执行路径都可能改变实际消耗。
小脚本可能只消耗一点,运行数小时、需要反复读取文件和执行命令的大项目则会更快消耗。这里没有可靠的比例关系,也不能套用“一条消息等于一次”。即使官方给出过消息数范围,那也是估算值,不是每个账户都能稳定发送的固定次数。
套餐的实时额度和费率应以 OpenAI 当前 Pricing 页面为准。旧文章里的套餐倍率、消息次数或消耗比例都可能被后续调整,不适合拿来估算还能运行几个任务。
四类数字不要混
套餐用量回答的是“这个计费周期还剩多少、什么时候重置”;上下文窗口数字回答的是“当前会话还能容纳多少信息”。上下文已经接近或达到窗口上限,不代表订阅额度已经耗尽。
Credits 是增购的余额,API 账单则是另一套独立计费记录。套餐剩余量没有归零,不代表 API 一定免费;API 产生了费用,也不代表 ChatGPT 与 Codex 的共享池已经见底。
这几类数字不能拿其中一个反推另外三个。
报错先沿这条路径查
打开 Settings → Usage
├─ 周期用量已满
│ └─ 记录重置时间;再比较等待、升级和 Credits
├─ 周期用量未满,但上下文窗口已满
│ └─ 按当前会话的容量问题处理,不要先改套餐
└─ 周期用量未满,请求仍然失败
├─ 保存完整报错、时间和模型
├─ 核对账户、工作区、入口与权限
├─ 对照当前官方帮助和服务状态信息
└─ 仍无法解释时联系官方支持
用量面板已达到上限,可以按周期额度已经耗尽处理,查看重置时间、升级套餐或增购 Credits。 面板仍有余额时,则不能直接归因于共享额度。现有资料没有提供请求级限流的错误码、触发阈值和重试参数,所以这里不编造错误码对照表,也不承诺一个通用的等待秒数。
额度耗尽后怎么选
| 处理方式 | 更适合的情况 | 需要核对 |
|---|---|---|
| 等待自动重置 | 当前任务可以暂停,不急于继续 | 距离重置还有多久 |
| 升级订阅 | 长期、高频使用 Agentic 或 Codex | 官方实时价格、额度表和工作区计费方式 |
| 购买 Credits | 需要在重置前继续使用符合条件的功能 | 增购余额、使用范围和有效期 |
这三种方式不是固定优先级。短暂任务可以等重置;持续高负载再比较升级是否划算;重置前必须继续运行时,再确认 Credits 是否适用。现有资料不能保证升级后一定更耐用,具体结论应在官方实时价格和额度表更新后计算。
如果只是快速问答,且当前账户提供 Instant,可以优先使用这个不占用共享额度的入口;是否可用仍以账户界面为准。
下一步先留证
准备联系官方支持前,先保存完整报错原文、发生时间与时区、账户及工作区、模型、使用的入口和任务规模,再截取 Settings → Usage 的剩余量与重置时间,发送前做好脱敏。
先确认共享池是否真的见底,再决定等待重置、升级套餐还是购买 Credits。用量页仍有余额时,继续核对完整报错、权限和服务状态,不要把所有失败都归为“共用额度”。













暂无评论内容