Amp 的「零加成」混合计费怎么算账？和 credits 制差在哪
如果你比较过几家编程 Agent 的计费方式，会发现绝大多数走的是同一条路：卖你一个月度套餐，套餐里塞一堆叫 credits 的东西，用完了按 credit 单价续。Amp（Sourcegraph 出品）走的是另一条路，它的手册里写着一句在这个赛道里挺少见的话——对个人与非企业工作区，采用供应商 API 定价的零加成（zero markup）。
这句话值得单独写一篇，因为它改变的不只是价格，而是你能不能算清自己的账。credits 制下你算不清；零加成下你算得清，但要接受另一种不确定性。
先说清这篇的边界：我拿不到 Amp 任何订阅档位的价格数字。它的免费档说明页在核对当天返回 404，手册本身也没有列出档位表。所以下面不会出现任何 Amp 的月费金额，需要具体价格请以官方定价页为准。我能核实到的是它的计费机制，而机制恰恰是这篇要讲的东西——搞懂机制，你拿到价格表的那一刻就知道该怎么读。
「零加成」到底在说什么
Amp 的计费是混合式的：一份月度订阅，覆盖 agent 与 orbs 的使用；订阅额度用超之后，转为按实际用量计费，计费基础是实际的 LLM 用量加上部分工具费用。
关键在超额那一段。「零加成」的意思是：你为模型调用付的钱，等于模型供应商 API 的原价，平台不在这上面抽一层。你调用某个模型烧掉多少 token、按供应商的官方单价折成多少钱，你就付多少钱。平台不在中间加价。
要理解这有多不一样，得先看看别家是怎么做的。credits 制的核心是：厂商发明一个私有单位（credit），你用钱买 credit，用 credit 换模型调用。问题是，1 个 credit 到底对应多少 token、对应哪个模型的多少次调用，这个兑换比例通常不公开。厂商可以自己定，也可以随时调。于是你手里只有两个数：这个月买了多少 credit、还剩多少 credit。中间那层「credit → 实际算力」的汇率，你看不见。
看不见汇率的直接后果是：你无法判断自己有没有被加价。不是说厂商一定加了，而是说这个问题在 credits 制下无法验证。零加成把这层遮挡拿掉了——计费基础直接暴露成「实际 LLM 用量 × 供应商官方单价」，这两个数你都能独立查到。
三种额度单位的对照
把本轮能核实到的几家放在一起，会看到额度单位其实分三类。下面这张表里 Amp 那一行没有价格，是因为确实抓不到，不是漏填。
| 家 | 额度单位 | 可核实的数字 | 你能不能自己算清成本 |
|---|---|---|---|
| Kiro（AWS） | credits（私有单位） | PRO $20/月含 1,000 credits，超额 $0.04/credit | 算得出「一个 credit 多少钱」，算不出「一个 credit 多少 token」 |
| Warp | credits（私有单位） | Build $20/月含 1,500 credits，年付 $18 | 同上 |
| Augment Code | 美元 | BUSINESS $100/月含 $100 使用额度，涵盖 LLM、Context Engine 与计算 | 单位就是钱，口径最直白 |
| Amp | 订阅 + 实际用量 | 价格页抓不到，以官方定价页为准 | 超额部分按供应商 API 原价，零加成 |
这张表里有一处算术值得自己复核一遍。Kiro PRO 是 $20 换 1,000 credits，折下来 $0.02 一个 credit；而它的超额单价是 $0.04 一个 credit——超额价正好是套餐内单价的 2 倍。这个结论对你的用法有直接影响：在 Kiro 上，与其长期挂着超额跑，不如直接升一档套餐。
再看 Warp Build：$20 换 1,500 credits，约 $0.0133 一个 credit，比 Kiro 的 $0.02 便宜约三分之一。但这个比较毫无意义——两家的 credit 是各自定义的私有单位，Warp 的一个 credit 和 Kiro 的一个 credit 换到的算力压根不是一回事。这恰恰是 credits 制最难受的地方：单价看起来可比，实际不可比。
Amp 的零加成绕开的正是这个坑。它的成本口径和你自己拿 API key 直调是同一套，你可以拿自己过去直调 API 的账单当基准，直接横向对照。这是目前几家里可比性最强的一种。
Augment 那一档也不难算：$100 月费含 $100 使用额度，名义上是 1:1，钱进钱出。它和 Amp 属于同一类思路的两种做法——都把「私有单位」这层去掉了。
零加成的另一面：省下的加成，换来浮动的账单
零加成不是白送的，得看清它的代价，否则采购时会算漏。
第一，平台的钱主要从订阅里赚。 既然模型成本这一段不加价，那平台的收入结构就压在订阅费上。这意味着订阅费本身可能不便宜，也意味着「订阅里含多少用量」这个数才是真正的性价比核心。我拿不到这个数，所以没法替你判断划不划算——这一步你必须自己去官方定价页看。
第二，也是更要命的一点：你的超额成本会随实际 token 消耗浮动。 credits 制虽然汇率不透明，但它给了你一个确定的超额单价（比如 Kiro 的 $0.04/credit），你至少能算出「再花 $50 能买多少 credit」。零加成不给你这个确定性——你的账单等于实际烧掉的 token 数乘以模型单价，而实际烧掉多少 token，在任务开始前是估不准的。
哪些东西会把这个数字推上去，是很具体的：
- 长上下文。 你把整个仓库的目录树、十几个文件的完整内容塞进去，输入 token 直接翻几倍。
- 多轮对话重发历史。 Agent 每一轮都要带上之前的全部对话去请求，一个持续二十轮的会话，前面那些内容会被反复计费。这一项经常是账单的大头，而且最容易被忽略，因为你感觉上「只是又问了一句」。
- Agent 自主展开的步数。 一个模糊的需求会让它自己拆成搜索、读取、生成、逐文件修改、自检十几步，每一步都是一次带完整上下文的请求。
所以零加成的正确心态是：它保证的是「单价公道」，不是「账单可预测」。想要账单可预测，得靠你自己控制用量。
第三，适用范围要看清楚。 手册写的是「个人与非企业工作区」零加成。企业工作区是不是同样零加成，我没有核实到——手册没写，我也不打算猜。如果你是替公司做采购，这一条必须直接问官方，不能拿个人档的说法往企业档上套。
顺带一提，Amp 支持购买预付 credits，余额在用户设置里能查到。这里有个容易踩的细节：未使用的预付 credits，在账户不活跃满一年后会过期。如果你是那种项目做完就搁置半年的用法，一次性充太多是有沉没风险的。
关联 ChatGPT 订阅换 GPT-5.6 用量
这条设计挺特别，值得单独说：Amp 支持关联你的 ChatGPT 订阅，以此换取更多的 GPT-5.6 用量。
为什么这条重要？因为它改变了「总成本」的算法。做工具选型时，大多数人算的是「工具 A 月费 + 工具 B 月费」，把每份订阅当成互相独立的一笔支出。而这条机制意味着你已经付过的钱可以复用——如果你本来就有 ChatGPT 订阅（很多做技术的人有），那这份订阅在 Amp 这边还能再换一次价值。
采购时具体该怎么做：
- 先盘手上已有的订阅，别只盯着新工具的月费。团队里如果本来就人手一份 ChatGPT 订阅，这笔钱在 Amp 场景下是可以二次利用的。
- 把这项折算进总成本再做横向比较。拿 Amp 的订阅费去和别家单纯比大小，容易得出偏高的结论，因为漏算了这一块。
- 关联的具体额度换算，手册里没有写，我也不编。想知道能多换多少 GPT-5.6 用量，得看官方最新说明。
这类跨订阅的复用条款，是选型时最容易被漏掉的一类信息，因为它不在价格表的主表格里。类似的情况在别家也有，比如学生身份能换到的优惠——参考 Kiro 学生免费额度是怎么回事。看定价页别只看那五个档位框。
实操：零加成模式下怎么把账单压下去
既然账单跟着实际 token 走，那省钱的手段就全落在「怎么少烧 token」上。这几条按见效顺序排：
一、把需求圈死，减少 Agent 自主展开的步数。 这是效果最明显的一条。
对比一下同一件事的两种说法：
- 「帮我把这个电商项目的订单模块重构一下」——它会先搜索整个仓库找相关文件，读进来十几个文件，然后规划改动方案，逐个文件生成修改，再跑一遍自检。十几步请求，每步都带着膨胀的上下文。
- 「只改
order/service.ts里的createOrder函数，把参数校验抽成独立函数，别动支付相关逻辑」——它读一个文件，改一处，结束。
后者的 token 消耗可能只有前者的零头，而对于你已经想清楚该怎么改的场景，产出质量往往还更好，因为它没有机会自作主张。
二、控制上下文长度，别把整个仓库当输入。 明确指出该看哪几个文件，比让它自己去找便宜得多。你心里清楚问题在哪的时候，直接点名。
三、大任务拆段，每段单开会话。 这条是专门对付「多轮重发历史」的。一个跑了三十轮的会话，后半程每一次请求都在为前半程的内容重复付费。做完一个阶段就把结论落到文件或笔记里，然后新开一个会话继续——上下文从头开始，账单也从头开始。
四、本地能干的别交给它。 全局重命名用 IDE 的 rename 功能，批量替换用编辑器的正则替换，格式化交给 formatter，跑测试自己敲命令。这些确定性任务扔给 Agent，是拿浮动计费的资源去做零成本的事。
五、简单任务用便宜模型。 这一条在零加成下比在 credits 制下更划算，值得单独强调：零加成意味着你换用便宜模型省下的钱，是原封不动落到你账单上的。而在 credits 制下，不同模型消耗多少 credit 由厂商定义的兑换比例决定，你换到便宜模型未必能等比例省下 credit——省下的部分可能被汇率抹平了。这是零加成一个很实在的好处：省的钱是真省的。
如果你现在用的是快慢分档那类工具，控成本的思路会不太一样——那边的代价落在时间上而不是钱上，做法可以对照 Cursor 快速请求用完了怎么办。而按实际用量计费的工具，思路更接近 Codex 的用量与计费：省钱等于省 token，没有第二条路。
最后
Amp 的零加成，本质上是把「我到底为算力付了多少钱」这个问题的答案还给了用户。credits 制不是必然贵，但它的汇率不透明，你没有办法验证自己有没有被加价；零加成把计费基础对齐到供应商官方定价，你可以拿自己直调 API 的账单去核。这是这个模式最扎实的价值。
代价也很清楚：账单跟着实际 token 浮动，估不准；平台的收入压在订阅上，所以订阅本身值不值，得看具体价格和含量——而这两个数我确实没抓到，Amp 的免费档说明页当天返回 404，手册也没列档位表。这篇不给你一个编出来的价格，比给一个看着精确其实是猜的数字要有用得多。
决策路径可以这么走：你已经有直调 API 的成本基准、并且看重成本可核算，零加成这套对你的可比性最强；你更需要月度支出可预测、能接受汇率不透明，那固定超额单价的 credits 制心理负担更小；你本来就有 ChatGPT 订阅，那 Amp 这条关联换用量的路子要单独算进总账，别漏。最后不管选哪家，控成本的功夫都落在同一处——把需求说清楚，把上下文压住。这件事在任何计费模式下都成立。