编程 Agent 额度什么时候回血？三种刷新周期与你的排期节奏

2026-08-08

用 Agent 写代码久了，你迟早会遇到这么一天：改到一半，工具弹出一句”额度不足”。这时候你脑子里蹦出来的第一个问题通常不是”我花了多少钱”，而是——什么时候能接着用？

这个问题的答案，比”我买了多少额度”更影响你的实际工作方式。同样是”一个月 1000 单位”，如果这 1000 是一个月度总池子、你想哪天用完都行，那你完全可以憋到月底冲刺；如果它是按天摊给你的、每天到点回血一点，那憋是憋不出来的，你只能把大活拆开推进。这两种规则下的排期方式，几乎是相反的。

这篇不给你任何一家的具体刷新数值——原因后面会讲，简单说就是大部分家根本没公开。这篇给你的是：三种刷新形态的辨认方法、每一种对应的排期打法、deadline 前的通用策略，以及在官方没文档的情况下你怎么自己摸出规律。读完你至少能做到一件事：拿到一个新工具时，先花两分钟判断它属于哪一类，再决定要不要把重活压在同一天。

先把三种周期形态分清楚

市面上的额度恢复规则，粗看五花八门，归拢起来其实就三种形态。

形态	恢复方式	能不能”攒”	撞上限之后	典型体感
总量池	每个计费周期给一整包，周期内自由分配	能攒，攒到周期末尾一起花	池子见底就要加购或等下个周期	前松后紧，月底容易慌
滚动刷新	按固定节奏（例如按日、按周）自动补回	攒不住，不用也不会累积	等下一个刷新点，通常不长	天天有饭吃，但吃不了大席
滚动时间窗口	看的是”过去一段时间内你用了多少”	不适用，窗口一直在往前滚	等最早那批用量滚出窗口	撞墙来得突然，恢复也是渐进的

三者的关键差别不在”给多少”，而在你能不能把额度在时间上重新分配。总量池允许你重新分配，滚动刷新不允许，滚动时间窗口连”重新分配”这个概念都不成立——它约束的是密度，不是总量。

有一家把这件事写得很明确：Devin 的定价页写明了用量额度会按日 / 按周自动刷新（页面原文用的是 “automatically refresh”）。这是本文覆盖的几家里，唯一一家把刷新节奏直接写进官方页面的。它属于典型的滚动刷新，而且是日、周两级同时存在。

Claude Code 走的是滚动时间窗口的路子，并且在更长的周期上还叠了一层限制。这两层各自的阈值以官方文档为准，本文不复述任何数值——具体的机制说明可以看站内已发布的两篇：Claude Code 额度限制怎么算和 Claude Code 的周限制是什么。

Cursor 的机制又是另一种形态：快速请求和慢速池分成两档，快的用完不是断供而是降速。这套降级逻辑在站内 Cursor 快速请求用完了怎么办里讲过，同样不在这里编造数字。

剩下几家，说实话没什么可讲的，因为官方没写：

Kiro：套餐档位和 credits 数量写得很清楚，但 credits 的刷新周期在官方页面上找不到，计费参考页返回 404。
Warp：定价页把各档含多少 credits 列得明明白白，可是刷新周期同样没写，文档站的请求限制页也是 404。
Antigravity：额度与限速在官网上完全没有写明，文档的 limits 页 404。

一笔可以自己复核的账：为什么”攒”这件事很重要

先做个换算，让”能不能攒”这件事变得具体。

Kiro 的 PRO 档是 $20/月，含 1,000 credits，超出部分按 $0.04/credit 计费。那么套餐内单价是 $20 ÷ 1000 = $0.02/credit，而超额单价 $0.04 正好是它的 2 倍。也就是说，你每多用 1 个 credit，成本翻倍。

再把这 1,000 credits 摊到一个 30 天的月份上：1000 ÷ 30 ≈ 33.3 credits/天。

现在关键来了：这条日均线是我算出来的，不是 Kiro 的规格。 官方没写刷新周期，所以我不知道你能不能在某一天把 300 credits 一口气用掉。

如果它是总量池，那 33.3 这个数只是个参考均值，你完全可以某天用 300、后面几天几乎不用，总账不超就行。
如果它是按日刷新的，那 33.3 就是一堵墙，用到就停，第二天再来。

同一个数字，在两种规则下的含义完全不同。这就是为什么”刷新周期”比”含多少额度”更值得你先搞清楚——它决定了你的额度是一笔可支配资金，还是一份定量口粮。

