如果你这两天在用 Codex，大概率经历过这样一个瞬间：早上打开，额度 100%；中午写了几个函数，弹窗提示 5 小时窗口已耗尽；晚上额度重置，第二天再打开，显示本周剩余 0%。不是你没在用，是你用的东西变了——你付的是聊天时代的月费，调用的却是会自己读文件、改代码、跑测试、失败重试、并行开子代理的云端软件工程机器人。这篇文章想聊的不是「OpenAI 又克扣额度了」，而是这一轮额度塌方背后，到底是谁在替谁付账，以及接下来一年这件事会怎么收场。

01先看结论：不是玄学，是一次同时踩下三条刹车的容量事故

把过去十天的公开事件按时间排一下，脉络其实非常清楚：

日期	发生了什么
9 月 3 日	GPT-6 Astra 发布，分批上线。当天大量付费用户拿不到模型，Sam Altman 形容这次上线「一团糟」。官方承诺：每延迟一天，补一次额度重置
9 月 5 日	Astra 提前完成全量推送，OpenAI 给所有 Plus / Pro / Business 用户发了一次全量可存储重置
9 月 6 日	Tibo 宣布长尾场景用量优化，最多省 3–4 倍；同时给出关键建议：Astra 的 Low 档已强于上一代 Sol 的 High 档
9 月 7 日	官方再做一次全局重置，理由是「大家拿 Astra 疯狂做 Blender 建模把额度烧光了」。约 48 小时后，重度用户的额度被砍最多 4 倍
9 月 9 日	Tibo 公开预警：Astra 需求「前所未有」，可能被迫暂停新 Pro 订阅
9 月 10 日	正式官宣：暂停 200 美元 Pro 档（20x）的新订阅与升级。现有用户照常续费，但一旦取消或降级，暂停解除前买不回来
9 月 11 日	宣布 GPT-5.3-Codex-Spark 下线，理由是「用量已下滑，我们现在有显著更好的模型」

十天里，砍额度、发补偿、再砍额度、关门限售、砍模型，五连击。这不像一次产品迭代的节奏，更像一个机房在满载告警下的应急操作序列。

值得注意的一个细节：官方从未公布过周额度的具体数字，定价页上只写「可能另有每周限制」。这意味着所有关于「额度被砍了 30%」的结论，都只能来自用户自己解密本地日志反推——而反推和真相之间，隔着一层官方永远可以否认的口径差。

02网上到底有多少人在喊：社区证据盘点

这不是零星的抱怨。截至 9 月上旬，可以交叉验证的几个来源是这样的：

• OpenAI 官方社区：「Codex limits spark frustration among subscribers」一个帖子就有约 240 层回复；更早的「Codex Rate Limits Discussion Thread」累计 480+ 层。有用户统计，仅前 20 条回复里就有约 14 人明确说额度掉得比过去快。
• Reddit /r/Codex：8 月 16 日一条关于「额度被削减」的帖子拿到 1500+ 赞；8 月 20 日另一条描述「重置后几小时掉光」的帖子 213+ 赞。版主一度公开表示，在问题解决前会继续放行独立吐槽帖。
• 第三方追踪器：一个叫 TiboTattle 的独立额度追踪项目出现，据称有 500+ Codex 用户贡献用量数据。
• 中文社区：X、知乎、CSDN 上「Astra 额度粉碎机」的实测帖密集出现，有人干脆写了自己的路由脚本，把简单任务自动甩给便宜模型。

最有说服力的一条不是情绪，而是数据。一位 Pro 5x 用户的做法值得抄：他不比较原始 token 数，而是从本地 rollout-*.jsonl 日志里重建历史周期，用官方费率卡对未缓存输入、缓存输入、输出三类分别归一化，再用 total_token_usage 的累计差值（而不是把 last_token_usage 快照累加）来避免重复计数。他得出的结论是：自 8 月初起，Pro x5（可能还有 x20）的周额度实际缩水约 30%–33%。

「我故意把大部分负载迁到了比 Sol 便宜 60% 的 Terra，额度反而掉得更快。这不是感觉，是我把自己几周的日志挖出来对完账之后的结论。」

另一位 $100 档用户的描述几乎是本轮症状的标准样本：Astra 掉得太快，于是切到 Spark；结果 Spark 也在几乎没有使用的情况下耗尽——「昨天重置到 100%，今天又全没了」。这类「重置后瞬间蒸发」的报告在多平台反复出现，已经超出「额度不够用」的范畴，指向记账或调度层面的异常。

