更新 — 2026年夏天：这个方法对我已经失效
到2026年夏天，这套 workflow 对我来说已经不再稳定可用。我的账户中 5 小时使用窗口的计数器消失了，只剩周限额仍然可见。实际效果是，我之前围绕它安排工作的那个较短重置窗口不存在了。
更关键的是长任务的行为发生了变化。当一个较大的 Codex 任务运行到我的周限额耗尽时，我看到的是工作停止，而不是像以前那样继续推进到完成。因此，我原来“在最后 3–5% 启动最重任务”的规则基本失去了意义：我不能再指望已经开始的任务可以越过周限额继续执行。
这里必须严格区分我的实际观察和官方产品规则。我能确认的是自己账户和 workflow 中发生的事情，但我无法证明 OpenAI 已经永久取消了所有用户的 5 小时窗口。事实上，OpenAI 当前的 Codex 文档仍然提到 5 小时窗口和周窗口，并说明活动中的 turn 在达到限额后有时仍可继续，但受 fair-use 限制。因此，我把2026年夏天的变化记录为我真实经历到的产品行为，而不是所有账户都适用的官方规则。
下面的正文保留为这次变化之前确实对我有效的 workflow 记录。对于当前情况，应以这里的更新为准，而不是旧正文中的现在时建议。
当我在 ChatGPT Plus 中的 Codex 使用量显示只剩大约 3–5% 时，我不会再把剩余额度花在小 prompt 上。相反，我会启动已经准备好的、规模最大的工程任务。
对我来说，这通常是完整的 TypeScript 迁移、全 repository 的 ESLint 清理、大型 codebase 的深度 bug review，或者大规模结构性 refactor。我经常提前准备好多个项目，这样最后一小段 usage 可以给到当时真正能直接开始的重任务。
我改变用法，是因为反复观察到一个现象。不是一次，而是多次，我在可见额度快耗尽时启动了较大的工作，之后即使界面看起来已经没有额度，Codex 仍然继续推进任务。有些情况下任务甚至继续到了完成。这个现象重复得足以改变我的调度方式，但不足以让我把它写成产品保证。
改变我 workflow 的那个观察
快到 usage limit 时，人很自然会变得保守：担心大任务中途被截断，于是把最后一点额度留给小请求。现在我反过来使用最后的 3–5%。对我来说，它更像一个 launch window。
我不再问“还能塞几个小 prompt”，而是问：“趁 included usage 还没用完，我现在应该启动哪个已经准备好的、价值最高的任务？”
这个方法能成立，是因为项目本身已经准备好，任务范围也足够明确。我不会用最后几个百分点去探索“到底要做什么”，而是直接开始执行。
关于名称和限制的一个重要修正
我以前把它叫作“Codex Plus”，但这只是口头简称，并不是官方产品名称。OpenAI 的表述是：Codex 包含在 ChatGPT Plus 中。这一点值得修正，否则容易让人以为 Codex Plus 是单独的套餐或产品。
OpenAI 当前的Codex 使用文档也明确说明，消耗量会随工作规模和复杂度、模型以及 task 的运行位置而变化，并且存在包括 5 小时窗口和每周窗口在内的 usage windows。因此，本文里的“3–5%”指的是 usage 界面显示的剩余百分比，不是实际时间、token 或保证可完成工程工作量的 3–5%。
符合条件的 Plus 用户在 included limit 用完之后，也可以通过 credits 延长 Codex 使用。这并不会让这个 workflow 失效，只是让边界更清楚：我讨论的是如何分配订阅中包含的 usage，而不是如何绕过 quota。
我会在最后 3–5% 启动什么
我通常把这类范围较大的工程工作留到这个时刻：
- 完整 TypeScript 迁移
- 全 repository 的 ESLint 清理
- 大型 codebase 的深度 bug review
- 大规模结构性 refactor
与其把剩余额度拆成一串价值很低的小请求，我更愿意启动其中一个完整的大任务。对这类工作而言，准备好的 repository 和清楚的目标，比“聪明”的 prompt 文案重要得多。
提前准备多个项目也是同样的道理。如果某个 repository 还需要额外决策或 setup，我不会把最后的 window 浪费在准备它上面，而是可以直接切到另一个已经 ready 的项目。
真正的约束是准备程度
重点不是“等到 3% 再粘贴一个超长 prompt”。如果 task 本身很模糊，有限 budget 很容易消耗在 exploration、clarification 或错误方向的工作上。这个模式只适用于项目已经可以执行、task scope 已经比较清楚的情况。
如果开发者想尝试类似 workflow，一个实用的 preflight 是提前写清 scope：什么要改、什么不要改、有哪些 constraint、结果如何 validate、希望 agent 最终交付什么。这些是通用工程 safeguard，并不意味着某种特殊 prompt 格式能够解锁更多 usage。
这样的准备还有一个好处：如果 limit 真的把大任务截断，也更容易继续。只要 scope 和 validation criteria 从一开始就清楚，半完成的 migration 或 review 都更容易接着做。
我能确认什么，以及不能确认什么
基于自己的使用，我能确认的范围很窄：多次出现过已经启动的 task 在可见 usage limit 看起来耗尽之后仍继续推进的情况，有时还完成了。
但我不能确认背后的 mechanism。我不能说 OpenAI 会给所有 running task 一个隐藏 grace period，也不能说最后 3–5% 一定足够完成任意规模的大任务，更不能说这个 behavior 永远稳定，或者它是绕过 limit 的办法。OpenAI 文档没有承诺这些。
这个区分很重要。我会参考自己反复观察到的 behavior 来安排工作，但不会把它当保证。如果 task 在 limit 处停止，我不会认为产品出了问题。只要剩余 included usage 被用在比几个小 prompt 更重要的工作上，这个策略仍然达到了目的。
任务完成不等于任务已经验证
任务越大，另一个区别越重要：completion 不等于 correctness。TypeScript migration 能 build，不代表 runtime behavior 正确；ESLint clean 不代表 business logic 正确；bug review 标出可疑 pattern，也不代表已经确认真实 bug；即使 refactor 的 tests 全绿，可信度也取决于 tests 和 checks 实际覆盖了什么。
这个 workflow 改变的只是我什么时候开始工作，并不会降低 validation 标准。大型 agentic change 仍然需要与风险匹配的检查，例如 diff review、typecheck、tests、build、runtime checks 或项目特定的 verification。
什么时候不适合这样做
并不是所有大 task 都适合放在 limit 最后启动。如果工作本身还不明确、需要频繁 product decision、涉及 destructive 或 production-sensitive operation，或者中断后会让 repository 留在危险的中间状态，这种方法就不合适。
这时，更小且边界清楚的 task，或者一个新的 usage window，通常是更好的工程选择。目标不是让最后一个 prompt 看起来更“猛”，而是把稀缺的 included usage 用在能够安全产生有效进展的工作上。
我现在的规则
当 ChatGPT Plus 中包含的 Codex usage 只剩大约 3–5% 时，我不再优化“还能发几个 prompt”。我会看提前准备好的项目，启动其中最重、scope 清楚、并且真正值得做的工程任务。
如果 visible counter 到 0 之后 Codex 还在继续，我把它当作自己反复观察到的有用 behavior，而不是应得的保证。如果它停了，我也不会意外。我没有找到绕过 limit 的方法。我只是找到了一个更好的方法，决定在撞上 limit 之前到底应该启动什么。