按额度计费的智能体产品

步骤 1供应商说"额度"时可能指三种东西，其中只有一种是价格。

同一个词在不同产品里干着完全不同的活。在你试图为某个按额度计费的方案做预算之前，先把它归到下面三类之一。

• 挂钩型额度只是换了名字的货币单位。1 个额度等于一个明示的金额，供应商以额度为单位公布各模型的费率，算法跟你已经在做的 token 算法一样。额度的存在只是为了打包——让供应商把一份配额塞进席位里并卖加购包——它不增加任何预测风险。
• 计量型额度以某个你能数清的东西计价：token、请求、音频分钟、解析页数。只有在换算表公开且带版本号的前提下，你才能把它折算成工作量。没有版本号，那张表就只是今天的快照。
• 不透明额度以任何你观察不到的东西计价。供应商说一次任务消耗"若干额度"，具体多少取决于产品内部做出的路由与思考强度决策，而你了解费率的唯一方式就是花掉它、看着余额往下掉。这在按席位定价的智能体产品里是常态，也是本页要讲的那一类。

这个区分之所以重要，是因为预算有两个因子，而没有锚点的额度藏掉了其中一个。支出等于单价乘数量。在 token 账单上，你谈的是单价、控制的是数量，这才使智能体支出预测在根本上可做。在不透明额度的账单上，供应商既定下配额的价格，又决定每次任务吃掉它多少。价目表上什么都不必动，你的实际每任务成本就能翻倍。

步骤 2两个真实案例，把事实说准。

这两件事都发生在 2026 年。它们有用，是因为二者从大致相同的起点出发，走向了相反的方向。

Notion，2026 年 10 月 19 日。据该公司自己的公告与帮助中心：Business 与 Enterprise 席位各获得 1,500 个 Standard 额度，用于由 Notion 的路由器挑选模型的工作；另有 500 个 Select 额度，用于用户自己指定模型或运行自定义智能体的工作。额度按月重置，不结转，不能在成员之间共享或转移；管理员可以加购。新客户在公告当天切换，既有客户在 11 月 2 日切换。额度与 token、额度与任务之间的换算率均未公布。同一次发布里，智能体对单个任务的持续工作时长从 5 分钟提升到 24 小时以上。

GitHub，2026 年 6 月 1 日。Copilot 废除了"premium request"这一计费单位，换成 GitHub AI Credits：1 个额度等于 1 美分，用量按各模型公布的费率、以输入、输出与缓存 token 计量。按年订阅 Pro 与 Pro+ 的用户在订阅到期前仍留在旧的按请求计费体系上，于是旧的倍率——例如代码评审按 13 个请求计——会与新体系并行运转一段时间。

把这两段当成一个结论来读。GitHub 的旧 premium request 本来就是一个不透明额度外挂一张倍率表，而它的行进方向是朝着锚点走。Notion 的新额度在设计上就是不透明的，行进方向是离开锚点。这里没有什么"等行业趋同"可言；你必须逐家去问，自己买到的是哪一种。

步骤 3自动路由让供应商同时成为两个因子上的交易对手。

推销一套额度体系的那个功能，往往正是让它不可预测的那个功能。Notion 对 Auto 的说法是：在 20 多个常见用例上，它取得了与 Opus 5.5 和 Astra 相当的结果，而平均成本低约 90%——这个数字在该公司帮助中心里写的是"比 Opus 5.5 低 87%"。两个数都来自供应商自己的测试，而两者之间的差距很说明问题：如果供货方对自家节省幅度的两次公开表述差了三个百分点，那你靠一条下落的额度余额做出的还原，不会比这更紧。

路由是个好主意，本页不是在反对它——模型路由正是智能体产品里大部分成本下降的真正实现方式。问题纯粹在于旋钮归谁。一个把你的中位任务从小模型挪到大模型的路由器，已经抬高了你的每任务成本，而没有任何价格变动、任何公告、任何账单项。在 token 账单上，你会立刻从按模型的明细里看到它。在额度账单上，你看到的是余额见底得更早，而供应商的解释是你的用量长了。

所以要向按额度计费的供应商提的问题，不是"一次任务多少钱"，而是：什么会改变一次给定任务所消耗的额度数，以及它改变之前你会不会先告诉我？通常有三样东西能改变它——路由策略、各模型的额度权重、思考强度默认值。三样都在供应商一侧。未固定的供应商默认值是这一风险的一般形式。

步骤 4去测那个唯一的不变量：用你自己的流量，测每完成一次任务消耗多少额度。

你无法审计一个从未拿到的费率，但你可以测自己的消耗量，而这个测量既是预测的输入，也是你带进续约谈判的证据。按任务类型分别跑，因为混合后的数字恰好会盖住你马上要放量的那一类任务。

# Measure on YOUR traffic. The vendor's unit is the only thing you
# cannot define, so define everything else: the task, and "done".

# 1. Read the balance, run N real tasks of ONE type, read it again.
before = admin_api.credit_balance(pool="standard")
results = [run_task(t) for t in sample_of(task_type, n=50)]
after  = admin_api.credit_balance(pool="standard")

# 2. Divide by SUCCESSES, not attempts. A retried task spent twice.
done = [r for r in results if r.accepted_by_reviewer]
credits_per_completed_task = (before - after) / len(done)

