Claude上天，额度无边

额度又炸了

用Claude干活干得多的人，大概都经历过这种场面：代码写到一半，文档改到关键段落，突然弹出一条提示，额度用完了，请稍后再试。

Max账号都不够用吗？说好的不限量呢？

严格来说，确实没有"不限量"这回事。Claude的付费订阅有额度上限，用完了就得等。问题是，这个"等"经常卡在最不该卡的地方，手头的任务断在中间，思路打断，节奏全乱。

那额度到底怎么算的？搞清楚这件事之后，我们找到了一个办法，让这个问题基本消失了。

两层限制

Claude的付费账号同时受两层限制管着。

第一层是周额度。每个账号有一个固定的每周重置时间，比如每周三晚上9点，到了那个时间点额度恢复。这个重置时间是Anthropic给每个账号分配的，不会随着使用习惯变化。

第二层是5小时滚动窗口。这是更常碰到的那道墙。

日常工作中真正卡人的，几乎都是这个5小时窗口。

5小时限制是个滚动窗口

5小时窗口的机制，说起来就一句话：从发出第一条消息的那一刻开始计时，往后推5个小时，这段时间内有一个token消耗上限，用完就得等窗口结束。

但细节藏在"第一条消息的那一刻"里。

这个窗口不按整点开始，也不在午夜重置，也不在每天某个固定时间启动。它的起点完全取决于"这轮的第一条消息是什么时候发的"。计时的最小单位是10分钟，向前取整。比如9点47分发了第一条消息，系统会把起点归到9:40，窗口就是9:40到14:40。

窗口结束之后，系统不会自动开始下一个窗口。它会一直处于空白状态，直到再发一条消息，才开启新的5小时。

这就是"滚动"的含义：窗口的位置不固定，每次都由第一条消息的时间决定。

一天只能跑两轮

理解了窗口机制之后，拿一天的时间排一下，问题就很清楚了。

假设早上9点坐下来开始工作，发了第一条消息，窗口锁定为9:00到14:00。上午是工作密度最高的时候，如果用得比较猛，可能12点额度就用完了。这时候窗口还没结束，得干等到14点。

14点窗口释放，再发一条消息，新窗口开到19点。这一轮如果也是正常工作强度，可能17点、18点就差不多了。

一天下来，两轮。

如果工作量大，两轮之间那段空白就很难受。16点用完额度，19点才能继续，中间3个小时干等着。而且因为每天坐下来的时间不一样，窗口的起止点天天在漂移，今天是9点到14点，明天可能是9点半到14点半，后天又变了。没办法提前规划，也没办法跟其他安排配合。

问题的根源很明确：窗口的起点是随机的，取决于每天什么时候发第一条消息。

手动踩点

道理不复杂：触发一个窗口只需要一条消息，哪怕用最轻量的模型回复一个字也算。

我平时会手动做这件事。早上到了先随便发一条消息，把窗口"踩"到一个固定的时间点上。比如每天固定8点发一条，窗口就是8:00到13:00，13点之后再发一条，窗口13:00到18:00，依此类推。

但手动操作有个很现实的问题：不稳定。有时候忙起来忘了，有时候还得天天想着这个事，很消耗心神。偶尔做一两次不费事，每天做就变成了一个负担。

自动化的动机就是这么来的。

本地定时

我们之前开发了一个叫ClaudeTerminal的产品，可以在本地电脑上定时发消息触发窗口。设好时间它自己跑，比手动靠谱多了。

跑了一段时间之后发现一个根本问题：它依赖电脑开机。

电脑关了，定时任务就不跑了。系统重启了，软件要手动重新打开。偶尔崩一次，当天的窗口就漏掉一两个。对于一个每天要稳定执行四次的任务来说，把它绑在一台本地电脑上，基础不够稳。

需要一个不关机的东西。

搬到云上

正好手上有一台云服务器，7×24小时在线，日常已经在跑其他服务了。

我们跟Fable 5.1聊了一下这个需求，发现实现起来比想象中简单。核心步骤就几个：在服务器上装一个Claude Code CLI，用账号登录一次（只需要登录这一次，之后token会自动续期），然后写一条cron定时任务，到了指定时间自动执行一条命令。

命令本身非常轻量，用haiku模型（Claude家族里最小、最省额度的型号）发一句"只回复我1"，模型回一个数字"1"，整个过程消耗的token可以忽略不计。

执行结果每次追加到一个日志文件里，记录时间、账号、模型、回复内容、耗时、退出码，随时可以回溯。

两个账号各三四秒搞定，窗口就开了。

从部署完成的那一刻起，电脑再也不用操心这件事了。关机、出门、睡觉，服务器按时执行，一次不漏。

6、11、16、21

四个时间点的选择花了点心思。

6:00、11:00、16:00、21:00，把一天切成四个5小时的区块，窗口首尾相接，中间没有空隙。

早上6点第一个窗口开启。没有人6点就开始工作，但这恰恰是重点。等8点、9点坐下来的时候，窗口已经过了两三个小时，前面那段空闲时间没有产生任何token消耗，额度全部留给了真正工作的两三个小时。相当于把窗口里"不干活"的时间段挪到了前面，把"干活"的时间段集中在后半程。

11点第二个窗口接上，覆盖到下午4点。中午吃饭休息的时间自然包含在窗口里，不浪费额外的等待。

16点第三个窗口到晚上9点。下午和傍晚的工作时段，加上晚饭时间，正好在这个窗口里。

21点第四个窗口留给需要晚上加班的情况。如果不加班，这个窗口自然消耗掉，不影响第二天早上6点的新一轮。

四个窗口排下来，从早到晚任何时段坐下来工作，当前窗口里都有剩余额度可用。以前一天只能跑两个有效周期，现在是四个，而且时间固定，可以围绕它安排工作节奏。

几个落地的问题

多账号的情况下，每个账号在服务器上有独立的配置目录，cron任务分开跑，互不干扰。一个账号出了问题不影响另一个。

账号到期没续费怎么办？登录状态和订阅状态是两回事。到期后每次请求会失败，日志里记一条错误，仅此而已。续费之后不需要重新登录，下一个定时任务会自动恢复正常。

想改时间怎么改？时间表写在一个独立的配置文件里，没有散在系统配置的各个角落。服务器上还跑着一个Openclaw，我们给它留了一份操作文档，想改时间的时候直接跟它说一句就行，不用自己登服务器改文件。

整套东西跑起来之后回头看，其实做的事情很小：一条定时任务，一句最轻量的消息，一个不关机的服务器。但它解决的问题很实际，把白天可用的token量，几乎翻了倍。