2026 年 7 月 28 日 21:09（美国太平洋夏令时间），OpenAI Codex 负责人 Tibo Sottiaux 发布了 GPT-5.6 Sol 使用限额调查更新；换算为中国标准时间是 7 月 29 日 12:09。中文转述很容易把它压成一句“OpenAI 给 Sol 加了 18% 额度”，但原始声明其实包含三种性质完全不同的动作：
- 重置当前使用限额；
- 经过多项改进，典型 Sol 使用下，同一限额预计维持约 18% 更久；
- 恢复调查期间临时暂停的五小时计量窗口。
如果把它们混在一起，后面的所有判断都会错位。本文只做事件核查：OpenAI 重置了什么、18% 准确表示什么、为什么公开费率相同仍会更快耗尽限额，以及哪些结论目前还不能写。
一、先把三项产品动作分开
证据图 1：Tibo Sottiaux 的公开调查更新。截图保留重置、18% 与五小时窗口的原始上下文。
“重置当前限额”更接近一次性恢复当前窗口中的可用量。它没有自动改变套餐长期包含量。
“同一限额维持约 18% 更久”描述的是优化后的典型使用预期。它不是向每个账户永久充值 18%，也不是承诺每个任务都节省相同比例。
“恢复五小时窗口”说明调查期临时措施结束。它和限额重置、运行效率改善都不是同一件事。
因此，最准确的一句话不是“永久增加 18% 额度”，而是：
OpenAI 重置了当前限额，并预计优化后的典型 Sol 工作负载能让同一限额维持约 18% 更久；调查期间暂停的五小时窗口随后恢复。
二、18% 是“维持更久”，不是“Token 固定减少 18%”
假设优化前一份限额可维持 100 分钟，优化后约为 118 分钟。若再额外假设任务强度恒定，则单位时间消耗速率为：
100 ÷ 118 ≈ 84.75%也就是理想化条件下约下降 15.25%，而不是下降 18%。
这个换算只是帮助理解“时长增长”和“速率下降”的差别，不是 OpenAI 对个体用量的保证。Agent 任务并不匀速：大仓库、网络搜索、多工具、子代理、失败重试和更高 reasoning effort 都会改变执行树。
所以以下三种写法都不成立：
- “所有用户永久多 18% 额度”；
- “Sol 每个任务 Token 固定下降 18%”；
- “Sol 价格下降 18%”。
三、OpenAI 否认削减套餐用量，但这不否定用户体验
官方声明明确否认削减任何订阅计划原本包含的用量。与此同时，用户感到同一窗口更快耗尽，仍然可能是真实的。
两件事可以用一个简单关系同时解释：
可完成工作量
≈ 套餐包含资源
÷ 每个任务的实际资源消耗即使分子没变，只要复杂任务的模型轮次、上下文、工具调用、搜索或子代理活动增加，分母就会变大。用户看到的是“只完成了两个任务就触发限额”；平台看到的可能是“账户分配没有变，但完整执行树产生了更多计量活动”。
四、为什么 Sol 比预期更快消耗限额
OpenAI 给出的不是一个单点 Bug，而是一组相互叠加的 Agent 行为。这些行为有些来自能力提升，有些来自运行效率不足，必须分开判断。
1. Sol 更愿意长时间工作
传统聊天模型回答完成后就停止；编码 Agent 会继续读取仓库、运行命令、修改代码、补测试、检查失败并再次修复。Sol 的一部分能力提升，来自它更愿意持续执行，而不是过早交付不完整结果。
这会形成一个真实悖论：更高的任务完成率往往来自更多工作，更多工作又可能让同一订阅窗口更快耗尽。判断额外消耗是否值得，必须看边际质量：多两轮测试如果避免线上事故，成本有价值；十轮搜索如果只是重复确认，成本就是浪费。
2. 工具和子代理会放大完整执行树
界面上的一条用户消息，后台可能包含读取规则、搜索文件、运行测试、多个子代理、修改代码、再次测试和最终整合。每个分支都可能触发独立模型调用、上下文输入和输出。
子代理并行能够降低墙钟时间，却会提高总 Token。OpenAI 的多代理文档也明确提醒，增加子代理会增加 Token 使用。因此“响应更快”和“消耗更少”不是同一个指标。
3. 相同的 High 不等于相同计算量
Medium、High、Max 或 Ultra 更像模型行为倾向，不是跨模型统一的硬件刻度。官方说明指出，Sol 在相同 reasoning effort 下也可能比旧模型做更多工作；Sol High 可能处理比 GPT-5.5 High 更多的 Token。
所以迁移时不能把旧模型档位机械映射到新模型，必须重新测量任务完成率、执行轮次和单位成功成本。
4. Code Mode 既可能减少往返，也可能增加往返
程序化工具调用可以把循环、条件和并行控制放进代码沙箱，只把聚合结果交回模型；用于独立、可预测、有界的调用时，它可能减少模型往返。
但如果每个小调用都重新返回模型、长上下文被反复处理、批次过大导致截断补读，或者工具等待和网络搜索不断触发新判断，Code Mode 也会带来更多响应与缓存输入。它不是天然省钱或天然更贵，收益取决于任务形状和边界控制。
5. 网络搜索是天然的长尾放大器
研究任务不像仓库修改那样边界清晰。一次搜索会带来多个页面，每个页面又可能引出新关键词、冲突证据和补查需求。如果没有搜索预算、证据饱和条件和停止规则，执行会不断携带增长中的历史继续搜索。
搜索工具本身是否收费，与模型处理搜索结果是否产生 Token，是两件不同的事。
五、Rate Card 相同，只能排除公开单价上涨
证据图 2：截至 2026 年 7 月 31 日，OpenAI Codex Rate Card 中 GPT-5.6 Sol 与 GPT-5.5 的输入、缓存输入和输出费率相同。
当前公开费率为：
| 模型 | 输入 / 100 万 Token | 缓存输入 / 100 万 Token | 输出 / 100 万 Token |
|---|---|---|---|
| GPT-5.6 Sol | 125 Credits | 12.5 Credits | 750 Credits |
| GPT-5.5 | 125 Credits | 12.5 Credits | 750 Credits |
这能支持的结论只有一个：公开的单位 Token 费率没有因为从 GPT-5.5 换到 Sol 而上涨。
它不能推出“同一个任务一定产生相同总量”。完整任务消耗仍取决于输入、缓存输入、输出的组合，以及任务和额外 Agent 实际产生了多少 Token。
因此真正的关系是：
任务总消耗
= Token 费率
× 完整执行树产生的 Token 总量上一稿已经专门讨论过“Sol 多做的工作何时值得”以及模型路由。本稿不重复那套方法，只保留事件核查所必需的边界：相同 Rate Card 不能反证用户的高消耗体验。
六、最重要的承认不是 18%，而是长尾漏检
证据图 3：公开说明提到 Sol 更愿意长时间工作、调用更多工具和子代理，同名 reasoning effort 也可能做更多工作；发布前对平均值和中位数关注过多。
中位数用户觉得效率不错，与重度复杂任务快速触发限额，并不矛盾。
- P50 回答日常小任务是否稳定；
- P95 观察大仓库、长研究、多工具任务是否明显放大；
- P99 检查极端任务是否可能一次击穿窗口；
- 失败任务成本记录“没有交付时已经消耗多少”。
如果只看平均值或中位数，少量高消耗任务会被多数轻量任务稀释。对 Agent 产品来说，订阅容量和模型迁移都必须同时看分布尾部。
七、官方确认了什么，哪些仍未公开
官方目前确认：
- Sol 在部分场景消耗限额快于预期；
- 没有减少套餐原本包含的用量；
- Sol 更愿意长时间工作，并调用更多工具和子代理；
- 同名 reasoning effort 跨模型不一定对应相同工作量；
- Code Mode、工具等待和大量网络搜索会影响消耗；
- 发布前对平均值和中位数关注过多，遗漏了复杂任务长尾；
- 已推出多项改进，并给出典型使用约 18% 的预期。
官方尚未公开：
- 18% 改善分别来自模型、运行时、缓存、调度还是系统提示；
- 各计划、档位、任务类型的改善分布；
- 复杂任务 P95、P99 恢复到什么程度；
- 每个用户是否同时生效；
- 所有相关问题是否已经完全解决。
所以文章不能把“已部署多项改进”升级为“单一根因已定位且完全修好”。
八、真正应该验证的是“同一限额能完成多少合格任务”
对于用户和 Agent 团队，最有用的验证单位不是消息数，而是通过验收的完整任务。至少记录：
- 每个通过验收任务的 Credits；
- 模型轮次、工具和搜索次数；
- 子代理数量与失败重试；
- P50、P95、P99 单任务消耗；
- 人工返工时间与最终完成率。
如果典型任务更耐用，但 P99 仍频繁击穿窗口，说明改善是真实的，长尾问题也仍然存在。两者不冲突。
常见误解
误解 1：OpenAI 给所有人永久增加了 18% 额度
错误。官方说的是典型使用中，同一限额预计维持约 18% 更久。
误解 2：限额重置证明平台此前偷偷扣减额度
没有证据。官方否认削减计划包含量；限额重置可以是调查期间的一次性恢复措施。
误解 3：Rate Card 相同，任务消耗就不可能变化
错误。费率相同，完整执行树产生的 Token 总量仍可能不同。
误解 4：缓存输入费率低，所以大量缓存几乎不消耗 Credits
错误。低费率乘以巨大的缓存输入总量，仍会形成显著消耗。
误解 5：强制所有工具并行就能解决问题
错误。并行只适合相互独立、输出可控、没有写入冲突的调用；搜索、依赖链和关键写入通常需要串行判断。
FAQ
Q1：这次重置会永久改变五小时或周限额吗？
原帖只确认重置用量并恢复五小时窗口。具体账户的五小时和周限制应以 Codex 界面为准，不能由原帖推断所有周期永久改变。
Q2：18% 改善何时生效？
原帖称部分用户从发帖当天起应看到明显改善，并预计典型使用整体更耐用。具体部署可能分阶段，不同账户未必同时生效。
Q3：Sol High 应该与 GPT-5.5 High 一样省了吗？
不能这样推断。官方明确指出，同名推理档位跨模型不一定对应相同工作量。
Q4：为什么一个任务也可能快速耗尽限额？
一个用户任务可能包含多次模型调用、工具、搜索、测试与子代理。界面上的“一条消息”不等于计量上的“一次模型请求”。
Q5：所有长尾问题都已经完全修好吗？
没有公开证据能够证明。官方只说明已推出多项改进，并会继续优化 Code Mode 等效率问题。
结论
这次事件不是“OpenAI 永久增加 18% 额度”，也不能简化成“用户误会了”。
更准确的结论是：
OpenAI 没有承认削减套餐包含量，却承认 Sol 的复杂 Agent 行为让部分用户比预期更快耗尽限额；多项优化让典型使用预计维持约 18% 更久，但具体修复拆分和长尾改善分布仍未公开。
真正值得持续观察的，不是一次重置，而是 Agent 产品能否同时公开典型成本、长尾分布和完整任务的资源差异。