Claude（包括 Claude Code）的用量按 5 小时滚动窗口计算。窗口不是每天到某个固定时间统一刷新，而是从窗口内第一次实际请求开始计时。

这个机制本身不复杂，但很容易和真实工作节奏错位。例如，早上临时问了一句，下午真正准备连续使用 Claude Code 时，原来的窗口已经运行了一段时间；或者白天一直没有请求，真正开工后才开始计时。

我的处理方式是使用 Claude Code 自带的 Scheduled cloud agents，通常也叫 routines。在每天真正准备重度使用的几个时间点前，自动发送一条几乎零开销的请求，让窗口起点尽量贴近实际开工时间。

先强调边界：这不是漏洞，也不是绕过限制。它不会提高订阅套餐本身的总配额上限，只是利用 Anthropic 官方提供的定时功能规划已有用量。本文也不会给出"每 5 小时多少条消息"或固定 token 数字，因为不同订阅档位的额度不同，而且可能调整。

一、理解 5 小时窗口与模型分池

第一条实际请求会启动一个 5 小时窗口。想让重度工作尽量落在完整的新窗口内，就需要把第一条请求安排到真正开工之前，而不是任由零散请求提前启动。

根据我本人的实测观察，Opus 与 Sonnet 使用两个独立的配额池，各自计算 5 小时窗口。因此，给 Opus 发请求不会同时替 Sonnet 启动窗口，反之亦然。

这里必须加一个限定：Opus / Sonnet 分池是作者本人实测观察到的产品行为，并非官方文档明文承诺的规格，不能视为未来不变的官方保证。

二、创建 Scheduled cloud agents / routines

普通用户有两个创建入口：

1. 网页管理面板：App unavailable in region | Claude by Anthropic
2. 在 Claude Code 中输入 /schedule，按交互提示创建

也可以使用命令行工具程序化创建，但这不是完成本文配置的必要条件。

创建时无需绑定 GitHub 仓库，选择默认 Environment，sources 保持为空即可。四个时段分别使用下面的 prompt，同一时段的 Opus 和 Sonnet 任务使用同一条：

时段	话题方向	prompt 原文
早上（07:30/07:35）	天气或早高峰路况	我准备开始上班了，随口问我一句今天天气怎么样或者早高峰堵不堵（自己选一个话题，说法别老一样），像朋友聊天那样简单回一句就行。
午休后（13:01/13:07）	中午吃什么	到午休时间了，随口问我中午吃点什么好，像朋友聊天那样简单回一句就行，说法别老一样。
下班（18:10/18:14）	下班路况	我准备下班了，随口问一下现在下班路上堵不堵，像朋友聊天那样简单回一句就行，说法别老一样。
晚上（23:20/23:23）	剧集推荐	晚上有点空，随口问我最近有什么好看的剧集值得推荐，像朋友聊天那样简单回一句就行，说法别老一样。

这样设计的关键不是维护一套写死的问题库，而是只固定符合当下场景的话题方向，让模型每次现场组织具体措辞。固定文案即使内容无害，"一字不差、逐日准点"的模式本身也容易成为自动化行为特征。

同时只提供最小权限。例如配置概念如下：

{
  "allowed_tools": ["Read"],
  "sources": []
}

allowed_tools 中只保留最小集合，并不意味着一定要调用 Read。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 分钟，避免在同一秒并发。读者不应原样照抄这组时间，而应按自己的作息调整。

四、设计自己的触发时间

可以按以下步骤设计：

1. 找出真正的重度使用时刻

不要从 cron 表达式开始，而是先写下自己一天中真正会连续使用 Claude 的几个节点，例如正式上班、午休后恢复工作或晚间集中开发。

2. 提前几分钟触发

定时任务应比实际开工时间提前几分钟，给服务排队和生效留出余量。具体提前量按自己的观察调整。

3. 保证相邻触发点大于 5 小时

这是最重要的约束。如果同一模型的两个触发点间隔不超过 5 小时，后一次请求仍然会落入上一个未结束的窗口，无法启动新的完整窗口，相当于白白增加了一次请求。

4. 分别创建 Opus 与 Sonnet 任务

基于前述实测观察，每个时间节点都要为两个模型各建一条任务，并错开几分钟，不要同一秒发送。

五、四个实测踩坑

1. cron 不支持随机抖动

这里的 cron 是确定性调度，每次都按设定时间触发。它没有"在目标时间附近随机浮动几分钟"的选项。如果想避开同一秒并发，需要直接给 Opus 和 Sonnet 设置不同的固定时间。

2. 首次任务偶尔有排队延迟

新建任务第一次触发时，偶尔会晚几分钟。例如设定为 23:30，首次实际触发可能显示在 23:34 左右。后续运行一般会自我纠正。如果长期存在稳定偏移，可以把 cron 提前几分钟补偿。

3. 目前不能通过命令行或 API 删除

创建可以交互式或程序化完成，但目前删除任务、修改时间不能通过命令行或 API 操作。需要打开 https://claude.ai/code/routines，在网页管理面板手动处理。

4. 切换账号后任务不会迁移

旧 Claude Code 账号中建立的 routines 不会自动带到新账号。切换账号后，需要在新账号下重新创建全部定时任务。这也是我这次重新配置的直接原因。

六、配置完成后的检查清单

• 每个重度工作节点都有 Opus 与 Sonnet 两条任务；
• 四个时段使用对应的生活化 prompt，并要求模型每次现场组织不同说法；
• allowed_tools 保持最小权限；
• sources 为空，没有挂载 GitHub 仓库；
• 两个模型错开几分钟；
• 同一模型相邻触发点之间大于 5 小时；
• 首次执行后检查实际触发时间，长期偏移再补偿；
• 换账号后确认已经在新账号重建。

这套方法优化的是时间，不是配额数量。它把窗口的第一次请求安排到真实工作之前，让已有用量额度更贴合自己的作息，同时保持请求内容最小化，不执行任何实质任务。

完整版本也同步发在我的个站 chengbei.org，后续产品行为若有变化，我会按实际使用继续核对。