编程 Agent 额度告警怎么设？哪些家必须设、哪些家根本不用设
有人问「额度告警怎么设」的时候，心里想的往往是「我上个月账单比预期高，能不能提前知道」。但在动手翻设置页之前，有个更省事的问题要先回答：你用的这家，到底会不会让你超支？
这不是抬杠。市面上的编程 Agent 在「额度用完之后会发生什么」这件事上，走的是两条完全不同的路。一条路上，用完了就降速、就限流、就等下一个时间窗口——你被拖慢了，但账单纹丝不动。另一条路上，用完了自动续费、按需充值、按接口价现算——你没被打断，但钱在走。告警这件事的全部价值，只在第二条路上。 第一条路上的人花半天研究怎么设阈值，等于给一个不会漏水的水管装漏水报警器。
这篇讲三件事：怎么一眼分清自己在哪条路上；如果在第二条路上，水位该设几档、怎么算；以及一个很现实的问题——多数家官方根本没有告警功能，甚至连「在哪查剩余额度」的文档都找不到，这种情况下拿什么补位。
第一步：先分清哪些家需要告警
判断标准只有一条：额度用完之后，代价落在时间上还是落在钱上。
落在时间上的，典型是降级到慢速通道，或者等一个固定的时间窗口重置。这类机制天然有个特性——账单封顶。你可以疯狂用，但用得再多，这个月付的还是那么多，代价是排队变长、响应变慢。Cursor 走的就是快速请求用完之后降级到慢速池这一条路，具体机制站内另有一篇讲得比较细，可以看快速请求用完了怎么办。同理，靠时间窗口重置的（比如按周计算的限制，参考周限制那篇），也属于这一类。
这一类不需要告警。 你唯一需要的是「什么时候恢复」的心理预期，那是排期问题，不是财务问题。
落在钱上的，又分三种，风险从小到大：
| 超额机制 | 代表 | 钱怎么走 | 有没有天然刹车 | 要不要告警 |
|---|---|---|---|---|
| 降级 / 窗口重置 | Cursor 慢速池、按周窗口 | 不走 | 有（账单封顶） | 不需要 |
| 固定单价续费 | Kiro 超额 $0.04/credit | 按 credit 线性走 | 无，但能算准 | 要 |
| 按需充值 top-up | Augment 的 “Top-ups, pay as you go” | 充多少走多少 | 无 | 必须 |
| 按接口价计费 | Devin 超额按 API pricing | 随模型与实际 token 浮动 | 无，且算不准 | 必须，且要最紧 |
| 预付 credits | Amp（在用户设置里查余额） | 先付后用 | 有（余额归零） | 建议 |
最后一栏是这篇的结论：表格上半部分的人可以关掉这个页面了，下半部分的人往下看。
顺带说一句 Amp 的一个容易被忽略的细节：它的预付 credits 在账户不活跃满一年之后会过期。这不是超支风险，是另一种损失——你囤了额度、项目停了半年、回来发现没了。所以 Amp 用户的「告警」其实是两个方向：余额低了要知道，长期不用也要知道。
最需要警惕的组合：自动扣费 + 用量不可预测
如果只让我指一个最该设告警的场景，就是这个组合。
Warp 的付费档支持自动充值（auto-reload）：余额低于某个水位，系统自动帮你补上。这个功能本身是好意——它买的是「不被打断」。你在深夜赶一个重构，额度见底，Agent 不会突然停在半路让你去掏信用卡。
但请注意「自动」两个字的另一面：它不需要你点头。
编程 Agent 的用量为什么不可预测？举个具体的例子。你说「帮我把这个电商项目的订单模块重构一下」，Agent 会自己拆成搜索文件、读上下文、生成方案、逐个文件改、跑检查、发现不对再回头改——十几步甚至几十步，每一步都在花额度，而你只敲了一句话。再比如你写了个脚本让它批量处理一批文件，中间有个判断条件写错了，它可能对同一个文件反复调用几十次。这两种情况下，额度可能在你去倒杯咖啡的工夫里连续触发好几次自动充值，而你什么都没察觉。
所以开了自动充值的人，有三件事必须做：
- 去账单/订阅设置里确认有没有月度上限可设。 有的产品在自动充值之外还提供一个「本月最多充到多少」的封顶值，有就一定要设——这是唯一真正的硬刹车。没有的话，你就知道自己处在无保护状态，后面两条要执行得更认真。
- 把充值通知打开。 每次自动扣费都要有一封邮件或一条推送落到你眼前。这不是为了阻止扣费，是为了让「连续扣了三次」这件事在当天就被你看见，而不是月底看账单才知道。
- 每月核对一次账单。 不是看总额，是看扣费次数和时间点。连续几笔挨得很近的扣费，基本都对应着一个跑偏的任务，值得回头翻当天做了什么。
这三件事加起来花不了二十分钟，但它把「自动充值」从一个黑箱变成了一个可以被复盘的过程。
按需充值比 credits 制更需要盯
Augment 的超额机制是 “Top-ups, pay as you go”，额度单位直接就是美元。它跟 credits 制有个结构性差别，值得单独拿出来说。
credits 制哪怕没有告警，也有一个天然的信号：额度归零。归零那一刻，要么服务降级、要么系统提示你充值，总之你会知道。这个信号很粗糙，但它确实存在。
按需充值没有这个信号。它的设计目标就是让你感觉不到边界——用多少扣多少，可以一直续下去，没有一个位置会自动喊停。所以它把「知道自己用了多少」这件事，百分之百地推给了用户。
Devin 的超额按 API pricing 计费，是同一类问题的更极端版本：不但没有刹车，连预估都很难做准。成本随实际消耗的 token 和用的模型浮动，同样一句需求，Agent 拆成八步还是二十步、每步喂多少上下文，事前谁也说不清。所以这一类我的建议是：不要试图算准，改成设一个自己能接受的月度损失上限，按周核对，超了就当周收手。 承认算不准，比拿一个假精度的数字骗自己安全。
官方不给告警怎么办：用日历代替产品功能
这是这篇最实用的一节。
真实情况是：多数家连「在哪里查剩余额度」这件事，官方文档都查不到。 我们逐页核对时，Kiro 的计费参考页、Warp 的请求限制文档都是 404 状态；「什么算一次消耗」「额度多久刷新一次」这些最基本的问题，也普遍没有公开答案。既然连查询入口都语焉不详，那就更不要指望有一个成熟的阈值告警功能等着你配置。
所以，用一套手动流程补位。它土，但成本几乎为零：
- 固定每周同一时间记一次余额。 比如每周一上午上班先打开，把当前剩余额度记在一个表格里。关键是固定时间——不固定就会变成想起来才记，数据点一稀疏就失去意义。
- 算出周消耗。 上周余额减这周余额，就是这一周烧掉的量。第一次记完没有对比，从第二周开始才有数。
- 对照月预算判断进度是否超前。 一个月按四周算，正常节奏应该是每周烧掉月额度的四分之一左右。如果第二周就烧掉一半，说明进度超前，剩下两周得省着用。
- 超前就在当周调整用法。 注意是当周，不是等下周一再说——发现超前的时候通常还剩一半时间，这时候收手来得及；拖到第三周才反应，基本只能眼睁睁看着超额。
用日历提醒代替产品告警，是这套流程能跑起来的关键。设一个每周重复的提醒，标题就写「记额度余额」，两分钟的事。比起研究每家产品有没有隐藏的告警开关，这个方案的好处是通用——换一家产品，流程一个字都不用改。
水位设几档：50% 提醒，80% 决策
无论是产品自带的告警，还是上面那套手动流程，都要落到「到什么位置该有反应」上。我的建议是至少两档：
- 50% 提醒：月中还剩一半，这时候发现超前，你还有充分的调整余地——把大任务拆小、把上下文收窄、把能手写的部分手写掉。这一档不需要做决定，只需要知道。
- 80% 警戒：这一档必须做决定了。要么接下来省着用撑到月底，要么承认这个月的用量就是常态，准备升档。
80% 这一档怎么决定？有个可以直接算的判断依据——升档分界线：
分界线 =（下一档价 − 当前档价）÷ 超额单价
意思是：从当前档超额买多少个额度单位，花的钱正好等于升到下一档的差价。超过这个数还硬扛超额，就是在多花钱。
拿一组能算准的数字过一遍。Kiro 的 PRO 是 $20/月含 1,000 credits，PRO+ 是 $40/月含 2,000 credits，超额固定 $0.04/credit：
- 分界线 =（$40 − $20）÷ $0.04 = 500 credits
- 也就是说，PRO 档超出 500 credits 之后，你多付的超额费就已经够升到 PRO+ 了，而 PRO+ 直接给你多 1,000 credits
再算一个更扎心的比值：PRO 档 $20 买 1,000 credits，套餐内单价 $0.02/credit；超额单价 $0.04/credit——超额价正好是套餐价的 2 倍。这就是为什么「习惯性超额」几乎总是亏的：你在用双倍的价格买同样的东西。
把两档水位落到具体数字上，PRO 档就是：
| 水位 | 剩余 credits | 已用 | 该做什么 |
|---|---|---|---|
| 50% 提醒 | 500 | 500 | 记一笔，看看进度是不是超前 |
| 80% 警戒 | 200 | 800 | 判断月底前还会不会超 500，会就升档 |
需要说明的是：这套算法只在超额单价固定且公开的情况下成立。 按 API 价计费的那一类，分子分母都在浮动，算出来的分界线没有意义，具体价格以各家官方定价页为准。
团队场景要额外做的一件事
个人用户的额度是一本账，团队不是。团队的额度是几个人共用一个池子，或者按人头分配但汇总结算——不管哪种，你都会遇到同一个问题：这个月烧得多，是谁烧的？
说不清「谁烧的」，后面所有的动作都做不了。你没法针对性沟通，只能发一封「大家节约使用」的群邮件，然后下个月照旧。
所以团队要额外做的是用量归属：按人或者按项目建立记录，定期看消耗分布。方式可以很轻——如果产品后台本身能按成员看用量，直接看；如果不能，就退回上一节那套手动流程，只不过表格多几列，每人一列，或者每个项目一列。
看分布的时候，重点不是揪出用得最多的人。用得多完全可能是因为他啃的活儿最重。真正要找的是异常：某个人某一周的消耗突然是平时的好几倍，那多半对应一次跑偏的长任务或者一个失控的批处理脚本，把它复盘出来，全队都受益。这种沟通是技术性的，不是问责性的，团队更容易接受。
最后
回到开头那句话：额度告警不是每个人都需要做的事。先看你这家的超额代价落在时间上还是钱上——落在时间上的，账单天然封顶，把精力花在别处；落在钱上的，尤其是自动充值和按需充值这两类，告警是必需品而不是可选项。
而设水位的前提，是你得先知道自己一个月大概会用掉多少、以及升档分界线在哪。这两个数不算出来，50% 和 80% 就只是两个漂亮的百分号。
可以先用编程 Agent 额度估算器把月消耗和升档分界线算出来，再回头照着这篇设水位——顺序反了，设出来的告警多半会在错误的时间响，响几次之后你就开始无视它了，那还不如不设。