Augment 超额 top-up 怎么控成本？美元额度制的三个刹车点
如果你的团队在用 Augment，账单上迟早会出现一个问题：这个月 $100 的月费之外，又多充了多少钱，钱花在谁身上、花在什么任务上。
Augment 的 BUSINESS 档是 $100/月的固定价，里面含 $100 的使用额度，这份额度涵盖 LLM 调用、Context Engine 和计算，席位上限 50 个。额度用完之后的机制，官方页面上写得很直接：Top-ups, pay as you go——按需充值、随用随付。ENTERPRISE 档则是 Custom 报价，席位没有上限，使用限额可以自定义。
这篇不谈 Augment 好不好用，只谈一件事：在这套计费方式下，你的钱会从哪些缝里漏出去，以及怎么在漏之前把闸门装上。读完你应该能做到三件事——看懂自己的账单构成、给团队立几条能执行的用量纪律、判断什么时候该停止无限 top-up 转而去谈自定义限额。
额度单位就是美元，这省掉了一整层换算
先说这套设计里我觉得最实在的一点。
市面上大部分 AI 编程工具的额度单位是 credits（点数）。你买的是点数，花的也是点数，但”一次操作扣几个点”这件事，往往查不到。这不是抱怨，是实情：Kiro 的官方计费文档页在核对时是 404 的，Warp 的请求限制文档页同样 404，两家都查不到”什么算一次请求”。于是你拿着一个剩余点数的数字，却算不出它还能撑几天。
Augment 的额度单位直接就是美元。这意味着”超额多少钱”这个问题没有中间环节：超出 $30，就是 $30。不需要先知道单价，也不需要先知道一次 Agent 任务扣几个点。
对比一下就更清楚了。拿事实明确的 Kiro 做参照：PRO 档 $20/月含 1,000 credits，套餐内均价是 $20 ÷ 1000 = $0.02 一个 credit；超额单价 $0.04 一个 credit，正好是套餐内均价的 2 倍。这个 2 倍很重要——它意味着同样的工作量，落在套餐内还是落在超额区，成本差一倍。但要用上这个结论，你还得先回答”我这个月大概会消耗多少 credits”，而这一步恰恰是查不到的。
| 对比项 | credits 制（如 Kiro PRO） | Augment BUSINESS 的美元额度 |
|---|---|---|
| 额度单位 | credits（1,000/月） | 美元（$100/月） |
| 套餐内均价 | $0.02/credit（$20÷1000） | 额度本身就是美元，无需换算 |
| 超额单价 | $0.04/credit，是套餐内均价的 2 倍 | 页面只写 Top-ups, pay as you go，未写明是否有价差 |
| 算超额账的步骤 | 先查单次扣点 → 再乘数量 → 再乘单价 | 直接看金额 |
| 额度覆盖范围 | 页面未写明拆分口径 | 明确涵盖 LLM + Context Engine + 计算 |
表里最后一行也值得留意：Augment 明说这 $100 覆盖 LLM、Context Engine 和计算三块。这既是好事——不用担心 Context Engine 另外计价；也是提醒——你的上下文用得越重，吃掉的就是同一份钱。这一点后面还会说。
至于超额部分的单价跟额度内是否一样、有没有量大折扣，页面上没写。这里我不猜，以官方控制台与销售沟通的口径为准。
麻烦也正出在 pay-as-you-go：它没有天然的停止点
美元额度制算账清楚，但它有个反面。
credits 制虽然算账绕，却自带一个信号：点数归零。归零那一刻，工具会告诉你”没了”，这是一个天然的停顿点——你被迫决定是加钱、是降级用、还是等下个周期。像 Cursor 那种把快速请求用完之后自动落到慢速池的设计，代价其实落在时间上而不是钱上（这个机制我们在Cursor 快速请求用完了怎么办里拆过），用户会明显感觉到”变慢了”，于是自然收敛。
按需充值不给你这个停顿点。$100 用完，充上就继续；再用完，再充。每一次单独看都是几十美元的小额决策，合起来才是月底那张超预算的账单。真正危险的不是单价，是没有任何一个环节会主动喊停。
所以在 Augment 这套机制下，刹车必须由你自己装。这不是可选项。团队规模一大，这个问题会被放大——这也是 Copilot 那类按人分配 credits 的方案里，团队管理员最头疼的部分（我们在Copilot credits 用完之后团队怎么办里讲过团队侧的分配思路）。
团队场景：$100 按什么口径给的，页面没写
这是本篇最需要说实话的一节。
官方定价页面写的是：BUSINESS $100/月固定价，含 $100 使用额度/月，最多 50 席位。但这份 $100 额度到底是按整个工作区给的一份，还是按每个席位各给一份，页面没有写明。同样没写明的还有：能不能看到按人拆分的消耗报表、有没有预算上限设置、top-up 的最小充值金额是多少。
我不打算替官方回答这些。这几个数直接决定你的年度预算，猜错的代价远大于”承认不知道”的成本。正确做法是：开通前把这几条列成清单，去官方控制台确认，或者直接向销售问清楚，以他们的书面口径为准。
但口径不明不等于没法管。不管 $100 是怎么给的，下面这套办法都成立：
第一，建立用量归属。 按人或按项目给出一个可追溯的维度。如果控制台本身提供了分人视图，直接用；如果没有，退一步用组织手段——比如约定重度任务必须在项目频道里报备，或者把不同项目拆到不同工作区（前提是席位允许）。目的不是监视谁，而是让”这个月多花的 $80 是哪来的”有答案。
第二，定期看消耗分布，别只看总数。 团队用量几乎不会是平均的。经验上，十来个人的团队里，通常有两三个人贡献了大半消耗——可能因为他们在啃最难的模块，也可能因为他们的提问方式让 Agent 展开了太多步骤。这两种情况的处理完全相反，前者是合理成本，后者是可以优化的浪费。不看分布，你分不出来。
第三，跟重度使用者单独聊用法，而不是发通告限额。 群发”请大家节约用量”的效果基本为零，而且会让真正在干硬活的人不敢用。找那两三个人看看他们的实际提问，往往半小时就能找到问题。
四个能立刻做的控成本动作
设预算上限和告警。 如果控制台提供这个功能就一定要开——但它是否提供，页面上同样没写，需要你自己去后台确认。如果平台侧没有，就退到财务侧：把 top-up 的支付方式设成需要审批的，让每次充值经过一个人。手动一步，就是一个刹车。
把大任务拆段做，以便中途叫停。 这是最容易被忽略、收益却最直接的一条。一个跑二十分钟的 Agent 任务，如果它在第三分钟就跑偏了，剩下十七分钟的钱是白烧的。拆成三段做，你在每段结束时都有一次叫停的机会。
控制上下文长度。 因为 Augment 的额度明确涵盖 Context Engine，长上下文在这里是双重成本——检索和理解本身要钱，喂给模型的 token 也要钱。习惯性地把整个仓库丢进上下文，跟精确指定三五个相关文件，账单上的差别是实打实的。
把需求圈死，减少 Agent 自主展开的步数。 举个具体的：
“帮我优化下这个项目”
这句话会让 Agent 自己去搜索目录结构、读一堆文件、判断哪里该改、逐个文件生成修改、再自检一遍——十几步起步，而且每一步都在消耗额度。
“只改
order/service.ts里的createOrder函数，把库存校验提到扣款之前，别动支付逻辑”
这句话把范围锁死在一个文件一个函数上，Agent 没有自主展开的空间，步数收敛到个位数。
同一件事，两种问法，成本可以差好几倍。这一条不需要任何平台功能配合，今天就能改，而且改完是团队里最省钱的一条习惯。
什么时候该停止 top-up，去谈 Enterprise
给一条能直接执行的判断线：
如果连续 3 个月的 top-up 金额都稳定超过月费本身（也就是 $100 之外每月还要再充 $100 以上），说明你现在的档位跟实际用量不匹配，该去谈 ENTERPRISE 了。
理由很简单。BUSINESS 是固定 $100 含 $100 额度，当你每月实际花到 $200 以上，意味着有一半以上的支出走的是完全没有约束的按需充值通道——这部分既拿不到任何档位化的确定性，也没有上限保护。而 ENTERPRISE 档在页面上明确写了两件事：席位无限制、使用限额可自定义。后面这四个字才是关键，它意味着限额这件事从”你自己盯”变成”合同里写”。
再给一条更早的预警线：如果某个月 top-up 达到月费的 50%（也就是额外充了 $50 以上），还不到换档的时候，但该开始做用量归属和消耗分布记录了。等到翻倍那天你手上有三个月的数据，谈判时能说清楚自己要什么样的限额，而不是只能被动接受报价。
要提醒的是：ENTERPRISE 是 Custom 报价，具体价格、限额怎么设、超限之后是硬停还是转按需，这些页面上全都没有，只能谈。别抱着”网上查个参考价”的想法去，查不到的。
最后
Augment 这套计费的性格挺明确：算账这一环它替你简化了，管账这一环它交还给你。美元额度让你不用做单位换算，这是省心的地方；pay-as-you-go 让你没有强制停顿点，这是要自己补的地方。
真正的成本控制不在充值页面上，在提问方式和任务拆分上。上面那四个动作里，只有第一个依赖平台功能，另外三个——拆段、控上下文、圈死需求——今天就能开始做，而且不花一分钱。
至于最小充值金额、预算上限功能、用量报表、超额是否有折扣这几件事，页面上确实没写，我也不替它编。开通前花十分钟在官方控制台里逐条确认，或者直接问销售要一份书面说明，比看任何二手文章都靠谱。