顺带一提，Warp 的 Build 档是 $20/月（年付 $18），含 1,500 credits；Max 档 $200/月（年付 $180），含 18,000 credits。年付相对月付便宜大约 10%（$20→$18、$200→$180、$50→$45 三组都自洽）。但和 Kiro 一样，这些 credits 多久回一次血，页面没说。

三种形态各自该怎么排任务

这一节是本文最有用的部分。规则不同，打法就得不同。

如果是总量池，你的优势是可以做资金式管理。

月初别放开手脚。前 10 天用掉一半以上，就该警觉了。
可以有意识地为月末留一笔。很多项目的交付压力天然集中在月底，而总量池是唯一允许你为此提前储备的形态。
大重构、批量迁移这类”一次吃掉很多”的任务，可以集中安排在池子还厚的时候做。
定期看余额比定期看账单重要。等收到超额账单再回头看，钱已经花了。

如果是滚动刷新，你的核心约束是攒不住，但恢复快。

必须把大任务拆成多天推进。 不是建议，是硬约束——你没有办法把周一没用的额度挪到周五用。比如”重构订单模块”这种活，可以拆成”周一梳理调用关系并产出改动清单""周二只改 service 层""周三改测试”，每天占用的额度都在当天上限之内。
好消息是容错高。某天冲得猛超了，第二天照样有额度，不会整月停摆。这一点比总量池友好得多——总量池一旦月中掏空，剩下半个月就只能加购或者干等。
反过来说，不用也是浪费。如果你连着几天没写代码，那几天的额度就凭空消失了。有闲工夫的时候顺手把技术债、注释、测试补一补，反而是划算的。
日、周双层同时存在时（Devin 就写明了这两层都有），要留意哪一层先到顶。这一点单独放到后面讲。

如果是滚动时间窗口，你要按小时和天来编排，而不是按月。

短时间内高密度提问是最容易撞墙的行为。连着几十轮”你再试试""还是不对”，比一次想清楚再问代价大得多。
撞上之后没有”加钱立刻恢复”这条路，只能等窗口往前滚。所以手边永远要留一件不依赖 Agent 也能推进的事：手写一段边界清晰的代码、读文档、写测试用例、整理需求。别把一整个下午的产出压在同一个额度池上。
恢复通常是渐进的，不是”到点全满”。最早那批用量先滚出去，你就先恢复一点余量。所以刚恢复时别立刻又开一个大任务，很容易二次撞墙。

如果是快慢双档（Cursor 那种降级模式），其实是最舒服的一类：快的用完了掉到慢的，工作不中断，只是变慢。这时候的策略是把”急”和”不急”分开——赶工的时段用快档，收尾整理、写注释、补文档这类不赶时间的活，扔给慢档慢慢跑就行。

deadline 前，不管哪种周期，提前几天都比通宵稳

这条结论对三种形态都成立，理由各不相同，但指向同一个动作。

滚动刷新下，通宵是最糟的选择：你熬到凌晨三点，额度早在晚上十点就见底了，剩下五个小时纯耗着。而如果你提前三天开始，每天都能拿到一份新额度，三天的总可用量远超一晚。攒不了额度，但可以攒进度。

总量池下，理论上你可以憋到最后一天集中花。但实际操作里这条路很脆：一旦当天池子见底，你要么临时加购（Kiro、Warp 都提供付费档的额外额度购买，Warp 还支持自动充值），要么就地卡死。加购能救急，可代价是超额单价通常高于套餐内单价——前面算过，Kiro 的超额价是套餐内的 2 倍。深夜、deadline 前、心态最紧张的时候，恰恰是最不适合做付费决策的时刻。

滚动时间窗口下更直接：它天生就是用来限制”短时间高密度使用”的，而通宵冲刺正是这种模式的教科书案例。你越急，越容易撞；撞了还没有加钱绕过的口子。

所以这条建议可以简化成一句话：把 Agent 当成一个每天产能有上限的同事，而不是一台你想榨多久就榨多久的机器。 你不会指望一个人在 deadline 前一晚干完三天的活，对额度也别抱这个幻想。

一个尴尬的现实：六家里只有一家写明了

把上面提到的几家摆一起，情况是这样的：

工具	刷新周期是否公开	依据
Devin	公开	定价页写明按日 / 按周自动刷新
Claude Code	机制公开	滚动时间窗口 + 更长周期的叠加限制，数值以官方文档为准
Cursor	机制公开	快速请求 / 慢速池双档降级
Kiro	未写明	计费参考页 404
Warp	未写明	请求限制文档页 404
Antigravity	未写明	额度与限速官网未写明，limits 页 404

这个结果说实话有点意外。定价页上”含多少 credits”个个写得清清楚楚——那是卖点，当然要写。但”这些 credits 多久回来一次”直接决定你的使用节奏，却常常留白，或者藏在一个已经 404 的文档页里。

