先说结论：目前公开的官方资料没有给出一个适用于所有账户的 Plus、Pro 5x 或 Pro 20x“每周固定 Token 数”。Codex 套餐内用量更像由多个计量层共同决定：本地消息和云端任务共享五小时窗口，此外还可能有每周限额；任务所用模型、上下文和复杂度也会改变消耗。
因此，判断套餐够不够用，最可靠的方法不是拿论坛里的 Token 数套在自己账户上，而是：
- 在 Codex 用量面板查看当前剩余量和页面显示的重置时间；
- 在活跃的 Codex CLI 会话中输入
/status； - 记录真实工作中何时被限额打断，再决定是否从 Plus 升到 Pro。
先分清四种“额度”
很多困惑都来自把四套不同机制叫成了“Token 限制”。它们的用途和查看方式并不相同。
| 你看到的概念 | 它实际表示什么 | 应该去哪里确认 |
|---|---|---|
| 套餐内用量 | Plus 或 Pro 订阅包含的 Codex 使用能力 | Codex usage dashboard 或 CLI 的 /status |
| 五小时窗口与每周限额 | 本地消息和云端任务共享五小时窗口，且可能另有每周限制 | 以账户页面显示的剩余量与重置提示为准 |
| 购买额度（credits） | 符合条件的账户先消耗套餐内用量，用完后可用购买的额度继续使用受支持功能 | 账户中的额度余额、购买入口与适用功能说明 |
| API 用量 | 使用 API key 发起请求时，按 API 的用量规则单独计费 | API 用量与账单页面 |
最容易犯的错误，是把购买额度或 API 费率表里的 Token 单价，反推成 Plus、Pro 的套餐内周 Token 配额。官方的 Codex 费率说明 可以解释额度制活动如何按输入、缓存输入和输出 Token 计量，但它不能证明订阅套餐内包含多少固定 Token。
为什么不能给出一个准确的“每周 Token 数”
Codex 的消耗不只取决于你输入了多少字。根据官方定价说明，模型、任务规模和复杂度、本地或云端执行、上下文长度、推理、工具调用、检索以及缓存情况，都可能改变一次任务的实际消耗。
例如，下面两个提示词看起来长度相近，成本却可能完全不同：
- 在一个小仓库里修改一处文案，并运行单个测试；
- 在大型代码库里定位跨模块故障、检索大量文件、调用工具并反复验证。
后者需要读取更多上下文、执行更多步骤，也更可能占用较多额度。于是，“每天发多少条消息”或“每周写多少行代码”都不是稳定的换算单位。
还有一个现实问题：同一天可见的官方定价页面曾出现过不同的逐模型消息区间。它们共同确认了 Plus 与 Pro 的相对容量、共享五小时窗口和可能存在的额外周限制，却不足以支持一张长期有效的精确消息数表。做容量规划时，账户自己的用量面板比静态数字更有操作价值。
Plus、Pro 5x 和 Pro 20x 有什么差别
当前官方公开的 USD 标价与相对容量如下：
| 套餐 | 公开标价 | Codex 相对用量 | 更适合的使用状态 |
|---|---|---|---|
| Plus | USD 20/月 | 基准 | 偶尔或日常使用，限额很少打断关键工作 |
| Pro 5x | USD 100/月 | Plus 的 5 倍 | 多天频繁使用，Plus 的中断已经影响交付 |
| Pro 20x | USD 200/月 | Plus 的 20 倍 | 长时间、高强度并行工作，且 5x 容量仍明显不足 |
这些是公开 USD 标价和相对容量，不等于中国大陆账户的实际结账价格。税费、支付方式、购买资格、额度功能以及两个 Pro 档位是否都可选，都可能因地区和账户而异；升级前应以登录后的结账页为准。
什么时候继续用 Plus
如果你只是偶尔让 Codex 修改代码、解释项目或完成短任务，而且很少在关键时段碰到限制，Plus 通常已经能完成任务。一次异常庞大的仓库分析耗尽窗口，并不足以说明你长期需要 Pro。
先尝试减少无效消耗：给任务划定目录和完成条件、避免在同一会话反复塞入无关上下文，并根据任务难度选择合适模型。这里的目的不是追求“少用 Token”本身，而是减少不必要的检索和返工。
什么时候考虑 Pro 5x
如果以下情况在有代表性的工作日反复出现，Pro 5x 才开始有明确价值：
- Plus 的剩余量经常在工作尚未完成时见底；
- 中断发生在测试、调试或交付的关键链路上；
- 你已经控制上下文和任务范围，限制仍持续影响工作；
- 为延续 Codex 使用而购买额度，已经成为稳定而非偶发的支出。
Pro 5x 的意义是购买更大的套餐内容量，不是承诺某个固定任务数，也不能保证永远不会遇到窗口或周限制。
什么时候才需要 Pro 20x
Pro 20x 面向的不是“偶尔想要更快”的情况，而是可观察的持续高负载：你每天进行较长的代理式开发任务、多个项目都依赖 Codex，或者 5x 档位仍会规律性中断有价值的工作。
如果没有自己的 5x 使用记录，直接选择 20x 往往缺少决策依据。更稳妥的路径是先用账户数据验证容量缺口，再判断中断成本是否足以覆盖更高月费。
用一份简单记录做套餐决策
连续观察一个完整、具有代表性的工作周期。不要只记录“今天用了很多”，而要记录下面四项：
| 记录项 | 示例 |
|---|---|
| 任务类型 | 小修复、跨仓库重构、长时间调试、云端任务 |
| 使用条件 | 模型、上下文规模、本地或云端、是否大量调用工具 |
| 限制表现 | 何时触及窗口或其他限制，页面显示何时重置 |
| 业务影响 | 等待是否阻塞交付，能否改用手动流程，损失了多少有效时间 |
然后按以下顺序判断：
- 几乎没有实质中断：继续 Plus。
- 偶发中断，但可以改期：继续 Plus；如果账户符合条件，可比较偶发购买额度与长期升级的成本。
- 中断反复影响付费工作：考虑 Pro 5x。
- 已有 5x 的真实记录，仍持续受限：再评估 Pro 20x。
这套判断比“某套餐每周有多少 Token”更可靠，因为它把变量换成了可观察结果：你的任务是否完成、限制何时出现，以及中断到底值多少钱。
如何查看剩余用量和重置时间
你可以从两个入口核对：
- 打开 Codex 的 usage dashboard，查看账户当前显示的剩余限额；
- 在正在运行的 Codex CLI 会话里输入
/status。
账户界面可能显示相关重置时间，但公开资料没有确认所有 Plus、Pro 5x 和 Pro 20x 账户都遵循同一个普通周重置时刻。不要根据他人截图推算自己的周期；以你账户当前显示的计数器和时间标签为准。
如果 dashboard、CLI 与定价页的文案看起来不一致，先确认登录的是同一账户与套餐，再记录客户端、模型和显示时间。公开页面可能存在更新延迟或分阶段变化，而只有账户表面能反映你当下实际可用的限制。
购买额度能否代替升级 Pro
对符合条件的 Plus 和 Pro 账户，系统会先消耗套餐内用量；到达包含限额后，购买的额度可以继续支持 Codex 等适用功能。这使“维持 Plus + 偶尔买额度”成为一种可能，但并非所有地区和账户都有同样的购买入口、自动充值选项或价格。
可以用频率来判断：
- 额度支出只是偶发，且中断不影响关键任务，保留 Plus 可能更灵活；
- 几乎每个工作周期都要补充额度，应把实际额度支出与 Pro 月费一起比较；
- 即使提高套餐仍可能遇到限制，不要把 Pro 当成无限使用方案。
订阅内用量、购买额度和 API 账单应分别核算。尤其不要因为 ChatGPT 订阅升级，就假设 API key 的调用也包含在套餐内。
常见问题
Codex Plus 每周到底有多少 Token？
当前公开官方页面没有确认一个对所有 Plus 账户都适用的固定周 Token 数。套餐内消耗还受到模型、上下文、任务复杂度和工具使用等因素影响。请查看 usage dashboard 或在 CLI 输入 /status 获取账户当前状态。
Pro 5x 是否代表每周 Token 恰好是 Plus 的五倍？
官方把它描述为相对 Plus 的 5 倍 Codex 用量档位，但没有提供可安全换算成统一固定周 Token 数的公开公式。用“相对容量更大”理解比自行计算一个精确 Token 桶更稳妥。
Pro 20x 是无限使用吗？
不是。它代表相对 Plus 更高的容量档位，仍不应理解为无限用量；五小时窗口及可能的额外周限制仍需要考虑。
每周限额在周一重置吗？
公开资料没有确认适用于所有账户的统一普通周重置锚点。账户界面可能显示相关重置时间，应以登录后看到的实际标签为准。
Codex API 用量包含在 Plus 或 Pro 里吗？
不要把两者混为一谈。通过 API key 使用 Codex 属于单独的按量计费路径，应在 API 用量和账单页面核对；ChatGPT 套餐内用量则在 Codex 的账户用量入口查看。
最后怎么选
先不要从传闻中的周 Token 数出发。打开 usage dashboard 或运行 /status，确认真正限制你的究竟是五小时窗口、可能的周限额，还是套餐用完后的额度余额。
如果 Plus 很少阻塞真实工作，就继续用；如果中断在多个代表性工作日反复影响交付，再考虑 Pro 5x；只有已有数据表明 5x 仍长期不足时，Pro 20x 才有清晰依据。套餐选择的核心不是追求最大的数字，而是用最低的稳定成本，让重要任务不中断。
进一步核对可参考 Codex 官方定价、ChatGPT 套餐中的 Codex 用法 与 ChatGPT 灵活额度说明。
