Codex 限额重置后自动续跑：长任务跨 5 小时窗口的做法与取舍
Codex 的用量重置窗口常把长任务切成碎片，人得守着终端补一句「继续」。这篇梳理社区里几种续跑思路——用官方定时能力、自己写轮询加注入的小工具、把任务拆小——并给出实现清单、幂等与上限保护、账号合规边界，以及哪些坑需要自己验证。
用 Codex 跑长任务的人大多遇到过这种情况：任务正跑到一半，额度见底，提示要等下一个重置窗口。窗口可能长达数小时，人一离开，任务就停在原地等人敲一句「继续」。有人半夜爬起来补一句，有人干脆把剩下的活留给第二天。
社区里因此出现了各种「续跑」方案：有人写了小工具，跟踪用量与重置时间，到点自动发送「继续」并回车；有人指出 Codex 本身就有定时能力；也有人希望能接中转、要 Windows 版、想要带文件的定期任务。讨论背后其实是同一个问题——怎么让被限额切成碎片的长任务，在不违规、不失控的前提下跑完。
问题到底卡在哪一层
需要区分两种限制。一种是模型侧或工具侧的定时唤醒，属于正常功能，你可以让 agent 在指定时间自己开始工作；另一种是账号级的配额与重置窗口，到点之前无论怎么催都不会有额度。很多「自动继续」的诉求混在一起，导致方案选错：用脚本猛刷请求，除了浪费时间和触发风控，并不能让额度提前恢复。
真正需要自动化的只有一件事：窗口恢复的那一刻，把「继续」送进去，并确保只送一次。
三种路径与各自的取舍
路径一：用 Codex 自带的定时/自动化能力
有人提到工具本身已有定时功能，配合让模型自查「这一步是否正常、要不要纠正」，可以做出相当稳的自动推进。
- 适合：任务边界清晰、能写成明确步骤的场景。
- 代价：定时唤醒同样要调用模型，会计入用量；而且它解决的是「什么时候开始」，不是「额度没了怎么办」。
路径二：自建「轮询 + 注入」小工具
这是社区里最常见的做法，本质是三件事：读状态、判时机、注入输入。
- 读状态：优先解析本地已有的会话记录或用量信息，或调用官方开放的用量接口。不要靠抓包伪造请求，那既是合规问题也是稳定性问题。
- 判时机：解析重置时间或限额提示文案，留 30–60 秒容差，避免刚好卡在边界上白发一次。
- 注入输入：agent 在等待输入时阻塞在终端里，直接往管道写字节经常无效。用 tmux、expect 或 PTY 注入更可靠。
# 让任务跑在一个持久会话里
tmux new -s codex
# 判定可继续时，由脚本注入
tmux send-keys -t codex '继续上一步的任务，先输出当前进度再继续' Enter
这类工具和「用量查询类网站」不是一回事：前者是实时监控加动作，后者只提供信息展示，别混为一谈。
路径三：把任务拆小，从根上减少等待
把「一次跑完」改成「每次跑完一个可交付的小块」，每块结束就提交、留记录。这样即使被窗口打断，下次接续的成本也很低，而且不需要任何外挂。
- 适合：重构、批量改写、逐文件处理这类天然可切分的活。
- 代价：需要提前设计任务清单，前期多花十几分钟。
三种路径并不互斥。实践里比较稳的组合是：任务拆小 + 官方定时 + 少量注入兜底。
自建方案的实现清单
| 项目 | 要求 |
|---|---|
| 幂等 | 用状态文件记录已注入次数与时间戳，同一窗口只发一次 |
| 上限保护 | 设最大续跑轮次、最长总时长、连续失败退避 |
| 轮询频率 | 一分钟级别足够，过密只会增加负担 |
| 权限 | 默认沙箱、写操作需确认；动手前先 commit |
| 日志 | 每次注入与模型输出都写入文件，便于回看 |
| 通知 | 跑完、失败、超上限时推送提醒 |
| 环境 | 机器不休眠、网络不断，否则判定会在错误时刻触发 |
max_loops=8; loops=0
while :; do
wait_for_window_reset # 解析用量与重置时间
[ "$loops" -ge "$max_loops" ] && break
tmux send-keys -t codex '继续上一步的任务，先输出当前进度再继续' Enter
loops=$((loops+1))
sleep 120 # 给模型时间，避免重复注入
done
如果希望脚本在半夜也稳定在线，可以把轮询和注入放到一台长期开机的机器上执行，比如按月租用的新加坡独享远程 Mac mini，整机在机房常开、网络稳定，适合长期挂着这类 AI 工具；本机设置不休眠加 tmux 也能覆盖大部分场景，按需要选。
风险与边界
- 账号自动化是否被允许，以官方最新条款为准。 只做「等额度恢复后再继续」是正常使用；用多账号轮换、伪造请求去突破配额，属于明确的违规，也不要参与账号买卖或共享。
- 谨慎对待来路不明的中转。 把凭据交给第三方转发，会带来泄露、日志留存和稳定性风险，相关条款也需要自行确认。
- 别开无限权限的全自动执行。 无人值守时模型误删文件、误改配置的代价很高，沙箱加版本控制是底线。
- Windows 支持情况以官方说明为准。 没有原生版本时，用 WSL 或等价终端环境承载持久会话，通常比另写一套注入逻辑省事。
- 社区里有人把需求丢给模型直接生成 Windows 版本，这条路可行，但生成物同样要自己审一遍权限与幂等逻辑。
小结
「自动继续」解决的是等待，不是额度。先确认卡住的是配额窗口还是任务设计问题，再决定要不要写工具：能拆的任务优先拆，能交给官方定时的就交给官方，最后才用轮询注入兜底，并且一定加上幂等、上限和日志。至于工具的真实行为细节，建议先在小任务上跑几轮验证，再放到重要项目里。
