你一个月要烧多少额度？一套自己就能跑完的编程 Agent 用量估算法
挑编程 Agent 的时候，最难回答的问题不是”哪家模型强”，而是一个特别朴素的问题：我一个月到底要烧多少额度，$20 那档够不够？
你去翻定价页，能查到的全是供给侧的数字——这一档给你 1000 个 credits，那一档给你 1500 个。但没有一家会告诉你需求侧：一个 credit 能干什么。 是能改完一个函数，还是够跑一次全项目重构？定价页上没有，官方文档里往往也没有。于是”够不够用”这个问题，在别人那儿永远找不到答案，只能你自己测。
这篇文章给你一套五步测法。读完你能做到三件事：算出自己的日均消耗，把它换算成月成本，以及判断该留在当前档、补超额，还是干脆升一档。全程只需要你记两个数字、隔一天记一次。
为什么这个数没人能替你算
根子在于：Agent 的消耗量没法用”一次操作”来定义。
传统的按次计费好理解——发一次请求扣一次钱。但 Agent 不是这样工作的。你点一次”发送”，它可能自主跑三步，也可能跑十五步：先搜索项目里哪些文件相关，再逐个读进上下文，然后生成方案，再逐文件落改动，最后跑一遍自检看有没有把别处弄坏。这一串有多长，取决于你的需求有多含糊。
举个能直接对照的例子。同样一句”帮我重构一下”：
- 把范围圈死的人会说：“只改
order/service.ts里的createOrder，别动支付逻辑，也别碰测试文件。“Agent 的搜索范围收敛到一个文件，读取、改动、自检都是小闭环。 - 随口一说的人只丢下一句”这个订单模块写得太乱了，重构一下”。Agent 得自己判断”订单模块”包含哪些文件，一路搜下去可能牵出支付、库存、通知三条线，读了二十个文件才敢下笔。
这两种问法，消耗差三五倍是很正常的事。同一个人、同一个项目、同一家工具，消耗量能差这么多——那么任何”平均一个月用多少”的通用答案，对你都没有参考价值。
所以别再找别人的经验帖了。你要的是你自己那台机器上、你自己那种问法下的真实数字。
五步测法：一份可以照着做的清单
这是核心，写成清单是为了让你能直接照做。
第一步：记下当前剩余额度和日期。
打开工具的用量页，把剩余额度抄下来，连日期一起。别只记个大概，记精确值。像 Amp 这类支持预付 credits 的工具，余额就在用户设置里；不同工具的位置不同，但基本都在账户或用量面板里。
第二步：照常干一天活。
这一步的关键词是”照常”。别专门造测试任务——特意去跑一个大重构来”试试看能烧多少”，测出来的是你的好奇心，不是你的工作量。也别因为在测量就克制着少用，那会系统性低估。就当没这回事，该怎么干怎么干。
第三步：第二天同一时间再记一次，相减。
同一时间很重要，因为有些工具的额度是按周期自动刷新的——比如 Devin 的定价页就写明用量配额会按日 / 按周自动刷新。如果你跨过了刷新点，两次读数相减出来的就是个负数或者莫名其妙的小数。固定在每天同一个钟点记，能把这类干扰降到最低。
相减得到的就是日均消耗。如果你的工作日差异大（比如周一开会、周三写代码），测三天取平均更稳。
第四步：乘以你一个月真正会开这个工具的天数。
这一步最容易出错，单独拎出来讲：不要乘 30。 你一个月不会有 30 天在写代码。刨掉周末、会议日、出差、休假、以及那些一整天都在改 PPT 的日子，大多数人真正打开编程 Agent 的天数在 15 到 22 天之间。先老实数一遍你上个月的日历，再决定乘几。
第五步：拿月消耗对照档位表。
以 Kiro 的个人档为例（数据来自其定价页）：
| 档位 | 月价 | 含 credits | 超额单价 | 每美元含额度 |
|---|---|---|---|---|
| FREE | $0 | 50 | 页面未写明 | — |
| PRO | $20 | 1,000 | $0.04/credit | 50 |
| PRO+ | $40 | 2,000 | $0.04/credit | 50 |
| PRO MAX | $100 | 5,000 | $0.04/credit | 50 |
| POWER | $200 | 10,000 | $0.04/credit | 50 |
假设你测出日均 60 credits，一个月开 18 天，那么月消耗 = 60 × 18 = 1080 credits。对照上表，PRO 档含 1000，你超了 80。
三个最容易算错的地方
第一，用 30 天当工作日，会系统性高估。
还是上面那个日均 60 的人。按 30 天算是 1800 credits，按 18 天算是 1080。前者已经逼近 PRO+ 档的 2000，很可能让你直接掏 $40；后者只是刚过 PRO 档的线，补几美元超额就行。一个乘数选错，多花一倍的钱。
第二，忽略超额单价往往是套餐内单价的两倍。
拿 Kiro 算一遍：PRO 档 $20 买 1000 credits，套餐内单价 = 20 ÷ 1000 = $0.02/credit；而超额单价是 $0.04/credit。超额价正好是套餐价的 2 倍。
这意味着”就超一点点”的成本比你的直觉贵。前面那个超 80 credits 的人，要付 80 × $0.04 = $3.2，当月实付 $23.2。如果他不知道这是双倍价，心里按 $0.02 估，就会以为只要 $1.6。量小的时候差别不大，量一上来就很刺眼。
第三，忽略档位之间有没有批量折扣。
这一点各家差别很大，必须逐家看，不能默认”买得多就更划算”。
- Kiro：把上表最后一列扫一遍，PRO 到 POWER 的每美元含额度全是 50 credits。也就是说，从 $20 一路买到 $200，单价一分不省。往上升档只解决”额度够不够”，不解决”划不划算”。
- Warp：Build 档 $20 含 1,500 credits，每美元 75；Max 档 $200 含 18,000 credits，每美元 90。高档每美元多拿 20%（90 ÷ 75 = 1.2）。这家往上买是真的更便宜。Warp 还标了年付价：$20 → $18、$200 → $180，约 10% 折扣。
一家没折扣、一家有 20% 折扣，说明这事根本没有通行规律。你只能自己把”月价 ÷ 含额度”这一列算出来，然后横着比一遍。
算出来之后怎么办
三种情况，三条动作。
情况一：用量低于套餐的 70% → 考虑降一档。
Kiro PRO 档 1000 credits 的 70% 是 700。你连着两个月都在 700 以下，说明这一档买大了。不过降档前先看清楚下面还有没有档——Kiro 的 PRO 档往下就是含 50 credits 的免费档，中间没有过渡档位，降下去大概率不够用。Warp 的 Build 档往下也是免费档，而免费档具体给多少 credits，页面并没写明。“该降档”和”降得下去”是两件事，得看这家的档位梯度。
情况二：略微超出套餐 → 补超额可能比升档便宜。
关键是算出升档分界线：
升档分界线 =（下一档价 − 当前档价）÷ 超额单价
以 Kiro 从 $20 升到 $40 为例：(40 − 20) ÷ 0.04 = 500 credits。
含义很直白：超出量在 500 credits 以内，补超额比升档划算；超过 500，就该升档了。
验算一遍前面两种人：
| 你的情况 | 月消耗 | 超出量 | 留在 $20 档的总成本 | 升到 $40 档的总成本 | 该选 |
|---|---|---|---|---|---|
| 日均 60 × 18 天 | 1,080 | 80 | 20 + 80×0.04 = $23.2 | $40 | 留在 $20 档 |
| 日均 120 × 18 天 | 2,160 | 1,160 | 20 + 1160×0.04 = $66.4 | 40 + 160×0.04 = $46.4 | 升到 $40 档 |
第二行超出量 1,160 远大于分界线 500，所以升档；升完之后还超 160，补 $6.4 超额，总共 $46.4，比硬扛在 $20 档省了 20 块。分界线这个公式帮你把”该不该升”从感觉题变成了算术题。
情况三：超得很多 → 先别急着升，回头看看提问方式。
如果你的月消耗是套餐的三四倍，升档只是把账单抬高，问题没解决。回到第一节那个对照：把范围圈死能省下几倍消耗。先花一周时间练”把需求说清楚”，再重新测一遍日均，很多人这一步就把账单打回去了。
一个必须承认的事实：单次扣费规则，官方普遍不公开
写这篇的时候我逐家去翻了计费文档，结果是：多家工具的相关文档页当前返回 404。Kiro 的计费参考页打不开，Warp 的请求限制文档页打不开，Amp 的免费档页面打不开，Antigravity 的额度限制页也打不开。
这不是你没找到，是真的没有。
所以本文自始至终没有出现”一次代码补全扣几个 credit""跑一次重构大概多少”这类数字——因为没有官方来源，我不会编。 同样地，别信第三方的换算表。你在论坛或者某些评测里看到的”1 credit ≈ 一次中等复杂度请求”，除非它标了官方出处，否则大概率是作者自己的体感，而体感受提问方式影响能差三五倍（见第一节）。拿别人的体感去规划自己的预算，还不如老老实实测一天。
顺带说个反例：Augment Code 是个特殊情况，它的 BUSINESS 档 $100/月含 $100 使用额度，额度单位直接就是美元，涵盖 LLM、Context Engine 和计算。这种设计不用你去猜”一个 credit 值多少钱”，但你仍然不知道”一次操作花几美分”——换了单位，没换问题。同理，Amp 走的是订阅 + 超出后按实际用量计费，对个人和非企业工作区对供应商 API 定价零加成，账算得清，但一次操作烧多少，还是得你自己测。
如果你用的是 Cursor 或 Claude Code，机制又不一样：额度打完不一定是收钱，也可能是降速或者等刷新，对应的估算重点也不同，可以先看看 Cursor 快速请求用完了怎么办 和 Claude Code 的周限制怎么算 这两篇，把你那家的降级机制先搞清楚，再回来做用量估算。
最后
把这套方法压缩成一句话：记基线 → 照常干一天 → 相减得日均 → 乘真实工作日 → 对照档位表 → 用分界线公式决定补超额还是升档。
五步里最容易偷懒的是第二步（专门造任务测）和第四步（乘 30）。这两个地方走偏，后面算得再准也没用。
数字测出来之后，别用手算——四则运算不难，难的是超额、档位、分界线绕在一起容易绕晕。把你的日均消耗、每月工作天数、当前档位的月价和含额度、超额单价填进 编程 Agent 额度估算器，页面会直接给出你的月消耗、月总成本、用量占套餐的百分比，以及升档分界线在哪儿。填一遍不到一分钟，比在纸上列式子靠谱。