标签页合一、额度合一：ChatGPT 与 Codex 从 12 月起共用一个用量池

先说结论：界面是小事，账单是大事

2026 年 11 月 2 日，OpenAI 给用户发了一封邮件，里面装着两件事：一件是界面上的——ChatGPT 桌面应用里的 Chat 和 Work 两个标签页要合并成一个体验；另一件是账单上的——从 12 月起，ChatGPT 和 Codex 将共用同一个用量额度。TechCrunch 当天率先报道了这封邮件，OpenAI 自己的帮助中心页面也已经写明了 12 月共享额度的规则。两件事里，前者只是少点一次鼠标，后者却可能改变你每个月用量见底的那一天。

先把最容易误解的一点钉死：Codex 不会被合并。邮件原文写得很清楚：“Codex will remain a separate experience in the ChatGPT desktop app.”也就是说，合并的只是 ChatGPT 这一侧内部的 Chat 与 Work 两个标签，写代码的 Codex 仍然是桌面应用里独立的一块，工作流和历史记录都不变。把“合并”理解成“三个功能合成一个”的人，会误判这次改动的范围。

再把时间线钉死。合并体验没有确定的全面上线日期：先给一小批用户试用、收集反馈，之后再广泛推送。共享额度则有明确月份：12 月起，Plus、Pro 和 Business 套餐的 ChatGPT 与 Codex 用量将按 token 计入同一个额度池。界面合并是“快了”，额度合并是“12 月”，两者不要混成同一个时间表。

今天的桌面应用为什么让人晕

要理解这次合并，先看清今天的结构。按 OpenAI 帮助中心的描述，新版 ChatGPT 桌面应用里其实有三块：Chat 负责问答、搜索和对话；Work 负责研究、分析并产出文档、表格、演示文稿、报告和网站；Codex 负责对本地文件、仓库和终端做软件开发。在 ChatGPT 这一侧内部，你还要在 Chat 和 Work 之间拨动一个开关。TechCrunch 的评价很直接：这么多分区，让人经常忘了自己正在哪里工作、项目到底存在哪一边。

这种结构是功能扩张留下的痕迹。聊天、智能体式工作、编程，原本是三条不同的产品线，各自长出了自己的入口和计量方式。当它们被塞进同一个桌面应用时，用户要先做一道分类题——“我这个问题算对话还是算任务？”——然后才能开始工作。OpenAI 这次合并的逻辑，就是把这道分类题从用户手里拿走：你不用先想好这是一个问题还是一个任务，直接开口，从探索想法到让 ChatGPT 把活干完，都在同一个地方完成，中间可以带文件、带插件，让它建网站、做演示文稿、替你在网上操作，而你在一旁审阅和引导。

Anthropic 在 9 月已经走过类似的一步，把 Claude 的对话和 Cowork 合并到同一屏。两家厂商的方向是一致的：回答与动手之间的分界线，正在从导航栏里消失，交由模型自己判断。但这并不意味着两家的做法没有区别：Anthropic 的合并发生在对话与通用智能体之间，而 OpenAI 这次特意把写代码的 Codex 留在了合并范围之外——因为 Codex 面对的是本地文件、仓库权限和沙箱，这些边界不适合被聊天窗口的随性默认值稀释。

真正值得算账的：一个额度池意味着什么

界面合并省的是点击次数，额度合并改的是消费结构。过去，ChatGPT 的对话用量和 Codex 的编程用量是分开计的；12 月起，它们从同一个 token 额度池里扣。OpenAI 帮助中心写明的规则有四条：第一，适用范围是 Plus、Pro 和 Business 套餐；第二，用量按 token 计，模型越强、任务越复杂，扣得越快；第三，即时聊天（Instant chat）不计入额度；第四，合并后的剩余额度和重置时间可以在“设置 → 用量”里一次看清。用完之后的选择也写明了三条：等重置、升级套餐，或者购买额度继续使用符合条件的部分功能。

OpenAI 在邮件里的表态是，大多数用户不会受影响，但“根据用量和模型，有些人可能需要更频繁地等待重置”。这句话要拆开读。“大多数用户”指的是轻度使用者：短对话、偶尔让 Work 生成一份文档、偶尔用 Codex 改几行代码的人，一个池子够用。但对重度使用者，合并意味着此消彼长：一个漫长的 Codex 编程会话可能吃掉当天聊天的余量；反过来，一下午密集的 Work 任务也可能让晚上的编程提前见底。以前两个池子互不干扰，现在它们互相抢水。

