北京
Codex技术经理蒂博在社区发布了一条最新通知：所有付费用户的当周额度已经完成重置，但从明天开始，5小时滚动限额机制将重新生效。这一变动让不少刚刚松一口气的开发者再次绷紧神经——此前因GPT-5.6模型推出后额度消耗过快，Codex团队一度暂停了滚动限额，允许大家“敞开用”以收集数据、定位问题。
好消息是，经过这段特殊时间的调查与优化，团队已经部署了多项改进。蒂博透露，在Sol模型的典型使用场景下，当前的使用额度预计会比此前增加18%左右。也就是说，虽然5小时的窗口限制回来了，但单次窗口内你能跑的任务量，理论上会比之前多出近两成。
为什么GPT-5.6那么“费额度”？蒂博没有直接给答案，但从他列出的几条原因中能拼出全貌。Sol模型在处理任务时表现得更“激进”——它愿意花更长时间工作，也会自动发起更多工具调用，尤其是在协调多个子智能体、串联复杂流程时，模型会频繁拉取工具、等待反馈、再继续操作。这种设计让Sol处理复杂问题的能力明显增强，但代价是每轮响应消耗的令牌、缓存输入都远超团队预期。
同样的推理努力程度下，Sol也比前代模型更“卖力”。比如在Sol+High模式下，它消耗的用量明显高于GPT-5.5+High模式。加上程序化调用赋予的并行处理能力，Sol可以一边等待某个工具返回结果，一边启动另一项搜索，这进一步推高了单轮响应开销。结果就是开发者不仅等得久，额度也用得像流水一样快。
Codex团队承认，这些问题对不同用户的影响并不均衡。中位数用户的令牌效率其实相当高，让他们觉得Sol既好用又省量；但那些处理复杂任务的资深开发者，就成了消耗大户，常常短时间内就用光窗口额度。蒂博坦言，团队在模型发布前过于关注平均和中位数使用量，忽略了长尾场景中的极端消耗，这也间接导致了部分用户的强烈反弹。
如今，改进已上线，Codex也借此机会调整了对Sol调用行为的处理方式，重点优化了等待工具调用、大量网络搜索等场景下的效率，以减少不必要的响应和输入缓存。重新启用5小时滚动限额，意味着回归常态化控制，但此刻额度刚完成重置，蒂博的建议也很实在：别急着开快速模式一口气用完周额度，先稳住观察，毕竟明天恢复限额后，会不会再次同步重置，目前还没有准信。
对于一直在寻找高性价比开发工具的团队而言，模型消耗与付费限额的平衡始终是个敏感话题。这次Codex的调整，至少传递出一个信号：团队开始正视“越强越耗”的设计代价，并在努力让先进能力不变成额度焦虑的源头。至于18%的增幅能否真正消解资深用户的不满，恐怕还要等窗口恢复后的实际体验来回答。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
