Claude Code 对齐 5 小时用量窗口：用 Scheduled Routines 预热 Opus 与 Sonnet
Claude（包括 Claude Code）的用量窗口，不是每天在固定钟点统一刷新，而是从窗口内第一次实际请求开始，滚动计算 5 小时。这个细节会直接影响使用体验：真正坐下来准备重度工作时，窗口可能还没启动，也可能已经被更早的一次零散请求提前开掉。
我的做法很简单：用 Claude Code 自带的 Scheduled cloud agents，也就是 routines，在每天真正准备开工的几个时间点之前，自动发送一条几乎零开销的消息。它不调用工具、不执行任务，只负责把窗口起点对齐到我的工作节奏。
核对日期：2026-08-28。Opus 与 Sonnet 分别计算 5 小时窗口，是我本人使用中的实测观察，不是官方文档明文承诺；产品行为以后也可能变化。
先说边界：这是时间规划，不是增加配额
这套配置不会增加订阅套餐本身的总配额上限，也不会绕过任何限制。它做的只是用 Anthropic 提供的官方定时功能，把你自己的用量窗口起点安排到真正需要使用的时刻。
每条预热消息也刻意保持最小化：不调用任何工具，不读取仓库，不执行实质任务。它不是高频、攻击式的滥用请求，更不是所谓“漏洞”。不同订阅档位的用量额度不同，也可能调整，所以本文不写任何“每 5 小时能发多少条消息”或固定 token 数字，只讨论如何安排你已有的用量额度。
机制：5 小时滚动窗口，以及两个模型分池
第一条实际请求会启动一个 5 小时窗口。假设你早上随手问了一句，等下午真正准备连续写代码时，先前窗口可能已经消耗了一部分，甚至已经结束。反过来，如果一直没有请求，窗口也不会因为某个固定刷新点自动替你对齐。
另一个关键点是：根据我自己的实测观察，Opus 与 Sonnet 是两个独立配额池，各自计算自己的 5 小时窗口。因此，只给其中一个模型发预热消息，并不能同时替另一个模型启动窗口。这个“分池”结论来自实际使用观察，不能当成 Anthropic 对未来产品行为的官方保证。
所以我的安排是：每个计划开工的时间点，分别给 Opus 和 Sonnet 各发一条，两个任务再错开几分钟。
用 Scheduled cloud agents 创建 routine
有两种适合普通用户的入口：
- 打开管理面板：https://claude.ai/code/routines
- 在 Claude Code 中输入
/schedule，按交互提示创建
也可以用命令行工具程序化创建，但普通使用没有必要展开。创建时不需要绑定 GitHub 仓库，选择默认 Environment 即可，sources 留空。
四个时段各自对应一个贴近真实生活的话题，同一时段的两个模型使用相同的 prompt：
| 时段 | 话题方向 | prompt 原文 |
|---|---|---|
| 早上（07:30/07:35） | 天气或早高峰路况 | 我准备开始上班了，随口问我一句今天天气怎么样或者早高峰堵不堵（自己选一个话题，说法别老一样），像朋友聊天那样简单回一句就行。 |
| 午休后（13:01/13:07） | 中午吃什么 | 到午休时间了，随口问我中午吃点什么好，像朋友聊天那样简单回一句就行，说法别老一样。 |
| 下班（18:10/18:14） | 下班路况 | 我准备下班了，随口问一下现在下班路上堵不堵，像朋友聊天那样简单回一句就行，说法别老一样。 |
| 晚上（23:20/23:23） | 剧集推荐 | 晚上有点空，随口问我最近有什么好看的剧集值得推荐，像朋友聊天那样简单回一句就行，说法别老一样。 |
固定不变的模板化消息即使内容本身无害，“一字不差、逐日准点”的模式也容易成为自动化行为特征。因此 prompt 只固定生活化的话题方向，具体措辞由模型每次现场组织，不维护写死的问题库。
权限只给最小集合，例如：
{
"allowed_tools": ["Read"],
"sources": []
}
这里给出 Read 并不是要它真的读取文件，而是把可用工具压到最低，靠这一层配置（不是 prompt 文案）保证它不会真的去执行任务。sources 留空，意味着任务不挂仓库。
我的时间表：四个工作节点，八个任务
我一天挑四个真正准备重度使用 Claude 的节点：早上上班、午休后、下班、晚上加班前。因为 Opus 与 Sonnet 分开触发，所以一共是 4 个时间点 × 2 个模型，也就是 8 个定时任务。
下面是我的北京时间（CST）配置，仅供理解设计方法，不建议原样照抄：
| 使用节点 | Opus | Sonnet |
|---|---|---|
| 早上上班 | 07:30 | 07:35 |
| 午休后 | 13:01 | 13:07 |
| 下班 | 18:10 | 18:14 |
| 晚上加班前 | 23:20 | 23:23 |
同一节点的两个模型错开 5～7 分钟，避免同一秒并发。真正重要的不是这些钟点，而是它们对应我的实际作息。
怎么套到自己的日程
先找出一天里真正会重度使用 Claude 的四个时刻，再反推 routine：
- 每个时刻提前几分钟触发，给任务留出生效时间。
- 每个时刻分别为 Opus、Sonnet 创建任务。
- 两个模型错开几分钟，不要同一秒发送。
- 相邻两个触发点之间必须大于 5 小时。
最后一条尤其重要。如果两个触发点只隔 4 小时多，后一次请求仍然落在上一个窗口里，它不会替你开启一个全新的 5 小时窗口，只是白白多发了一次请求。先画出自己的工作时间轴，再创建 routine，比直接抄别人的 cron 更可靠。
四个实测踩坑
第一，cron 是确定性调度，不支持随机抖动。每次都会精确按设定时间触发，没有“随机浮动几分钟”的选项。
第二，首次创建的定时任务偶尔会排队几分钟。例如设为 23:30，第一次实际触发可能显示在 23:34 左右；后续一般会自我纠正。如果长期都有固定偏移，可以把 cron 提前几分钟补偿。
第三，目前这类定时任务不支持通过命令行或 API 删除。要删除任务或修改时间，只能去 https://claude.ai/code/routines 手动操作。
第四，切换 Claude Code 账号后，旧账号创建的定时任务不会自动迁移。需要登录新账号，再把这些 routine 重新创建一遍。
最后检查一次
配置完成后，确认每个工作节点都有 Opus 和 Sonnet 两条任务，sources 为空，四个时段使用对应的生活化 prompt 且要求每次换一种说法，模型之间已错开几分钟，相邻窗口也确实超过 5 小时。
它解决的不是“怎样获得更多配额”，而是“怎样别让已有配额在错误的时间开始计时”。对于工作节奏比较固定的人，这个小调整足以让每次真正开工时，更稳定地落在一个刚启动的完整窗口里。