还有一层背景让这次合并显得更敏感：就在 10 月 29 日，OpenAI 刚刚把 Pro 100、Pro 200 和 Pro 500 三档的 Work 与 Codex 额度翻倍，并取消了原定的 Pro 200 削减（本站 10 月 30 日轮次已报道过那次反转）。也就是说，用户是带着刚刚变大的额度进入 12 月的共享池的。这既是好消息也是提醒：池子变大了，但池子也变成了一个。评估 12 月的影响时，不能只看“额度翻倍了”，还要看“你的聊天用量和编程用量加起来是多少”。

目前仍有几个关键数字没有公布：每个套餐的共享额度到底是多少 token、不同模型各自的消耗速率是多少、12 月内的具体切换日期是哪一天、Free 和 Go 套餐以及企业套餐如何处理、网页端和移动端会不会跟进同样的合并。OpenAI 没有公布这些数字，任何声称“某套餐够用/不够用”的结论现在都还缺乏依据。诚实的做法是：把 12 月当作一个需要实测的月份，而不是一个已经可以下结论的月份。

三类用户，12 月前各做一件事

第一类：聊天为主、偶尔编程的人。你大概率就是 OpenAI 所说的“大多数用户”。12 月前唯一要做的事，是去“设置 → 用量”里看一眼你现在的用量结构：聊天和 Codex 各占多少。只要两者之和离上限还远，合并对你就是一次纯粹的界面简化，不用专门做什么。

第二类：每天重度使用 Codex 的开发者。你是受影响最大的群体。建议在 12 月切换前做一次用量审计：连续记录一周，分别记下 ChatGPT 对话、Work 任务和 Codex 会话各自的消耗量级（即使现在没有精确的 token 数，任务次数和时长也能帮你估算相对比例）。如果 Codex 本来就占你用量的大头，12 月起要预留一个缓冲：把不重要的长任务拆小、把探索性提问留在即时聊天（不计额度）、把真正需要 Codex 的工作集中在额度刚重置的时段。另一个值得核实的选项是 API 计费：据同期报道，Codex 在环境中检测到 OpenAI API 密钥时可以切换为按用量 API 计费，而不消耗套餐额度——这条路径是否适合你，需要你自己在官方文档里核实，不要只凭转述就动手迁移。

第三类：给团队写内部指南的人。你们的文档里如果有“用 Chat 问问题、用 Work 做任务”这类按标签分工的写法，合并推送到你的账号后就要改写。更重要的是计费口径：团队成员以前可以分别解释“聊天额度”和“Codex 额度”，12 月起要改成“一共一个池子”。预算审批、成本分摊、用量预警的阈值，都要按合并后的口径重算一遍。等到有人 12 月中旬突然撞上限时再改文档，就晚了。

别被“合并”这个词带偏：三个常见误读

误读一：“ChatGPT 和 Codex 合并了，编程也要在聊天窗口里做了。”不对。邮件明确说了 Codex 保持独立体验，OpenAI 帮助中心也确认 Codex 的工作流和历史记录与 ChatGPT 分开。合并的是 Chat 与 Work，不是 Chat 与 Codex。

误读二：“合并后用量会翻倍。”不对。共享额度不是两个额度相加，而是一个池子两处扣。10 月 29 日的翻倍是另一回事，不要把它和 12 月的合并混成“额度又翻倍了”。

误读三：“所有人 12 月都会被强制切换。”不对。界面合并是先小范围试用再广泛推送，没有公布全面上线日期；额度共享写的是 12 月起，但具体切换日、不同套餐的覆盖细节仍未公布。把“12 月”理解成“12 月 1 日所有人同时切换”，就过度解读了。

判断：导航修好了，计量才刚开始收紧

把这次改动放在 2026 年 OpenAI 的产品线里看，它的模式其实很清晰：界面越来越简单，计量越来越统一。聊天、Work、Codex 曾经是三个入口、两套账；现在入口正在合拢，账本也正在合拢。对 OpenAI 来说，统一计量更容易解释、更容易运营；对用户来说，统一计量意味着过去靠“分开算”获得的缓冲消失了——你不能再指望聊天池的余量去补贴编程池的超支，因为它们已经是同一个池子。

这并不必然是坏事。一个池子配一个清晰的用量页面，比两个池子配两处模糊的计数器更容易管理。真正的问题从来不是“合不合并”，而是“合完之后，池子到底有多大、不同任务的消耗速率是多少”。OpenAI 目前还没有公布这两个数字。在它们公布之前，最好的姿势不是焦虑也不是无视，而是做一次自己的用量审计：知道你的聊天、Work、Codex 各自吃掉多少，再等 12 月的用量页面告诉你合并后的总数。界面合并的那一天，你可能根本不会注意到；用量见底的那一天，你一定会注意到。

用量页应该怎么看：三个数字就够了