需要泼一盆冷水：这些证据的成色并不整齐。TiboTattle 的贡献者不等于投诉者；本地日志反推依赖用户自己对费率卡和归一化函数的理解，任何一处假设错位都会得出偏差。但「大量用户在不同平台、用不同方法、得出方向一致的结论」这件事本身，就足以要求官方给出一个可核验的解释——而到目前为止，官方只给了一句「没有变化」。

03为什么烧得这么快：四个工程层的原因

把情绪剥掉之后，额度塌方其实有相当清晰的工程解释。它不是一个原因，是四层叠在一起。

推理档位、缓存命中、并行子代理、Fast 加速——四层开销叠加，账单在同一秒内被放大

第一层，推理档位的隐性杠杆。这是最容易被忽略、也最容易自救的一层。Tibo 本人给过一条非常直接的校准建议：GPT-6 Astra 在 Low 档的表现已经优于 GPT-5.6 Sol 的 High 档，习惯把 Sol 开到 High 的人，用 Astra 时应该降到 Low 或 Medium。但大量用户的肌肉记忆还停留在上一代——「重要任务就把档位拉满」。在 Astra 上，这不是保险，这是烧钱：档位每上一级，模型在后台的隐式推演、自我博弈和多轮验证呈几何级增长。有开发者实测同一个复杂实现任务：Medium 档 80 次请求、1110 万 token、51 分钟完成；切到 High，耗时涨到 77 分钟，烧掉巨量算力，最后反而漏掉一个基础启动缺陷。这就是为什么会有人遇到「还剩 12% 额度，给 Astra Max 派了个简单任务，30 秒后清零」——在他眼里是发了一条消息，在计费系统眼里是一次小型核爆。

第二层，长上下文里的缓存命中率。Agent 模式和聊天模式的根本差别在于上下文长度：聊天几轮，上下文几千 token；跑一个多步重构，上下文轻松到几十万。而只要中间有任何一处扰动——换推理档位、改系统提示、插入新文件——缓存的 prompt 前缀就失效，下一轮要按普通输入重新计费。有用户实测，切换推理档位后缓存命中率从 98.5% 掉到 65%，重建之后才回到 97% 以上。这正好解释了 9 月初那次 configuration_update 更新的意义：它允许在同一段长对话里随时调高或调低 reasoning effort，而不再打断已缓存的前缀。对一个跑几十轮的 agent 任务来说，这个改动等于直接把毛利率还给了用户。

第三层，并行子代理的乘数效应。这是 2026 年才成为主要变量的东西。Astra 允许一次拉起多个子代理分头干活，社区里有人把 max_concurrent_threads_per_session 从默认 3 提到 64。听上去很爽，但每一个新开的子代理都是一条独立的上下文，而它的缓存基本是冷的——有开发者把 Ultra 档的激增消耗直接归因于「每 spawn 一个子代理就 miss 一次缓存」。实验数据也很冷：一次 19 分钟、64 个子代理的并行任务，吃掉了 Pro 5x 周额度的 5%。

第四层，Fast / Ultra 模式的价格标签。Fast 模式在 Astra 上是标准费率的 2.5 倍（API 侧「最高 2 倍速度、2 倍价格」），而且 Codex 界面早期的「1.5x」文案本身就是错的，后来才改成「2x speed, increased usage」。Ultra 档同样带乘数。很多人开启它只是因为「Astra 就该配最快的档」，却从没算过这笔账——你买的是延迟，付的是配额。

还有一个被低估的结构性因素：Codex 和 ChatGPT Work 共用同一个 agent 用量池。你在后端跑一个长任务的同时，在前端问了几句「刚才那个任务怎么样了」，两边在同一个池子里扣账。重负载到来时，两侧互相挤占。

04官方的口径为什么这么难堪：议价权在谁手里

这一轮最有意思的地方，是官方回应的姿态。概括下来是三步：先否认，再给折扣，最后关闸。

第一步，否认。面对「额度被偷偷砍了」的指控，Tibo 的回应是「重置前后没有差别」；面对「Astra 上线后变笨了」的对比视频（同一提示词生成的 3D 模型从有弹链有支架退化成几块灰方块，视频近百万播放），先由员工在评论区说「我们没做任何改动，但正在调查」，55 分钟后 Tibo 亲自补一句「自 Astra 上市以来，我们没有做出任何改变」。

第二步，给折扣但不改规则。9 月 6 日那条「长尾最多省 3–4 倍」的公告，读原文会发现措辞极其严密，四道边界都在：限定在「long tail」（十几轮工具调用、代码反复报错重试的极端长任务）、限定在「power users」、限定在「用 ChatGPT 账号登录」的订阅侧（API 价格不动）、上限是「up to」。它没有上调任何一档的额度上限，只是把后端的上下文缓存和冗余压缩做得更好了。结果是同一份公告，重度用户感觉「确实能多跑几轮」，而大量普通用户的第一反应是「谢谢，但我额度已经是 0% 了」——因为对短对话，这个优化根本感知不到。

