Amp vs Claude Code 怎么选？成本透明度和账单可预期性的取舍
选 Amp 还是 Claude Code，表面上是选工具，实际上是在选你愿意接受哪一种痛苦。
Amp（Sourcegraph 出的那个）的记账方式是：月度订阅包含 agent 与 orbs 的使用，超出之后按实际用量计费，计费基础是实际的 LLM 用量加上部分工具费用。而且它在手册里写明了一件很少有厂商愿意写的事——对个人和非企业工作区，供应商 API 定价零加成（zero markup）。Claude Code 是另一套：滚动时间窗口的限额，再叠加一层更长周期的限制，撞上了就只能等窗口滑过去。
这两句话摆在一起，差异就出来了：一个让你看清每分钱花在哪，一个让你不必看。读完这篇你应该能做到的是——判断自己的用法属于哪一类，以及别在采购时被”看起来更便宜”骗过去。
先说一句必须说清楚的：本文不会出现 Amp 的任何月费金额。我手上核到的资料里没有 Amp 各档订阅的价格数字，那我就不写，因为写了就是编。价格请以 Amp 官方定价页为准。Claude Code 那边同理，具体的窗口时长和额度数值以官方文档为准，站内已经有两篇专门写过它的机制：Claude Code 额度限制 和 Claude Code 周限制。
零加成 vs 订阅封顶：两种完全不同的记账方式
“零加成”这个词听起来像营销话术，但它的实际含义很硬：你为模型付的钱，等于供应商 API 的原价。中间那一层没有抽成。
这件事的价值不在”便宜多少”，而在口径可比。你自己直接调供应商 API 跑一遍同样的任务，花的钱和通过 Amp 跑是同一个量级、同一套单价。这意味着两件事变得可能：第一，你可以拿自建脚本的成本来给 Amp 的账单做交叉验证，账单异常你能看出来；第二，你评估”要不要自己搭一套”的时候，省下的不是模型钱，只是那套 agent 编排的价值——这个判断题一下子就清晰了。
给一个可以自己复算的例子说明”加成”意味着什么。以下这组数字是我为了说明口径随手设的示例，不是 Amp、也不是任何供应商的报价：假设某模型的输入价是每百万 token 3 美元，你这个月的 agent 会话累计吃掉 40 百万输入 token，那么零加成下这部分就是 40 × 3 = 120 美元；如果换成一个抽 20% 通道费的平台，同样的活儿要付 120 × 1.2 = 144 美元，差 24 美元。用量翻十倍，差距就是 240 美元。加成是按比例走的，用得越狠差得越多——这也是为什么重度用户比轻度用户更在意这一条。
代价也很实在。超额部分随实际 token 浮动，而 agent 的 token 消耗恰恰是最难预估的那种。同一个需求，“帮我把订单模块重构一下”会让 agent 自己拆成搜索、读文件、生成方案、逐文件改、跑自检十几步，每一步都把越来越长的上下文重新发一遍；而”只改 order/service.ts 里的 createOrder，别动支付逻辑”就收敛得多。长上下文和多轮重发是两个放大器，叠在一起，月底账单能和你月初的心理预期差出一个数量级。你没法提前算准，这是零加成模式无法回避的结构性问题。
Claude Code 走的是反方向。订阅制的核心价值是账单封顶：你不需要在每次让它改代码之前心算一下这一轮值不值。缺点也同样干脆——额度是滚动窗口的，撞上了加钱也不一定能立刻解决，很多时候就是等。等待的成本不体现在账单上，体现在你下午三点卡住、晚上八点才能继续这件事上。
| 维度 | Amp | Claude Code |
|---|---|---|
| 计费结构 | 混合：月订阅含 agent 与 orbs 使用，超出后按实际用量计费 | 订阅制，滚动时间窗口限额 + 更长周期限制叠加 |
| 计费基础 | 实际 LLM 用量 + 部分工具费用 | 以官方文档为准 |
| 加成 | 个人与非企业工作区对供应商 API 定价零加成 | 不适用（不按 API 用量对用户计费） |
| 月账单可预期性 | 低，超额随实际 token 浮动 | 高，订阅封顶 |
| 成本归因粒度 | 细，能看到钱花在哪 | 粗，不需要看 |
| 撞上限的表现 | 转为按用量付费，继续跑 | 只能等窗口滑过 |
| 代价落在 | 钱上 | 时间上 |
| 预付 | 支持预付 credits，用户设置里查余额 | 以官方文档为准 |
| 形态 | 多编辑器插件 | 终端 CLI |
有一个范围问题必须点出来，别读错了：零加成的表述覆盖的是个人和非企业工作区。企业工作区是不是同样零加成，我核到的资料里没写。没写就是没写，我不替它推断。如果你是代表公司做采购，这一条请直接找官方问清楚，别拿本文当依据。
预付 credits「不活跃满一年过期」：先看清触发条件
Amp 支持买预付 credits，余额在用户设置里能查到。规则里有一条容易被误读的：未使用的 credits 在账户不活跃满一年后过期。
我见过不少人看到”一年过期”就下意识理解成”买了一年后作废”，然后决定只买最小额度。这两件事差得很远。触发条件是账户不活跃满一年，不是购买满一年。也就是说，只要你在正常用这个账户，余额并不会因为”买得早”而蒸发；真正会触发的场景是你彻底停用了——换了工具、项目结束、人离职了账号没人接手，然后一整年没动静。
所以正确的担心对象不是”我买多了会不会到期”，而是”这个账号会不会有人一整年不碰”。团队里那种为某个短期项目临时开的账户，才是真正的高风险位置：项目三个月做完，账号放着，一年后余额没了。
那预付多少合适？给一个可以自己算的口径：过期时钟是 12 个月，用你未来 3 到 6 个月可见的用量作为预付上限，也就是把敞口压在过期周期的 1/4 到 1/2 之间。这个区间的逻辑是——即便出现最糟糕的情况（你下个月就不用了、账号从此闲置），你压在里面的钱也只是三到六个月的量，而不是一整年的量。至于”3 到 6 个月是多少钱”，这取决于你自己的用量，我给不了数，也不该给。做法是先按小额跑满一个真实的月份，拿到一个真实的月均值，再乘 3 到 6。
顺带说一句：这条规则本身其实比”到期即作废”友好得多。愿意把这种细则写进手册的产品，通常在别的地方也不太会玩花活——这算是一个正面信号，虽然不构成选型理由。
关联 ChatGPT 订阅换 GPT-5.6 用量：算总成本时别漏了
Amp 支持关联你已有的 ChatGPT 订阅，换取更多的 GPT-5.6 用量。
这条容易被当成一个无关紧要的小功能，但它会实打实地改变你的采购算式。如果你（或者你团队里的人）本来就在为 ChatGPT 付订阅费，那这笔钱在 Amp 这里能产生第二次价值；反过来，如果你是为了这个用量才去订 ChatGPT，那这笔订阅费就必须计入 Amp 的总持有成本，不能只看 Amp 那一侧的账单。
我建议采购时用一张最朴素的表把三块加起来：Amp 订阅 + 预期超额用量 + 为换用量而付的外部订阅。三项都填完再和另一个方案比。只比其中一项——尤其是只比订阅月费——是最常见的采购错误，而且几乎必然导向错误结论，因为 Amp 恰恰是那种”订阅只是入场费、真实成本在用量里”的产品。
还有一个隐含前提值得留意：这个机制把你和一个外部账号绑在了一起。团队场景下，那个 ChatGPT 订阅归谁、离职怎么交接、公司报销走哪条线，都是要先想清楚的事，不然会变成一笔说不清归属的费用。
形态差异：多编辑器 vs 终端 CLI
这一层的差异比计费更早决定你能不能用得下去。
Amp 的覆盖面很广：VS Code 系（包括 Cursor 和 Windsurf）、Neovim、Zed，以及 JetBrains。但 JetBrains 那一条有个必须说清的状态——已废弃，仍可用，但不再更新。
“仍可用”和”值得押注”是两回事。对个人开发者，还能跑就先跑着，哪天不行了换个编辑器就是；对一个主力用 IntelliJ、PyCharm、GoLand 的团队，这是一条要写进风险栏的信息。不再更新意味着：IDE 大版本升级之后的兼容性没人保证，新功能不会同步过来，出了问题的修复优先级你心里应该有数。如果你的团队短期内不可能离开 JetBrains，那么把 Amp 定为主力工具这件事，你至少得准备一个”哪天插件不能用了怎么办”的答案。
Claude Code 是终端 CLI，路径完全不同。好处是编辑器无关——JetBrains、Vim、Emacs、随便什么，只要你有终端就能用，也不存在”某个 IDE 插件被废弃”这类风险，同样一套用法还能直接搬到服务器和 CI 环境里。代价是它不在你的编辑器里，diff 审查、跳转、改完直接看引用这些事都得切窗口，习惯 IDE 内联体验的人前几天会觉得别扭。
一句话概括：Amp 是”来你的编辑器里”，Claude Code 是”你去终端找它”。这不是优劣，是工作习惯的匹配问题，而且是最容易被低估的那个匹配问题。
按场景怎么选
场景一：你要给”AI 到底花了多少钱”做成本归因。 选 Amp。零加成让账单口径和直调 API 一致，你能把成本拆到项目、拆到人、拆到具体任务类型，还能拿自建脚本的花费做交叉验证。Claude Code 的订阅制在这件事上给不了粒度——它本来就不是按这个口径设计的。
场景二：你的预算必须先批后花，超支要走审批。 选 Claude Code。订阅封顶意味着报预算就是报订阅费，没有月底突然多出一笔的可能。Amp 的超额随实际 token 浮动，长上下文和多轮重发会推高账单，在”先批后花”的流程里这是硬伤——你没法提前给出一个准数。
场景三：你的团队主力是 JetBrains 系 IDE。 优先考虑 Claude Code，或者至少不要把 Amp 的 JetBrains 插件当成长期方案。理由上面说过：那条插件已废弃、不再更新。如果团队坚持要用 Amp，务实的做法是让大家在 VS Code 系里用它，JetBrains 继续做主力开发环境，两者并存。
场景四：你的用量波动极大，有的月份几乎不碰、有的月份连轴转。 这种情况倾向 Amp。按实际用量计费对”闲月”是友好的，闲月不产生超额；而订阅制在闲月是纯浪费。反过来，如果你的用量高且稳定——每天固定几小时的重度使用——订阅封顶的性价比会更容易算得清，也更省心。
场景五：你就是不想管这件事。 选 Claude Code。这不是敷衍，是真实存在且完全合理的诉求。成本透明度是有维护成本的：你得定期看账单、得分析异常、得教会团队怎么控上下文。如果这些事没人愿意做，那么透明度带来的信息就变成了没人读的报表，你付出了不可预期性，却没换到任何东西。
决策路径
按顺序问自己四个问题，第一个答”是”的就停：
- 你的预算流程要求月度支出可预测吗？（比如超支要走审批、或者你就是不想每月对账）→ 是，选 Claude Code。
- 你的团队离不开 JetBrains 系 IDE 吗？ → 是，选 Claude Code，或把 Amp 限定在 VS Code 系里作为补充。
- 你需要把 AI 成本拆到项目/人/任务，或者要对账单做交叉验证吗？ → 是，选 Amp，并且把预付额度控制在未来 3 到 6 个月可见用量之内。
- 你的用量月度波动大、闲月很闲吗？ → 是，倾向 Amp；用量高且稳定则倾向订阅封顶。
四问都不明确的话，我的建议是先用 Claude Code 跑一个月，把”我到底一天用它几次、什么任务用它”摸清楚。有了真实用量画像，上面这些问题才有答案可填；在没有画像的时候比价，比的其实是想象。
另外提醒一句，如果你是企业采购，第 3 步要额外确认零加成在企业工作区是否同样适用——这一点我没有核到，只能请你去问官方。
最后
把这篇的判断压成一句：Amp 让你看清成本，Claude Code 让你不必看成本，你得先想明白自己想要哪一种。
这两者不是替代关系，也不存在谁全面更优的说法。零加成的价值只有在你真的会去看账单、会去做归因的时候才兑现；订阅封顶的价值只有在你确实需要”不操心”的时候才兑现。买错的典型症状是：买了 Amp 却从不看账单，于是只承受了不可预期性；或者买了 Claude Code 却每天在等窗口，于是把成本从钱转移到了自己的下班时间上。
最后再重申两条边界，免得被误引用：本文没有给出 Amp 的任何价格数字，因为我核不到，价格以官方定价页为准；Claude Code 的具体窗口时长和额度数值同样以官方文档为准，机制层面的说明见 Claude Code 额度限制。真要下单之前，两边的官方页面都自己打开看一眼，这一步没人能替你做。