# 3. Re-measure monthly, and after any vendor release note.
#    The series is the deliverable; a single number is not.

有三个细节决定这个数字是否诚实。要除以完成的任务数而不是尝试次数，否则一次质量回退会被读成一次降价——这正是每任务成本在 token 账单上要求的同一种纪律。要把两个额度池分开记：一个产品同时有"路由池"和"用户自选池"，就是有两个价格，而把工作从一边挪到另一边是一个伪装成模型偏好的成本决策。还要在每个数字旁记下日期，因为能发现一次无声的权重调整的是那条时间序列，单个样本做不到。

接下来是配额算术，而"不结转、不共享池"正是在这里造成伤害。设一个席位每月有 1,500 额度，实测每完成一次任务烧 12 额度。

One seat, 1,500 routed credits per month, no rollover, no pooling.

Measured burn    Tasks/seat/month   Team of 20, capacity
---------------  -----------------   --------------------
12 credits/task              125              2,500 tasks
20 credits/task               75              1,500 tasks   (-40%)

Same seat price. Same rate card. Nothing announced.

Pooling arithmetic, 20 seats, 1,500 each:
  pooled      30,000 credits against TEAM peak
  per-seat    20 x 1,500 against EACH SEAT's peak
  if 4 power users need 3,000 and 16 need 400:
    pooled need  = 4x3,000 + 16x400 = 18,400  (fits)
    per-seat     = 4 seats throttled at 1,500; 17,600 unused

上半部分是路由暴露：一次你根本看不见的权重调整，在价格不变的情况下吃掉你 40% 的吞吐。下半部分是结构性的那一半。没有共享池，按团队平均值配的额度对谁都不对——重度用户撞墙，而轻度用户的余额在月底原地过期。要按每个席位自己的峰值配额，这通常意味着给一小群人买更高的档，而不是给所有人一个统一配额；并且把用不掉的余量当成固定成本，而不是当成意外。固定成本与可变成本是看这件事的框架，而算出来的每任务数字归单位经济性管。

步骤 5合同里该要什么，按优先级排。

这件事上采购的筹码比工程多，而这些诉求都小到：一个全部拒绝的供应商，其实是在告诉你某件事。按这个顺序提。

• 一个锚点，或一张带版本号的公开权重表。1 个额度等于一个明示金额；或者按模型，1 个额度等于一个明示数量的可计量物，并带一个你可以引用的版本串。单这一条就把不透明额度变成计量型额度，下面所有条款都变得不必要。
• 权重调整前的通知。如果一次给定操作所消耗的额度数可以变，那你要的是像价格变动一样、带明示提前期的公告。在没有锚点的情况下，这是协议里最值钱的一条。
• 一份你能对账的用量导出。按请求的额度消耗，附上服务该请求的模型与时间戳，可通过 API 取回。没有模型归属，你就无法区分"我们用多了"和"路由器挪了"——而这个区分就是争议的全部。
• 有上限的超额单价。期中加购的额度，按一个在合同期内锁定的价格。无上限的超额会把一笔席位交易变成由供应商裁量的用量计费——谁最终承担这份波动，见定价模型。
• 共享池，或一个可调的档位组合。如果拿不到共享池，就去谈每月在档位之间调整席位的权利。这能挽回共享池本应吸收的一部分波动。
• 一条不依赖这些额度的退出路径。任何以额度计价的承诺，都是以交易对手定义的单位计价的承诺，所以宁可要一个费率差一点的短期合同，也不要一个费率好看的长约。预留吞吐与承诺用量讲的是同一个陷阱的 token 版本。

有一处不对称值得点名：供应商看得见你的每任务额度，你看不见。这不是什么阴谋，只是遥测数据放在哪里的问题；它的含义是——你带着 step 4 那条实测序列去谈续约，和你只带着一张发票去谈续约，是两场不同的谈话。

步骤 6按额度计费确实更划算的那些场合。

上面讲的是可观测性，不是"额度不好"。有些情形下，买一个不透明额度就是对的，而出于原则拒绝它会让你多花钱。

• 当配额明显大于你的需求时。如果实测消耗只用掉席位配额的三分之一，汇率可以挪动相当大的幅度才会波及到你，而你买到的是一个你不会撞上的上限。风险真实存在，但今年不属于你。放量之前重新测一次。
• 当额度意味着供应商替你吃掉一笔你吃不下的成本时。一个路由池意味着某次结果很贵的任务由供应商承担。那正是定价模型所描述的波动转移，而在长尾型工作负载上，它可能比你让出的那份透明度更值钱。
• 当你是在评估、而不是在部署时。在试用期里，一份固定的额度配额就是一个无需任何工程投入的硬性支出天花板——而这恰恰是 token 账单会逼你自己造的那道护栏。免费额度与试用期经济性讲了另一侧的陷阱：试用期的消耗速率很少能在生产流量里存活。

你不该做的，是在没有实测序列的情况下把按额度计费的产品当成生产依赖，因为它的失效是安静的。token 账单失效得很响，会有一根你能告警的尖峰。额度账单的失效表现为吞吐：到月底任务开始被拒，受影响的是你最重度的用户，而这起事故会以"对产品的抱怨"而不是"关于预算的告警"抵达你。把余额接到你放支出告警的同一处——环内成本控制就是它该去的地方——并且对"消耗速率 ÷ 剩余天数"告警，而不是对余额告警。