第三步，直接关闸。9 月 10 日暂停 200 美元档新订阅，是这轮里唯一不需要解释的举措。Tibo 的原话是这类订阅「对我们系统的压力最大」，暂停是「最小的那一步」，好让我们「继续提供尽可能广泛的访问」。翻译一下：平台算的是收入增长和服务容量是两回事——收进来多少订阅费，和随后必须交付多少推理算力，不是同一个指标。而 200 美元档的特殊之处在于它的额度标称是 Plus 的 20 倍，价格却只是 Plus 的 10 倍。用得越多越划算，用户算得越清楚，OpenAI 承担的推理成本就越高。

关掉最贵的入口，让新增算力优先给存量用户——这是容量约束下最简单的取舍

这里有一层多数评论没点破的东西：官方的公关劣势不是措辞问题，是举证责任倒挂。周额度的具体数字从未公开，用户无法核验自己是否落在「长尾」范围内，也无法验证「重置卡是否真的等于一份周额度」——有用户对比重置前后各消耗 14% 周额度的记录，发现重置后需要约 6360 万 token 而重置前需要 1.14 亿，据此估算重置卡只给了一半额度，Tibo 直接否认。当官方握着唯一的账本，任何「我们没变」的声明在用户端都是不可证伪的。这才是它看起来「难堪」的真正原因——不是傲慢，是信息结构决定的。

05Spark 下线：砍的不是模型，是一个使用姿势

9 月 11 日，Tibo 宣布 GPT-5.3-Codex-Spark 下线，理由很简短：用量在下滑，而且我们现在有显著更好的模型。计划把客户迁移到迭代更好的方案上。

这条消息如果孤立看，只是一次常规的产品淘汰。但放在 Astra 的时间线上，它说明的事情要多得多。Spark 是 2026 年 2 月上的东西，是 Codex 家族里唯一一个「为交互速度而生」的型号——峰值输出到过 1000 token/秒，成本低、启动快、纯文本、能力弱，专门用来做「改一行、看一眼、再改一行」的高频小迭代。它和 Astra 代表的是两种完全不同的工作方式：一个把时间切碎，一个把任务拉长。

Spark 的死因不是它不好，是它所服务的那个工作方式，正在被订阅经济淘汰。Spark 便宜、快、额度友好，用户在额度和速率的双重挤压下会自然往它迁移——而迁移的方向，恰恰是平台最不想看到的方向：单位时间内的会话次数多、每次任务轻、但订阅费一分不涨。于是出现了一个尴尬的局面：社区那句总结说得很直接，Spark 的额度会在主额度耗尽后仍然「基本满格」，所以聪明人学会了「主池烧完就去刷 Spark 池」。一个能被用户系统性套利的产品线，在容量紧张的时期必然被优先关掉。

所以「替代品」这个问法本身可能就问错了。如果预期是「会有另一个 Spark」，那大概率会失望——官方给的方向是「迁移到显著更好的模型」，也就是往 Astra / Sol / Terra / Luna 这条线上并。真正要留意的是另一个信号：Astra 引入的跨上下文窗口笔记机制。它让模型在上下文填满时不再只靠一次性的 compaction 摘要，而是保留笔记并让早期窗口保持可检索。官方说这个功能会「在未来几周成为 Astra 的默认」。这句话的含义是，长任务里那些「为什么上次修复失败」的细节终于不会被每次压缩抹掉——这是为长跑 agent 修的基建，而不是为秒回修的。

06用量池分裂成两层：Agent 时代的账单长什么样

把这一轮所有碎片拼起来，指向的是同一件事：订阅制的计价基础，和 Agent 的成本结构，已经不匹配了。

聊天时代，月费买的是「对话次数」，成本可控、可预测，一个用户一天问二十个问题，背后的推理负载是有界的。Agent 时代，月费买的是一个可以自主读文件、改代码、跑测试、失败重试、并行的执行体，同样的一个月费，成本方差可以差出两个数量级。而你无法通过「更严格地限制提问次数」来解决这个问题，因为伤害最大的恰恰是那些「一条消息触发几十轮工具调用」的深度用户——限制次数挡不住他们，只能挡住只想改个错别字的人。

档位	价格（月）	标称额度	Astra 5 小时窗口（官方估算）
Plus	$20	1x（基准）	约 5–45 条
Pro 5x	$100	Plus 的 5 倍	约 25–225 条
Pro 20x	$200	Plus 的 20 倍	约 100–900 条