12 月之后，“设置 → 用量”页面会成为付费用户最常打开的页面之一，但很多人第一次打开时会不知道看什么。其实只需要盯住三个数字。第一个是剩余额度：合并后的池子里还剩多少，这是你今天还能干多少活的上限。第二个是重置时间：额度什么时候回满，这决定了长任务应该安排在重置之前还是之后。第三个是消耗结构：最近一段时间里，聊天、Work 任务、Codex 会话各自吃掉了多少比例——这个数字现在还没有以 token 明细的形式公布，但用量页至少会给出合并后的总量变化趋势，连续看两周就能估出自己的消耗结构。

看用量页时有一个常见的错觉：以为“剩余额度还很多”就等于“可以随便开长任务”。长任务的消耗不是线性的：一个让模型反复试错、多次返工的任务，消耗可能是同类短任务的几倍甚至十几倍。更稳妥的做法是，长任务开始前先看一眼剩余额度，任务进行到一半时再看一眼——如果消耗速度超出预期，及时把任务拆小或者换用更轻量的模型，而不是等到额度见底才发现任务做到一半被迫中断。被迫中断的任务是最贵的：它既消耗了额度，又没有产出可用的结果。

团队管理员还应该多看一个维度：成员之间的用量分布。合并之后，个别成员的重度 Codex 使用可能会挤占整个团队的预算感知——虽然额度是按账号计的，但团队报销和预算审批是按整体算的。如果团队里有人长期在月底前一周就见底，问题可能不是额度太小，而是他的任务拆分方式需要调整，或者他的一部分探索性工作应该转移到不计额度的即时聊天里。把用量页当作团队工作方式的体检表，比把它当作账单更有价值。

给团队的迁移清单：12 月前四周这样做

第一周：盘点。列出团队里所有在用 ChatGPT 桌面应用和 Codex 的账号，记录每个账号的套餐类型；同时收集现有内部文档里所有提到“聊天额度”“Codex 额度”“Chat 标签”“Work 标签”的段落，标出 12 月后需要改写的位置。盘点阶段不要做任何改动，先把现状写清楚。

第二周：实测。让每个重度用户连续记录一周的用量结构：每天大概开了多少次对话、跑了几次 Work 任务、跑了几次 Codex 会话，每次的任务规模如何。记录不需要精确到 token，次数和时长就足够估算相对比例。这一周的数据是 12 月后判断“合并有没有让我更快见底”的唯一基线——没有基线，12 月的任何感受都是主观的。

第三周：改写。按合并后的口径重写内部指南：删掉按标签分工的写法，改成按任务目标分工；把“两个额度”改成“一个池子”；把用量预警的阈值从分开的两条线改成合并后的一条线，并写明触发预警后该怎么做（等重置、升级、买额度三选一）。同时把 Codex 的 API 计费选项作为附录写进去，但标注“需自行核实官方文档”，不要把它写成已确认的推荐方案。

第四周：演练。选一个非关键任务，在额度较低的时段模拟一次“见底”：让团队实际走一遍用量页查看、任务拆分、模型降级的操作，确认每个人都知道额度见底时该停什么、该保什么。演练的目的不是制造焦虑，而是让 12 月真正见底的那一天，团队的第一反应是执行预案，而不是互相询问“这是什么情况”。预案的价值永远体现在第一次真实触发之前。

还有一个问题：网页端和移动端会不会跟进

这次合并目前只说清了桌面应用，网页端和移动端会不会跟进，OpenAI 没有公布。按帮助中心的现有描述，Codex 在网页和移动端本来就不可选，桌面端的 Codex 对话只能通过移动应用的远程标签页查看——这个结构决定了合并很难简单平移到其他端。网页端没有 Work 标签的完整形态，移动端则更侧重轻量对话，把 Work 的重型任务能力搬过去需要重新设计交互，而不是简单复制一个合并后的界面。

对用户来说，这意味着未来一段时间里可能出现“桌面端一个样子、网页端另一个样子”的分裂期。同一账号在不同设备上看到不同的入口、不同的用量口径，是最容易产生困惑的场景。务实的做法是：以桌面端为准建立自己的使用习惯，在网页或移动端只做轻量操作，等 OpenAI 明确公布其他端的计划后再统一调整。不要为了追新而在每个端都重建一套工作流——入口会变，但你的任务和文件不会因为入口变化而消失，真正需要保护的是工作习惯的连续性，而不是界面的统一性。

（本文事实核查说明：合并体验与邮件引文以 TechCrunch 2026 年 11 月 2 日报道为准；12 月共享额度、适用套餐、token 计量、即时聊天不计入、设置用量页与用完后的三条出路，均以 OpenAI 帮助中心《Understanding ChatGPT and Codex usage limits》页面原文为准；各套餐具体额度数字、模型消耗速率与 12 月内具体切换日期，OpenAI 尚未公布，文中已明确标注为未知，未作推测性断言；与 10 月 29 日额度翻倍的关联以本站 10 月 30 日轮次报道为背景。）