Claude Code的token额度不是按天重置,而是按5小时滚动窗口计算——第一条消息发出的时刻决定了窗口起点。这个机制导致一个常见问题:早上8:30随手问了一句,token在上午11点烧完,下午1:30才能恢复,正好卡在工作效率最高的时段。已经有开发者找到了解决方案:用Claude Code自带的云端定时任务功能,在固定时间点发送一条几乎不消耗token的消息,把5小时窗口锚定到可预测的时间节点上。 5小时滚动窗口的运作逻辑
Claude Code的token预算基于滚动窗口而非固定日历周期。窗口从用户发送第一条消息的整点小时开始计算,而不是从消息发出的精确分钟。举例来说,早上8:47发出第一条消息,窗口锚定到8:00而不是8:47,5小时后即下午1:00重置。
这套机制的直接后果是:每天的重置时间会随使用习惯漂移。周一早9点开始用,重置在下午2点;周二磨蹭到11点才开工,重置就推迟到下午4点。对于需要持续编码的开发者来说,这种不确定性意味着token耗尽的时间点无法预判,经常撞上高产出时段。
除了5小时窗口之外,Anthropic还在2025年中引入了7天滚动周限额,与5小时窗口独立计算。如果周限额用完,等5小时也没用,必须等7天窗口重置。Max计划用户使用Opus 4等高级模型时尤其需要注意这一点。
锚定方案:用Cloud Scheduled Task固定重置节点
核心思路很简单:在每天的固定时间点,让云端自动向Claude Code发一条极轻量的消息(比如"say hi"),触发窗口锚定到该时间点。这条消息使用Haiku模型、不带上下文、不调用工具,token消耗可以忽略不计。
Claude Code的Web端(claude.ai/code/scheduled)支持创建云端定时任务,任务运行在Anthropic托管的基础设施上,不依赖本地电脑开机。具体设置步骤: 第一步:访问 claude.ai/code/scheduled,点击 New scheduled task。
第二步:任务名称随意填(比如"warmup"),Instructions填"say hi",关联一个仓库(必填项),模型选Haiku以降低消耗。
第三步:Repeats选Custom,输入cron表达式。以每天四个时段为例:5 7,12,17,22 * * *,含义是每天UTC时间7:05、12:05、17:05、22:05各执行一次。
第四步:点击Create,任务立即生效。
设置完成后,每个执行时间点会锚定一个新的5小时窗口。以UTC+8(北京时间)为例,上述cron对应的本地时间是15:05、20:05、次日1:05、次日6:05。如果工作时间集中在白天,更适合的cron可能是5 1,6,11 * * *(对应北京时间9:05、14:05、19:05),覆盖上午、下午、晚间三个时段。
注意cron表达式中的时间是UTC,需要根据自己的时区换算。任务执行可能有几分钟的偏移(Anthropic对每个任务施加了固定的jitter以避免同一时刻大量任务并发),但不影响窗口锚定效果。
三种定时方案对比:云端任务 vs GitHub Actions vs 本地Cron
除了Web端的Cloud Scheduled Task,还有两种方式可以实现相同效果。
方案一:Cloud Scheduled Task(推荐)。在claude.ai/code/scheduled直接配置,任务运行在Anthropic云端,不需要本地电脑在线,也不需要额外的CI/CD账号。缺点是Web界面目前要求关联一个GitHub仓库(即使任务本身不需要操作代码),以及自定义cron表达式需要手动输入,没有可视化的时间选择器。最小执行间隔1小时。
方案二:GitHub Actions。开发者vdsmon做了一个叫claude-warmup的开源项目,原理是用GitHub Actions的schedule触发器定时执行claude -p "hi" --model haiku --no-session-persistence。优点是完全可控、日志可追溯、不占用Claude Code的定时任务配额。缺点是需要生成OAuth token并存为GitHub Secret,设置步骤稍多。适合已经重度使用GitHub Actions的开发者。
方案三:本地Cron / launchd。直接在macOS的crontab或launchd中配置定时执行claude -p "hi" --model haiku。优点是零依赖外部服务,缺点是需要电脑保持开机和唤醒状态,笔记本合盖就失效。适合有固定工位台式机的场景。
三种方案的共同原理一致:在目标时间点发一条最小化消息,让5小时窗口的起点变得可预测。选哪种取决于使用习惯——不想折腾就用Cloud Scheduled Task,追求可控性就用GitHub Actions。
实际效果与使用建议
设置完成后,每个工作时段都从满额token开始。以每天三次触发(9:05、14:05、19:05北京时间)为例,9:05-14:05是上午时段,14:05-19:05是下午时段,19:05-次日是晚间时段,每个时段的token预算独立计算。
几个实操注意点:
时区换算务必准确。cron表达式在云端任务中使用UTC时间。北京时间UTC+8,东京UTC+9,美西PDT为UTC-7。填错时区会导致窗口锚定在睡觉时间,完全浪费。
不要设置过于密集的触发。5小时窗口意味着最多每5小时触发一次才有意义,更频繁的触发不会叠加额度,只会额外消耗(虽然极少的)token。
周限额是独立的天花板。5小时窗口的锚定技巧只解决"重置时间不可预测"的问题,不能增加总额度。如果一周内的总使用量触及周限额,定时任务不会绕过这个限制。
Extended Thinking是token大户。单次开启Extended Thinking的复杂推理,token消耗可能是普通对话的数倍。在token预算紧张时,对简单任务关闭Extended Thinking、减少上下文中打开的文件数量、合并多个小问题为一个完整提问,都能显著延长每个时段的可用时间。
用/usage命令监控余量。在Claude Code中输入/usage可以查看当前窗口的消耗进度,也可以在claude.ai/settings/usage查看整体用量。建议在50%和75%时主动调整使用强度,避免在关键编码环节突然触及限额。
这个技巧的边界
锚定5小时窗口是一个合理的使用优化,本质上只是让重置时间变得可预测,没有绕过任何限额。但需要清楚认识到:它不能增加总可用token量,不能绕过周限额,也不能让免费计划获得付费计划的额度。对于token消耗持续超出计划限额的用户,升级到Max计划或优化prompt效率才是根本解决方案。