我的态度很明确：没写就别猜。 网上能搜到不少”某某工具是每 5 小时刷新一次”之类的说法，来源大多是某个人在某个版本某个套餐下的观察。这类信息有参考价值，但把它当规格用是危险的——工具在快速迭代，计费策略改起来往往不发公告。你按一个过期的传闻排了一周的工作计划，撞墙的时候是没人赔你时间的。

所以本文对这几家只讲机制、不给数字。这不是偷懒，是我确实不知道，而且我知道自己不知道。

官方不写，你可以自己摸一个

规格查不到，不代表完全没辙。有个很土但有效的办法：连续记录余额，观察它什么时候往上跳。

具体做法：

固定时间点采样。 挑三个你本来就在电脑前的时刻，比如上午 9 点、下午 2 点、晚上 9 点，各记一次余额。工具里能看余额的地方一般都有（Amp 就把预付 credits 的余额放在用户设置里）。
顺手记下当天用了多少。 不需要精确，“今天跑了两个中等任务”这种粒度就够。关键是要能把”余额变化”和”我干了什么”对上。
连着记两三天。 一天不够——你分不清余额上升是刷新还是你自己少用了。三天基本能看出节奏：如果每天同一个钟点附近数值回升，那多半是按日刷新；如果只在某个固定日子回升，那更像按周；如果余额是在你停手之后慢慢爬回来的，那是时间窗口在往前滚。
写进你自己的笔记里。 官方无文档可查，所以这份记录就是你唯一的依据，别只存在脑子里。
务必标注这是观察不是规格。 我建议在笔记里明确写上”这是 2026 年 X 月在 Y 套餐下的观察结果，官方未公布，随时可能变”。半年后你自己回头看这条记录，会庆幸当时加了这句话。

这个方法有明显的局限：不同套餐、不同地区、不同时期的行为可能都不一样，你观察到的只是自己那一份。但它至少让你从”完全不知道”变成”大概心里有数”，而且这份数是你亲手测的，比网上来路不明的说法可靠。

别忘了：日额度和周额度可能同时卡着你

最后提醒一个容易踩的坑。当一家同时存在日、周两级刷新时（Devin 的定价页就写明了 usage allowance 按日 / 按周自动刷新），真正约束你的是先到顶的那一个。

举个场景。假设你周一到周三每天都用得挺猛，但每天都没撞日上限，你会觉得一切正常。到了周四，你明明当天才刚开工没多久，却突然被拦住了——不是日额度的问题，是这一周的累计量先到顶了。这时候你要等的不是明天，而是下一个周期起点，中间可能隔着好几天。

这个坑的隐蔽之处在于：日上限每天都在给你”还有余量”的正反馈，让你完全感知不到周维度的水位在涨。而周限制一旦触发，等待时间是日限制的好几倍。

应对方式也简单：记账时同时记日累计和周累计。周中过半的时候看一眼周累计花掉了多少，如果周三就用掉了大半，那周四周五就该主动降速——把 Agent 留给真正难的部分，简单改动自己动手。这比周四被硬拦下来强得多，至少降速是你自己选的，节奏还在你手里。

同理，如果你所在的工具是”周维度 + 更长周期”的叠加结构（Claude Code 那种），逻辑是一样的：永远盯着周期更长的那一层，因为它撞上之后恢复得最慢。

最后

把这篇的东西收成一张决策卡：

拿到新工具，先找刷新周期，再看含多少额度。前者决定打法，后者只决定上限。
找不到就承认找不到，用两三天的余额记录自己摸一个，并注明是观察不是规格。
总量池 → 当资金管，为月底留一笔，月中掏空最危险。
滚动刷新 → 当口粮吃，大任务必须拆成多天，某天超了不必慌，第二天就回血。
滚动时间窗口 → 当密度管，按小时排，手边永远备一件不依赖 Agent 的活。
快慢双档 → 急的走快档，收尾整理丢给慢档。
deadline 前，提前几天永远比最后一夜稳，三种形态都没有例外。

选工具的时候，也不妨把”官方有没有把刷新规则写清楚”当成一个参考维度。它不代表产品好坏，但确实反映了一家愿意让用户对成本和节奏有多少掌控感。一个把计费文档做成 404 的产品，你在排期上就得给自己多留一点余量——这不是偏见，是没有信息时该有的谨慎。

本文提到的所有价格与档位以各家官方定价页为准，未写明的刷新周期本文不做推测。这些策略在快速迭代的工具面前会过时，但”先搞清楚恢复规则，再决定怎么排任务”这个思路不会。