注意最后一列和上一代的对比：同样是 5 小时窗口，Sol 大约能发 10–100 条，Astra 只有 5–45 条。官方自己的估算表，已经把「一条重任务打掉五分之一窗口」写进说明书了。所以社区里那两个极端体感都成立——有人 200 美元档开两个 Ultra 会话挂多个子代理跑 45 分钟只掉 9%；也有人 20 美元档在 Astra Light 档下单任务就触顶。区别不在谁更会用，在谁付得起。

有科技评论员把 Plus 用户跑 Astra 的体验比作「回到 1999 年的拨号上网」——每敲一次回车都在心里盘算剩余额度，生怕下一秒被断网。这个比喻不算夸张。

07接下来会怎么走：三种可能和一张行动清单

基于公开信号，我认为接下来一年有三种可能，概率从高到低：

1. 分层固化（最可能）。20 美元档继续作为「体验券」存在，保证大众能摸到最新模型，但用量被严格限制；真正把 Agent 当全职生产力用的团队，被推向 100/200 美元档甚至按量付费的 API。这轮暂停 200 美元档只是暂时的——容量补齐后会重开，但重开时价格和额度「不承诺沿用原来的」。
2. 计价单位换轨。从「消息条数」转向某种算力或积分口径，让成本与交付更贴近。官方已经出现「积分」这个中间层（费率卡上是积分，重置卡和额外购买也是），这是换轨的前兆。风险是用户更难理解和预算。
3. 效率优化托住体验。就像 9 月 6 日那次长尾优化和 configuration_update，靠缓存、压缩、调度层面的工程把同样的硬件榨出更多有效产出。这是唯一不伤害任何一方的路径，也是唯一有上限的路径。

我的判断是这三条会同时发生，而不是三选一。真正需要观察的信号不是「200 美元档什么时候重开」，而是两件更可核验的事：一，官方是否开始公布周额度的具体数字或换算方式——这决定了用户能不能自己算账；二，长尾优化的「长尾」是否给出了明确的上下文长度阈值——有开发者已经提出，如果任务的中位上下文超过 10 万 token，Astra Medium 可能比 Sol xhigh 还贵，而官方从未界定这条线在哪。这两个问题不回答，「我们没变」就永远只是一句话。

最后是给普通用户的行动清单，按见效速度排：

• 立刻降档。把 Astra 的默认 reasoning effort 调到 Low 或 Medium。这是投入产出比最高的一步，官方自己背书「Astra 低档强于 Sol 高档」。
• 模型分工，别一锅端。日常 80% 的粗活（格式整理、初筛、长文摘要、机械重构）交给 Terra / Luna / Sol；把 Astra 严格留作攻坚——架构设计、复杂 Debug、多步 agent 交付。
• Fast 不是默认，是采购。只有当「等待时间确实是瓶颈」（边看 UI 边改、会上临时调试）时才开，它按 2.5 倍费率记账。
• 一个任务一个会话。既然官方优化了长尾计费，就让上下文完整、目标结构化地待在同一个会话里，让缓存机制为你省钱，而不是碎片化地反复开新会话重建缓存。
• 自己记账。Codex 本地 rollout-*.jsonl 保存了完整的请求轨迹。怀疑账单异常时，导出模型、档位、时间戳和用量读数，这既是自证也是维权材料——预判「额度有问题」但拿不出证据，是这一轮所有抱怨里最吃亏的部分。

08其他动态

• GPT-6 Astra 在 Codex 中成为默认模型，但默认推理档位是 Light——不手动调高就不会深度思考，这是很多「新模型反而变糙」误会的来源。Codex CLI 需 0.153.0+ 才能访问。
• Astra 加入跨上下文窗口笔记机制：不再只靠一次性 compaction 摘要，保留笔记并让早期窗口可检索，官方称未来几周成为默认。
• Responses API 新增 configuration_update：同一段长对话内可随时调整 reasoning effort 而不破坏已缓存前缀，长跑 agent 的缓存复用率显著改善。
• Codex 与 ChatGPT Work 共用 agent 用量池，重负载会同时挤占两侧，规划任务时需一并考虑。
• 官方发放的是「可存储重置卡」，不是积分：一次性用量重置、有有效期、不永久提高套餐上限；即时购买的重置则会立刻拉起 5 小时与周窗口并重算 7 天。
• 推理档位新增 xhigh / max 两档，仅在 Responses API 侧可用；reasoning_effort = "none" 不被支持，会在 API 层被拒。

微信公众号

欢迎关注「字与码」

如果这篇文章对你有用，也欢迎在微信里继续关注后续更新。

X

X / Twitter

关注 @ax2_zicode

更即时的技术观察、新文章提醒和一些短想法会发在 X 上。