编程 Agent 的额度单位横比：credits、美元、请求、时间窗口有什么不同
想比较几个编程 Agent 哪个划算，多数人第一步就走错了：直接比月费。 都是 $20 一个月，看起来一样，但你买到的东西根本不是同一种货币——有的给你 1000 个点数，有的给你 $20 的用量额度，有的给你一批高优先级请求，有的给你一段时间窗口。
单位不同，就没法直接比。 这篇把当前主流的五种额度单位范式讲清楚，并给出一个把它们拉到同一口径的办法。搞懂之后，你再看任何一家的定价页，都知道该问什么问题。
一、五种额度单位范式
范式一：credits 点数制
代表：Kiro、Warp、Amp
厂商发明一个叫 credit 的抽象单位，你用钱买 credits，用 credits 换服务。
这是目前最常见的做法，好处是厂商可以给不同操作定不同价（一次简单补全和一次多步 Agent 任务显然不该同价），坏处是你必须先知道”一次操作扣几个 credit”才能估算够不够用——而这恰恰是各家披露得最不充分的地方。
举两个实际例子：
- Kiro：五档 credits 从 FREE 的 50 到 POWER 的 10000，超额 $0.04/credit。有意思的是，它的每美元 credits 完全一致（$20/1000、$40/2000、$100/5000、$200/10000，全是 50 credits/美元）——不给批量折扣。
- Warp：Build $20 含 1500（75 credits/美元），Max $200 含 18000（90 credits/美元）——给批量折扣，高档位每美元多 20%。
同样是 credits 制，这两家的档位逻辑完全相反：Kiro 是”买刚好够的那档”，Warp 是”用量大就往上买”。这就是为什么不能看到 credits 就以为都一样。
范式二：美元额度制
代表：Augment Code
不发明单位，额度就是钱。Augment 的 Business 档是 $100/月固定价，包含 $100 的使用额度，这个额度涵盖 LLM、Context Engine 和计算，超出后是 “Top-ups, pay as you go”。
这是五种范式里最透明的一种，因为它省掉了换算这一步：你不需要知道”一次操作扣几个 credit”，账户里扣的直接就是美元。你可以拿它去和 API 直调的成本做对比，口径天然一致。
代价是灵活性：厂商没法用点数杠杆去调节不同操作的相对价格。
范式三：请求优先级制
代表：Cursor
不按量断供，而是按优先级分档。Cursor 把请求分成快速请求（走优先通道，每月固定配额）和慢速池（配额用完后自动进入，功能不变但高峰期排队）。详见站内：Cursor 快速请求用完了怎么办。
这一档的本质是：额度控制的是速度，不是能不能用。 用完了你还能干活，只是慢。
这带来一个很实际的好处——账单天然封顶。对预算敏感的人来说，这个确定性比什么都值钱。
范式四：时间窗口制
代表：Claude Code
额度不是一个总量池子，而是一段时间内的用量上限：窗口内用超了就得等窗口滚过去，另有更长周期的限制叠加。站内有两篇专门讲：额度限制怎么算、周限制是什么，以官方文档为准。
这一档最关键的性质是：钱通常解决不了当下的问题。 撞到窗口上限，你只能等。这和 credits 制”加钱续着用”是完全相反的设计哲学。
好处同样是账单封顶，而且比请求优先级制更硬——它不是变慢，是暂时停。
范式五：刷新周期制
代表：Devin
Devin 定价页写明用量额度按日 / 按周自动刷新，超额可额外购买用量、按 API pricing 计费。（每档具体包含多少额度、单位叫什么，定价页未写明。）
按日刷新和”按月给一个总额度”是两种体验：你没法把额度攒到月底冲刺，但某天用超了，第二天就恢复，不会一整个月停摆。 对间歇性使用友好，对需要集中攻坚的人则要提前分摊安排。
二、一张对照表
| 范式 | 代表 | 用完之后 | 代价落在 | 账单可预期性 |
|---|---|---|---|---|
| credits 点数 | Kiro、Warp、Amp | 加钱买 | 钱 | 低（可能超支） |
| 美元额度 | Augment | 加钱买（top-up） | 钱 | 低，但换算最透明 |
| 请求优先级 | Cursor | 降级到慢速池 | 时间（变慢） | 高 |
| 时间窗口 | Claude Code | 等窗口重置 | 时间（暂停） | 高 |
| 刷新周期 | Devin | 按 API 价买 / 等刷新 | 钱或时间 | 中 |
读这张表的正确方式：右边两列才是你真正在选的东西。 你不是在选”哪家便宜”，而是在选”我愿意让代价落在钱上，还是落在时间上”。
- 有硬 deadline、线上要救火 → 选代价落在钱上的（credits 制、美元制）。变慢或停摆是不能接受的。
- 预算是硬约束、学生或自费 → 选代价落在时间上的（请求优先级、时间窗口）。账单封顶的确定性最值钱。
三、怎么把它们拉到同一口径
想真的比出个高下，你需要一个跨范式的公共单位。这个公共单位不是 credit，也不是美元，而是「你自己的一天」。
方法是这样的：
第一步，定义你的”标准工作日”。 不要用抽象的操作次数，就用你真实的一天：大概几次对话、几个 Agent 任务、任务平均多复杂。这个基线你心里其实有数。
第二步，在各家的免费档上，各跑一个标准工作日。 记下开始时的余额和日期，照常干一天活（别专门造测试任务——你要测的是真实用法），第二天再记一次，相减。
第三步，把结果统一换算成「一个标准工作日的成本」。
- credits 制：日均 credits × 该档的每 credit 单价。比如 Kiro PRO 是 $20/1000 = $0.02/credit，日均用 40 credits，就是 $0.8/天。
- 美元制：直接读数，不用换算。
- 请求优先级 / 时间窗口制：这两类算不出”每天多少钱”，因为账单是固定的。换个问法——「一天里我会不会撞上限？撞上之后损失多少时间？」 把那个等待时间乘以你自己的时薪，就是可比的代价。
第四步，用月成本对照各家档位。 日成本 × 你一个月真正开工具的天数（不是 30 天），得到月成本，再去看落在哪一档。
这套方法为什么必须自己跑一遍？ 因为消耗量的最大变量根本不是工具，而是你的提问方式。同样一句”帮我重构一下”，把范围圈死的人（「只改 order/service.ts 里的 createOrder，别动支付逻辑」）和随口一说的人，Agent 自主展开的步数能差好几倍。任何通用换算表都替代不了你自己的那一天。
四、看定价页时该问的三个问题
搞懂上面的范式之后，你再看任何一家的定价页，问这三个问题就够了：
问题一：这一档的每美元额度，和上下档一样吗？ 一样 = 没有批量折扣，买刚好够的那档（Kiro 是这样）。 更多 = 有批量折扣，用量大往上买划算（Warp 的 Max 档每美元多 20%）。 更少 = 你买的不是额度，是别的东西（Warp 的 Business 档每美元只有 Build 的 40%，多出来的钱买的是团队管理能力，判断值不值要看团队功能，不是算额度）。
问题二：额度用完之后，具体会发生什么？ 定价页上找 overage、top-up、pay-as-you-go、slow、limit 这类词。这是全篇最该弄清的一条——它决定了代价落在钱上还是时间上。
问题三：官方有没有写”一次操作扣多少”？ 写了就照着估。没写就别猜，也别信第三方的换算表——自己测一天。事实上多数家在这一项上披露都不充分，这不是你没找到，是确实没公开。
五、几条通用的省额度做法
不依赖任何厂商的具体单价，下面几条在五种范式下都成立，因为它们都指向同一件事：减少无效的模型调用。
把需求圈死再发。 Agent 自主展开的步数是消耗大头。提问前多花 20 秒写清”改哪个文件、哪个函数、不要动什么”，能省掉它自己搜索、试探、返工的一大串步骤。
别让它每次都重新摸项目结构。 把项目约定沉淀成一份长期文件（依赖怎么装、目录怎么分、测试怎么跑），放在你自己的仓库里而不是工具的云端设置里——既省额度，换工具时也能直接带走。
大任务拆开做。 一个跑歪的大任务浪费的是整串步骤；拆成几段，跑歪了只损失一段。
不满意时先想清楚再重发。 每次”再改改”都是一次新调用。连续追问三次慢慢逼近，不如停下来把要什么说清楚，一次到位。
本地几秒能干的别交给它。 改个变量名、调个格式、看一眼文件——自己动手比一次调用便宜。
最后
额度单位不统一，是这个赛道当前最大的比价障碍。 credits、美元、请求档位、时间窗口、刷新周期——五种范式各有各的道理，但它们让”哪家更划算”这个问题没法直接回答。
真正该拿来做决定的，是那两列：代价落在钱上，还是落在时间上。 赶工期选前者，守预算选后者。这个判断不需要任何换算表，也不会因为哪家调价而失效。
至于具体数字，本文引用的均为 2026 年 8 月 8 日各家官方定价页的展示内容，会随版本调整，以官方定价页为准。而官方没有公开的部分（比如多数家的单次操作扣费规则），我没有替你猜——花一天测出你自己的日均消耗，比任何表都准。