Codex 额度不够用：额度翻倍小技巧 + 白嫖长任务通道

很多人用 Codex 撞限以后，第一反应是干等。我以前也会这样。 但最近我发现，真正好用的不是一个技巧，而是两个技巧叠在一起：先提前触发 5 小时窗口，把刷新点挪到你的工作时间中间；然后在额度刚补回来一点，比如只有 1% 左右时，直接用 /goal 开全局任务。 我这边实测下来，一个 /goal 任务在 5 小时额度用完后，又继续跑了大约 4 小时，最后把任务跑完了。这就很香。 “只要全局任务已经启动，系统会让这一轮任务尽量收尾”。先说清楚，我不确定是不是官方规则，也不保证以后一直这样。但就目前体验看，它确实像是绕过了周额度的即时拦截。 这篇就说我会怎么用。

第一步：先把 5 小时窗口挪到你干活的时候

如果你的账号当前显示的是 5 小时使用窗口，有一个小技巧很值得做：不要等到真正开工才发第一条消息，提前 2 到 3 小时发一条短消息，把窗口先触发起来。 这不是破解额度，也不是让官方白送 token。它只是把刷新点挪到你真正干活的时间里。 比如你每天主要在下午 2 点到 6 点用 Codex。
如果你 2 点才开始发第一条消息，窗口大概率从 2 点算到 7 点。你要是 3 点半撞限，后面就只能干等。 但如果你上午 11 点提前发一条 ping ，窗口从 11 点开始，到下午 4 点左右进入下一轮。这样你 2 点到 6 点这段核心时间，就能吃到前一轮尾巴和后一轮开头。 这就是“额度翻倍”的真实含义。不是总额度永久翻倍，而是你最忙的几个小时里，可用窗口变多了。

先确认一件事：不是所有账号都按同一套规则

这个技巧成立的前提，是你的账号当前确实显示 5 小时窗口。 Claude 官方帮助文档明确写了 Pro 计划存在每 5 小时重置的 session-based usage limit，同时还可能叠加周额度、月额度、模型和功能限制。Claude Code 的 Pro / Max 说明里也提到，Claude 和 Claude Code 共享使用限制，实际可用 prompt 数会受项目复杂度、代码库大小、auto-accept 设置影响。 Codex 这边，OpenAI 帮助页更强调 agentic usage：任务越复杂、上下文越大、运行越久，消耗越多。到限以后要看 Codex usage page 或限额 banner。 所以我不会把“5 小时窗口”写成所有计划永远固定的铁规则。更准确的说法是：如果你的 Codex / Claude Code 当前显示 5 小时窗口，你就可以主动安排这个窗口的开始时间。 真正有用的不是“多薅额度”，而是别让刷新点卡在你下班以后。

我会怎么设置：开工前 2 到 3 小时，自动发一句话

如果你用的是 Codex App，并且版本里有 Automations，就直接建一个每天触发的自动化。时间填你主要干活前 2 到 3 小时，动作只做一件事：发一条短消息。 内容越短越好：

ping

或者：

稍后继续工作，先触发窗口。

不要让它读项目、扫文件、跑测试、改代码。这条自动化的任务不是干活，只是提前把窗口打开。 Claude Code 也一样。如果你用的是客户端，看看有没有 Routines / 自动化能力。如果你用 CLI，macOS / Linux 可以用 crontab ：

0 11 * * * claude -p "ping"

Windows 就用任务计划程序。我建议让 Agent 帮你生成命令可以，但先让它展示命令，不要直接执行。定时任务是系统级改动，最好自己确认一眼。

这个技巧适合固定时间高强度用 Agent 的人

如果你只是偶尔问 Codex 两句，这个设置没必要。它最适合这类人：

• 每天固定下午或晚上集中写代码
• 经常让 Codex 跑长任务
• 经常在核心工作时间撞限
• 用 Claude Code / Codex 做 PR、重构、测试修复
• 已经开始关注额度、窗口和任务复杂度

如果你的工作时间很随机，提前触发窗口就不太好安排。但如果你每天 14:00 到 18:00 都在用 Agent，把触发时间放到 11:00 左右就很舒服。到 16:00 左右刷新一轮，刚好落在后半段。 我不建议一天设很多个 ping。你不是在刷额度，你只是把窗口排到更适合自己的时间。

第二步：额度刚补到 1%，就把大任务交给 /goal

这才是更像白嫖的地方。额度刚补回来一点时，别拿它闲聊，也别让它解释概念，直接把真正的大任务放进 /goal 这种全局任务模式里启动。 我这边的测试是：一个 /goal 任务跑到中途，5 小时窗口额度已经用完，但任务没有立刻停。它又继续跑了大约 4 小时，最后把这一次全局任务跑完了。 这个体验很像“已经启动的全局任务可以继续收尾”。更关键的是，我这次测试里没有看到它因为周额度提示立刻停掉。 所以如果你问我这招值不值得用，我的答案很明确：值得。但用法要对。不要等额度满了才开大任务，只要额度补到能发起任务，哪怕只显示 1% 左右，也可以先把 /goal 开起来。 启动以后，不要频繁打断，不要中途塞一堆无关需求，让它专心把这一次全局任务跑完。我会把它理解成“抢到一次长任务通道”，不是“永久多了一桶额度”。 目前 OpenAI 这边没有在我测试的场景里把它立刻卡死。至于后面会不会调整，谁也别打包票。

这招最适合拿来跑长任务

我不会拿 /goal 去问一句话答案，太浪费。它更适合这些任务：

• 修一个比较完整的 bug
• 跑一轮仓库级重构
• 让 Codex 补测试、跑测试、再修失败
• 梳理一个复杂模块并产出改动
• 做一次跨文件的长链路任务

这种任务最怕中途断。所以我现在的习惯是：窗口快刷新前，先准备好任务描述。额度一补回来，直接 /goal 开跑。 不要在这时候浪费消息来问“你能做什么”“帮我分析一下”。把需求一次说清楚，目标、范围、验收标准都写进去。越像真实任务，越适合交给 /goal 。

最后说一句

Codex 额度不够用时，别只会硬等。先看你的 usage page 或限额提示，如果确实是 5 小时窗口，就把窗口提前触发。 下午 2 点开工，就上午 11 点 ping 一下。
晚上 8 点开工，就下午 5 点 ping 一下。 如果额度只补回来一点，但已经能发起任务，就优先开 /goal 跑大任务。