Augment 用美元当额度单位：$100 月费含 $100 用量额度是什么玩法？
你要是把市面上几家编程 Agent 的定价页排开看，会发现一个共同的动作：它们几乎都先发明一种叫 credits 的点数，然后告诉你每月给你多少点。$20 给 1,000 点，$200 给 18,000 点，听起来很清楚。但你真正想知道的那个问题——「我一天干八小时活儿，这些点够不够用」——它没回答。因为要回答这个问题，你得先知道一次操作扣几个点，而这恰恰是各家披露得最少的一层。
Augment Code 在这件事上走了另一条路。它的 BUSINESS 档是 $100/月固定价，包含 $100 的使用额度，而这个额度的单位不是点数，是美元。你的账户里扣掉的东西，和你信用卡上付出去的东西，是同一种单位。
这篇就把这件事讲透：钱当额度到底好在哪、$100 含 $100 这句话说明了什么又没说明什么、这笔额度覆盖的三类消耗为什么让它不能和「纯 API 账单」划等号、超额的 top-up 机制要配什么刹车、以及 50 席位那条硬上限该怎么算。文末给一条决策路径。看完你至少能判断：你的团队适不适合用这种计价方式。
别家发明点数，它直接扣美元
先说清楚这个差异有多大。
credits 制的本质是在你和账单之间插了一层换算：你充的是钱，扣的是点，中间那个「一点值多少钱、一点能干多少活」的汇率由厂商定义。理论上这没什么问题，运营商卖流量也是这么干的。麻烦在于这个汇率往往是单向透明的——厂商会告诉你 $20 换 1,000 点，但很少告诉你「让 Agent 把一个订单模块重构一遍」要花掉多少点。
以 Kiro 为例（这家事实相对完整，拿来当参照物）：PRO 档 $20/月含 1,000 credits，套餐内每 credit 折合 $20 ÷ 1,000 = $0.02；超额单价是 $0.04/credit，正好是套餐内的 2 倍。这个算术做得出来，但它只解决了「一个点多少钱」，没解决「一个点能干多少事」。Kiro 官方也没公开单次操作的 credit 消耗（相关计费文档页面当前是 404 状态）。也就是说，即便你把单价算到小数点后四位，你依然估不出月底会不会超。
Augment 的做法是把中间那层直接省掉。它没有汇率，因为它没有第二种单位。$100 的额度花掉 $37，你就知道你花了 $37。
| 项目 | 点数制（以 Kiro PRO 为例） | Augment BUSINESS |
|---|---|---|
| 额度单位 | credits（点数） | 美元 |
| 套餐内单价 | $20 ÷ 1,000 = $0.02/credit | 无需换算，1 美元即 1 美元 |
| 超额计价 | $0.04/credit（页面写明） | Top-ups, pay as you go（单价页面未写明） |
| 「一次操作花多少」是否公开 | 未公开 | 未公开 |
| 和自建 API 成本的口径 | 不同单位，无法直接比 | 同为美元，口径一致 |
注意最后两行的对比。两家都没告诉你一次操作花多少——这一点上它们没有高下之分，这是全行业的普遍状态。差别在最后一行：当你想回答「这钱花得值不值」的时候，Augment 的额度天然可以和「我自己调 API 要花多少」放在同一个坐标系里比，而点数制不行，除非厂商主动公开换算关系。
这不是小事。团队里做技术预算的人，最常被问到的问题就是「我们买这个工具，比自己搭一套贵多少」。美元额度让你能直接回答；点数制会让你卡在第一步。
$100 含 $100：这句话说明了什么，又没说明什么
先说它说明了什么。
月费和包含额度等额，意味着在没有超额的前提下，你交出去的这 $100，基本对应你这个月实际消耗掉的 $100 用量价值。换句话说，这一档更像是「一笔用量额度 + 平台能力」的打包销售，而不是在用量之上再叠一层加价卖给你。你付的钱，等于你能用掉的量。
再说它没有说明什么，这一层更重要。
第一，页面写的是 $100 固定价、包含 $100 额度，并没有说这个额度是按供应商成本原价结算的。「零加成」（zero markup）是另一家产品——Amp——在自己文档里明确写过的措辞，Augment 的定价页没有这句话。所以你可以说「月费和额度等额」，不能替它说「所以它一分钱不赚差价」。这两句话听着像，但后者是你替它下的结论，不是它承诺的内容。真要做这个判断，得看 Context Engine 和计算这两块怎么定价，而那个定价页面上没写。
第二，$100/月这个价格和「最多 50 席位」这条限制之间的关系，定价页的表述是固定价加席位上限，并没有把「是否按每席位计费」这一层写死。这类信息在采购环节非常关键，我不替它补——以官方定价页面为准，签合同前直接问销售，把「$100 是整个工作区的价格还是每人的价格」写进邮件里留痕。这不是我谨慎过头：一个 5 人团队和一个 50 人团队，这两种解释之间差 50 倍。
顺便算一笔上限：这一档最多 50 席位，如果按每席位 $100、每席位含 $100 额度理解，那么这一档能承载的月订阅规模就是 50 × $100 = $5,000/月，对应包含额度同为 $5,000/月。超过这个规模，只能走 ENTERPRISE——那一档是 Custom 报价，席位无限制，使用限额可自定义。
这 $100 不只是模型钱
这是最容易被误读的一点。
Augment 明确写了这笔额度涵盖三类消耗：LLM、Context Engine、计算。也就是说，你花掉的不只是模型调用的 token 钱，还包括它给你的代码库做索引、检索、维护上下文的那部分开销，以及跑这些东西的算力。
所以前面说的「可以和自建 API 成本比」，要加一个限定：别拿它和纯 token 账单直接划等号。你自己搭一套，除了模型调用费，还得算上向量库、索引更新、检索服务、跑这些东西的机器和维护它们的人。把这些都算进去再比，才是公平的对照。只比 token 单价，等于拿一台整车的价格去比一台发动机。
那么这三类消耗各占多大比重？不知道。定价页没有拆分，Context Engine 具体怎么计价也没写。我把这条明确写出来，是因为它直接影响你的用法判断：如果索引消耗占大头，那么「代码库有多大、多久重建一次索引」就比「今天问了多少个问题」更能决定你的账单；如果模型调用占大头，那么控制账单的着力点就回到提问方式上。这两种情况下的省钱策略完全相反，而现在没有公开信息能让你分辨是哪一种。
能给的实操建议只有一条：头两周把额度消耗曲线记下来。每天记一次剩余额度，同时记下当天团队干了什么——有没有新接入一个大仓库、有没有跑批量重构。两周下来你自己就有一张消耗结构的粗图，比任何猜测都可靠。这活儿看着笨，但它是目前唯一能拿到真数据的办法。
超额是 top-up，所以你必须自己装刹车
Augment 的超额机制写得很直白：Top-ups, pay as you go——额度用完了充值继续，按用量走。
这个机制本身没问题，问题在于它和另一个特性的组合：用量不可预测。Agent 类工具的消耗天然是尖峰型的。一个「帮我把这个电商项目的订单模块重构一下」的任务，Agent 会自己拆成搜索、读取、生成、逐文件修改、自检十几步，每一步都在花钱；而「只改 order/service.ts 里的 createOrder，别动支付逻辑」这种问法，消耗就收敛得多。同一个人、同一天，两种问法的账单可以差出一个量级。
「按需扣费」加上「消耗不可预测」，就是那种月底看账单会心跳加速的组合。所以：
- 设预算上限。能在产品里设就在产品里设，设不了就在支付渠道上设——用一张限额虚拟卡，或者和财务约定单月上限。宁可到点被拦住，也别到月底才发现。
- 把额度通知打开并指定到人。80% 的通知发到一个没人看的群里等于没有。指定一个具体的人接收，并明确他收到之后要做什么。
- 约定超额审批。第一次 top-up 之前要有人点头。不要让「充一点就能继续」变成一个无摩擦动作——无摩擦的付费动作是最容易失控的。
这套做法不是 Augment 独有的功课。凡是「用完了可以加钱续」的产品都需要它。可以对照着看另外两类机制：Cursor 的做法是快速请求用完之后降级到慢速池，代价落在时间上而不是钱上（详见 Cursor 快速请求用完了怎么办）；Copilot 的团队档则是另一种形态，管理员对 credits 的分配和超额有一层管控（详见 Copilot credits 用完了怎么办（团队版））。三种机制没有优劣，但它们踩坑的位置完全不同：降速机制最坏结果是效率下降，加钱机制最坏结果是账单超支。你得知道自己买的是哪一种。
50 席位这条线，要按未来的规模来判断
BUSINESS 档最多 50 席位，这是硬上限。超过就得谈 ENTERPRISE（Custom 报价，席位无限制）。
采购的时候别按今天的人数判断，按未来 12 个月的人数判断。理由很实际：中途从 BUSINESS 迁到 ENTERPRISE，你面对的不是点一下升级按钮，而是重新走一轮商务流程——报价、合同、法务、可能还有安全评估。这个过程占用的时间成本，往往比两档之间的价差更让人难受。
一个粗糙但好用的判断线：当前人数超过 35 人，就直接按 ENTERPRISE 谈。留 15 个席位的缓冲，一年内正常扩张不至于撞线。低于这个数，BUSINESS 够用，先跑起来更重要。
顺带说一句产品线：Augment 现在的产品名叫 Cosmos，官方博客在 2026-06-03 发文介绍过（“Hello, Cosmos: the platform for AI-native engineering teams”）；2026-07-29 的博客提到 GPT-5.6 Sol 成为 Cosmos 的默认模型。你在文档和界面里看到 Cosmos 这个词，指的就是它。
那到底该不该用它
不做排名，按场景说。
这几种情况下，美元额度这套机制对你是加分的：
- 你需要向上汇报「这笔钱花在哪了」，而汇报对象只认美元不认点数；
- 你正在做「买工具 vs 自建」的对比论证，需要一个口径一致的数字；
- 团队规模在 50 人以内，且短期内不会翻倍；
- 你能接受「先跑两周摸清消耗结构」这个前期投入。
这几种情况下，先别急：
- 你只想找个免费或低价的档位试试水——Augment 的免费档和试用条款页面未写明，定价页上只有 “Try Cosmos” 和 “Book demo” 两个按钮。想低成本试，得先问清楚试用怎么给，别默认有；
- 你的团队已经接近或超过 50 人，那 BUSINESS 这一档从一开始就不是你的选项；
- 你对超额支出的容忍度极低，且没有能力设预算上限——那么「加钱续」这类机制不如「降速继续用」的机制让人踏实。
再补一句关于对比的方法论。看这类工具，别把主要精力花在比「谁家的模型更强」上。一来那一层难以核实，二来同一个模型在两种提问方式下的产出差距，通常远大于两个模型在同一种提问方式下的差距。真正会长期影响你的，是计价机制本身——它决定了额度用完那一刻你面对的是什么：是加钱、是降速、还是只能等。这个差别，在你第三次撞到上限的时候会变得非常具体。想横向看更多机制形态，Codex 的用量与计费那篇可以一起对照着读。
最后
Augment 这个设计的价值，说到底是省掉了一层翻译。别家让你在「点数」和「钱」之间做换算，而换算所需的关键信息（一次操作扣几个点）恰恰没公开，于是这个换算你永远做不完整。Augment 把单位统一成美元，这个断头路就不存在了。
但它没解决另一半问题：一次操作要花多少美元，它同样没公开。所以你拿到的是一个口径清晰、但依然无法事先估算的额度。清晰和可预测是两回事，别把前者当成后者。
真正能落地的动作就三个：签约前把「$100 是整个工作区还是每席位」问清楚并留痕；上线后头两周记录消耗曲线，拿到属于你团队的真实数据；同时把预算上限和超额审批装好，别让 top-up 变成一个不需要点头的动作。
本文涉及的价格、额度和席位限制，均以 Augment 官方定价页面的当前表述为准。免费档条款、Context Engine 的具体计价方式、超额单价这三项，官方页面当前没有写明，本文也不做任何推测。