编程 Agent 套餐性价比怎么算？月费最低的档常常不是花钱最少的档
选编程 Agent 的套餐，绝大多数人的第一反应是看那一列月费，挑一个自己心理价位能接受的。这个动作本身没错，错的是到这里就停了。月费只是账单的上半截，下半截是超额费用——你这个月用超了多少、超出的部分按什么价补，才决定最后信用卡上扣掉多少钱。
这篇文章想做的事很具体：给你一个能自己动笔算的成本公式，算出「什么时候该升档、什么时候留在低档补超额更划算」的分界点；再给你三条判断维度，让你在打开任何一家定价页时知道该盯哪几个数。读完你应该能做到——看着一张陌生的套餐表，五分钟内说出「按我的用量，这家我应该买哪档，一个月大概花多少」。
先说结论：真实成本 = 档位月费 + 超出部分的超额费用。这个式子看着简单到不值一提，但只要超额单价存在，它就会推翻很多人凭直觉做的选择。
一个能算清的例子：月费低的那档反而多花 12 美元
用一组真实存在的档位来算。以 Kiro 的个人套餐为例，它的档位是这样的（数据来自 kiro.dev 定价页，核对日 2026-08-08）：
| 档位 | 月价 | 含 credits | 超额单价 |
|---|---|---|---|
| KIRO FREE | $0 | 50 | 页面未写明 |
| KIRO PRO | $20 | 1,000 | $0.04/credit |
| KIRO PRO+ | $40 | 2,000 | $0.04/credit |
| KIRO PRO MAX | $100 | 5,000 | $0.04/credit |
| KIRO POWER | $200 | 10,000 | $0.04/credit |
现在假设你这个月要消耗 1800 个单位，手上纠结的是 $20 档和 $40 档。
留在 $20 档：套餐内含 1000，超出 800 个，超额费用 800 × $0.04 = $32，加上月费 $20，一共 $52。
升到 $40 档：套餐内含 2000，1800 没超，超额费用 $0，一共 $40。
月费高一倍的档，实际支出反而少 $12。这就是「只比月费必然选错」最直白的样子。
但也别急着得出「无脑升档」的结论。把用量换成 1200 再算一遍：
留在 $20 档：超出 200 个，200 × $0.04 = $8，加月费共 $28。
升到 $40 档：仍然是 $40。
这一次留在低档省了 $12。同样两个档、同样的超额单价，用量差 600，结论直接反过来。
那分界点在哪？让两边相等就行。设超出 $20 档的量为 x：
$20 + 0.04x = $40 → 0.04x = 20 → x = 500
也就是说，每个月稳定超出 500 个单位以上就该升档，稳定低于 500 就留在低档补超额。换算成总消耗量，分界线落在 1500：低于 1500 留 $20 档，高于 1500 升 $40 档，正好 1500 时两边都是 $40，随便选。
这里有个容易被忽略的细节：分界点只跟「月费差」和「超额单价」有关，跟你用了多少无关。$40 到 $100 那一档同理——差价 $60，除以 $0.04，分界点是超出 1500 个单位。你可以把这条规律记成一句话：多出来的月费能买多少超额单位，就是升档的门槛。
还要提醒一句，这个算法建立在「用量稳定」的前提上。如果你的用量是这个月 800、下个月 2500 来回跳，那就不能只看平均值，得看波动带来的成本方差——极端月份的超额账单可能比你预期的高得多。真要保守，就按你近三个月的最高值去算升档分界，把账单的最坏值先钉死。
先看这家有没有批量折扣，它决定你的整个选档策略
算清单个分界点之后，还有一个更上层的问题：这家的大档到底值不值得往上买？
判断方法很简单，把每个档换算成「每美元能买到多少额度」，也就是含量除以月费。这一个动作能把定价页的真实意图暴露出来。
情况一：没有批量折扣。 还是上面那张 Kiro 表，我们逐档算：
| 档位 | 月价 | 含 credits | 每美元买到 |
|---|---|---|---|
| KIRO PRO | $20 | 1,000 | 50 |
| KIRO PRO+ | $40 | 2,000 | 50 |
| KIRO PRO MAX | $100 | 5,000 | 50 |
| KIRO POWER | $200 | 10,000 | 50 |
四个档，每美元都是 50 个单位，一分不差。这意味着**「买大档更划算」在这里是个错觉**——大档不便宜，只是把更多量打包进了月费里。它的价值不是省钱，是省心：额度够用就不用管超额账单。
对这类定价，正确的做法是买刚好覆盖你用量的那一档，多一分都是提前付出去的沉没成本。你消耗 2200，买 $40 档（$40 + 200×0.04 = $48）比买 $100 档划算一大截。
情况二：有真实的批量折扣。 换 Warp 的档位看（数据来自 warp.dev/pricing，核对日 2026-08-08）：
| 档位 | 月付价 | 年付价 | 含 credits | 月付每美元买到 |
|---|---|---|---|---|
| Build | $20 | $18 | 1,500 | 75 |
| Max | $200 | $180 | 18,000 | 90 |
| Business | $50/用户 | $45/用户 | 1,500/人 | 30 |
Build 档是 1500 ÷ 20 = 75 个单位每美元，Max 档是 18000 ÷ 200 = 90 个单位每美元，高档比低档多给 20%（90 ÷ 75 = 1.2）。反过来验算更直观：如果按 Build 档的单价去买 18000 个单位，需要 18000 ÷ 75 = $240，而 Max 档只要 $200，实打实省了 $40。
这种结构下，「用量大就往上买」不是错觉，是真便宜。年付还能再叠一层：Warp 页面标注年付约 10% 折扣（$20→$18、$200→$180、$50→$45 三个数字互相自洽），$180 买 18000 就是 100 个单位每美元了。
情况三：某一档的每美元额度明显更少。 注意上表里的 Business 档——$50 每用户只含 1500，换算下来 30 个单位每美元，只有个人 Build 档（75）的 40%。
第一反应可能是「这档太坑」，但这个判断下得太快了。同样是 1500 个单位，多收的 $30 显然不是在卖额度，而是在卖团队管理能力：席位管理、统一计费、权限控制这类东西。Warp 的 Business 档还写明最多 25 个席位，这本身就说明它面向的是有明确规模边界的团队场景。
所以对这种档位，判断值不值的标准不是算额度，是看功能。你需要给八个人统一开通、统一报销、集中管账，那这 $30 就有意义；你只是自己一个人想多要点额度，那它确实不合算，你该买的是个人高档。这个思路在别家也通用——GitHub Copilot 的多档结构里，企业档和个人档的差别同样主要在管理侧而不在额度侧，我们在 GitHub Copilot 五档套餐怎么选 里拆过那张表。
有些档位压根没法比价，这时候要诚实承认
上面两节的算法有个隐含前提：你知道每档含多少额度。可现实是，相当一部分厂商的定价页只写价格，不写含量。
Devin 就是典型（数据来自 devin.ai/pricing，核对日 2026-08-08）：
| 档位 | 价格 | 页面写明的额度 |
|---|---|---|
| Free | $0/月 | 未写明数量，标注 “Limited model availability” |
| Pro | $20/月 | 未写明数量 |
| Max | $200/月 | 未写明数量 |
| Teams | $80/月 + $40/月/座位 | 未写明数量 |
| Enterprise | 需洽谈 | 未写明 |
价格清清楚楚，含量一个都没有。这种情况下「每美元买到多少额度」这一列算不出来——不是难算，是缺分子。
这里我要说一句可能不太讨喜的话：遇到这种档位，正确的做法是承认「这一档没法比」，而不是找个第三方换算表填进去。网上不难找到各种「换算参考」，但那些数字要么来自某个用户的个人体感，要么来自早就改过的旧版定价，把它当成事实填进你的成本模型，算出来的是一个看着很精确的错误答案——比不算更危险，因为你会照着它做决定。
同样的道理适用于额度单位本身。Devin 页面提到的 ACU 之类的计量单位，官方文档里我没找到明确的定义与换算说明，那我就不写它等于多少——写了就是编。
那这类产品到底怎么选？先在免费档或最低档试用，用真实项目跑一到两周，摸清自己的实际消耗节奏，再决定要不要往上买。 花 $20 买一个月的信息，比对着一张没有含量的表格空想两小时靠谱得多。顺带一提，Windsurf 的定价入口现在已经 308 永久重定向到 Devin 的定价页（2026-08-08 亲测），所以如果你原本在比这两家，实际上现在只有一张表要看。
超额不是固定单价的情况，怎么给自己一个成本上限
还有一类更麻烦的定价：超额不按固定单价，而是「按 API pricing 计费」。
Devin 的 Pro 档就是这样，页面原文写的是超出部分可以额外购买用量，按 API 定价消耗。Amp 走的也是类似路子——月度订阅包含基础用量，超出后按实际 LLM 用量计费，而且明确写了对个人与非企业工作区零加成（zero markup），也就是供应商 API 是什么价它就是什么价，不加价。Augment 则是另一种变体：BUSINESS 档 $100 每月，含 $100 的使用额度，额度单位直接就是美元，涵盖 LLM、Context Engine 与计算，超出后按需充值。
这三家的共同点是：超额成本没法用一个固定数字代表。同样是「超出 1000 次调用」，你用轻量模型跑短上下文，和用重型模型跑几万 token 的长上下文，账单可能差出好几倍。任何声称能给你一个准确超额单价的说法，都跳过了「你到底会用哪个模型、上下文多长」这两个变量。
那要不要因此就放弃估算？不用。做法是按你估计的上限填一个保守值，得到的不是真实成本，是成本上限。 比如你判断自己最贵的场景是每个单位 $0.06，那就用 $0.06 去算，算出来的数字如果你能接受，实际账单只会更低；如果连这个上限都超预算，那这个方案就直接排除了，也省得再纠结。
预算这件事上，知道最坏情况比知道平均情况有用得多。平均值让你安心，最坏值让你不至于在月底被账单吓一跳。
顺便说一句 Amp 的一个小细节：它支持购买预付 credits，而未使用的 credits 在账户不活跃满一年后过期。这类条款在算性价比时容易被忽略——如果你是间歇性使用，预付大额度看着单价划算，实际可能有一部分永远用不掉。
比价之外，还得看额度用完之后会怎样
最后这一条不参与算术，但在实际使用中的分量可能比前面所有计算加起来都重。
额度用完之后会发生什么？ 大致三种走向：
| 走向 | 代价落在哪 | 典型体感 |
|---|---|---|
| 加钱续（超额计费 / 充值） | 钱 | 工作不中断，月底账单变厚 |
| 降速用（切到低优先级通道） | 时间 | 不用掏钱，但每次响应都要多等 |
| 等窗口重置 | 时间，且不可控 | 直接停工，等到刷新那一刻 |
这三种差别的本质，是代价落在钱上还是时间上。
Cursor 走的是第二条路——快速请求用完之后会降级到慢速通道，不额外收费，但响应变慢，这个机制我们在 Cursor 快速请求用完了怎么办 里详细拆过。Kiro、Warp 这类有明确超额单价的走的是第一条路，掏钱就能继续。Devin 页面则写明用量额度按日、按周自动刷新，这意味着即使撞上限，等待周期也是可预期的短周期，不是熬一整个月。
为什么说这条比省钱重要？想象一个具体场景：周四晚上，明天要交付，你正在让 Agent 批量改十几个文件的接口签名，改到第七个的时候额度撞顶了。
如果这家是「加钱续」，你点两下充值，五分钟后继续，代价是几十美元。如果是「降速用」，你能继续，但原本二十分钟能干完的活拖到一个半小时，交付时间往后推。如果是「等窗口重置」，你就只能停在这里——而重置可能在明天早上，也可能在下周一。
在赶工期的时候，几十美元和「今晚能不能干完」根本不在一个量级上。 所以我的建议是：如果你的工作有明确的交付窗口，选档时优先选「代价能落在钱上」的机制，哪怕它的每美元额度算下来不是最优的。反过来，如果你是自己学习、做副业项目、时间弹性很大，那降速甚至等待都完全可以接受，这时候把每一分钱的额度榨干才是对的。
顺带一提，如果你在意「撞上限之后要等多久」这件事，不同产品的限制周期设计差别很大，从按日刷新到按周刷新都有，Claude Code 的周限制 是另一种典型结构，值得单独了解一下。
最后：把各档抄进对比器，让它替你算
回顾一下这篇的四个动作：
- 用「月费 + 超额费用」算真实成本，别只看月费那一列；
- 用「多出来的月费 ÷ 超额单价」算升档分界点，按你的用量对号入座；
- 把每档换算成「每美元买到多少额度」，判断这家有没有真的批量折扣；
- 遇到不写含量的档位，承认没法比，去试用而不是去猜。
这四步都不难，但手工算四五个档、再横向比三四家，很容易在中间某一步算串行。我们把这套算法做成了 套餐性价比对比器——你把各档的月费、含量、超额单价照着定价页抄进去，填上你的月消耗，页面会直接给出每一档的真实总成本并从低到高排序，同时把「每美元买到多少额度」这一列算出来，告诉你这家到底有没有批量折扣。改一个用量数字就能看到排序怎么变，比在纸上重算快得多。
有一件事对比器帮不了你：它不知道你的真实月消耗是多少。这个数只能从你自己的账单历史里来，或者从一段认真的试用里来。先把这个数摸准，再谈选哪档——顺序反了，算得再精也是精确的错误。