Codex 优化额度消耗，使用时长提升 10%-50%

Codex 正在重置额度，并且已经做了 Token 消耗的优化，理论上来说现在 Codex 的额度会更耐用了。 --- 以下来自 Tibo 推文 --- Tibo：我们正在为所有 Codex 和 ...

Codex 正在重置额度，并且已经做了 Token 消耗的优化，理论上来说现在 Codex 的额度会更耐用了。 --- 以下来自 Tibo 推文 --- Tibo：我们正在为所有 Codex 和 ChatGPT Work 的付费用户重置使用额度。 如果你想了解 Codex 额度消耗问题的最新进展，请接着往下看。最近，我们的团队一直在日夜奋战，翻阅了成千上万份用户报告，并马不停蹄地发布了一系列修复补丁。 接下来，根据你使用 Codex 的习惯不同，你会发现自己的额度比以前变得更“耐用”了——使用时长大约能增加 10% 到 50%。 这次我们真的是拿着“显微镜”进行了地毯式排查，揪出了许多潜伏已久的小毛病。以下是我们发现并修复的核心问题： - Compaction（上下文压缩）。 在进行压缩时，我们之前错误地保留了旧图片，有时这会让上下文体积依然很大，从而再次触发压缩操作。修复后，对于重度使用图片的用户来说，额度消耗下降了约 10%。已修复。 - Memory（记忆机制）。 后台负责处理记忆的程序有时会继承“停止挂钩”（Stop hooks），导致在挂钩阻止它们结束时，这些程序依然在无意义地空转。这虽然只影响了不到 1% 的用户，但在极端情况下表现得非常糟糕——我们甚至观察到一个线程循环检查了 15,000 次自己“是否可以停止”。已修复。 - Goals（目标指令）。 在某些情况下，设定好的 `/goal` 指令在完成后，并没有乖乖停下，而是越过了预定的停止条件继续运行；或者，模型会死磕那些已经失效的工具，无限重试而不停止。我们看到的一些极端案例中，这竟然白白消耗了用户每周 15% 到 70% 的额度！已修复。 - Automations（自动化任务）。 部分自定义的定时任务，其运行频率超出了用户的实际设定。已修复。 - Subagents（子智能体）。 执行复杂任务时，主模型有时会调用其他专门的模型来协助）较小的模型（例如 Luna）有时会在没有被明确指令要求的情况下，擅自“请外援”调用能力更强（也更耗费额度）的助手模型。同样，如果负责调度的模型本身没有开启 `/fast`（快速）模式，它却会错误地要求子智能体以 `/fast` 模式运行。已修复。 - Computer History（计算机历史记录）。 旧版的代码实现会导致系统反复对重叠的活动记录进行总结。在部分案例中，单是这个小失误，每周就能吃掉用户高达五分之一的额度。已修复。 - Rolling task summaries（滚动任务总结）。 在普通的对话轮次中，系统会触发额外的后台请求。这不知不觉中增加了大约 1% 的 token（词元）消耗。虽然每次只扣一点点，但积少成多也是一笔不小的开销。我们现在已经禁用了这个功能。 - MCP。 部分工具返回的结果被系统重复编码了两次。我们还发现，一些工具的指令会被意外截断，导致系统不得不重新获取。已修复。 为了彻底斩草除根，我们对系统架构进行了底层调整，以防止这些问题卷土重来。退一万步说，即便问题真的复发，我们的团队也会第一时间收到警报。此外，我们正在开发一项新功能，未来你将可以直接在应用内清楚地看到额度究竟花在了哪里，再也不用瞎猜了。 毫无疑问，我们现在正在为大家重置所有的使用额度。祝大家度过一个愉快的周六！ Tibo @thsottiaux We are reseting usage for all paid users of Codex and ChatGPT Work. Please continue reading for an update on Codex usage limits. The team has been working around the clock, going through thousands of reports and shipping fixes. Depending on how you use Codex, you should see your usage go between 10% and 50% further than before. We really went with a fine comb, with many uncovered small things being longstanding and here is what we found and fixed: - Compaction. We were keeping old images during compaction, sometimes making the context large enough to trigger compaction again. After the fix, usage dropped around 10% for users making heavy use of images. Fixed. - Memory. Background memory workers could inherit Stop hooks and keep running when the hook wouldn’t let them finish. This affected fewer than 1% of users, with the long tail being pretty bad and we saw one example thread check whether it could stop 15,000 times. Fixed. - Goals. In some cases, a set /goal could finish and then keep going past the intended stop condition, or the model would keep retrying broken tools without stopping. We saw examples consume anywhere from 15% to 70% of a weekly allowance. Fixed. - Automations. Some custom schedules could run more frequently than configured. Fixed. - Subagents. Smaller models (e.g. Luna) sometimes picked more capable helpers without being explicitly asked. The same was true where the orchestrating model not running in /fast mode could request sub-agents to run /fast. Fixed. - Computer History. The older implementation could lead to repeatedly summarizing overlapping activity. For some cases we saw it consume up to one fifth of the weekly usage per week. Fixed. - Rolling task summaries. Ordinary turns were triggering extra background requests. These added about 1% to token usage. Small each time, but it adds up. We have disabled this. - MCP. Some tool results could be encoded twice. We also found tool instructions getting cut off and fetched again. Fixed. We’ve also made architectural changes to prevent these from regressing and our teams will get paged if it happens regardless. We are also working on showing you directly in the app where your usage goes so you don’t have to guess. Goes without saying that we’re resetting usage limits and I hope you enjoy a very nice Saturday! 🔗 View Quoted Tweet 💬 5 🔄 1 ❤️ 7 👀 2543 📊 5 ⚡