API 成本怎么监控：等账单出来就晚了
数据截至 2026-07，价格与限额以各官网为准。
成本监控真正的价值不在”知道花了多少”，而在”超支之前就把它拦住”。账单是事后凭证，不是控制手段——等你在月初看到上个月的数字时，钱已经花完了，你能做的只有下个月注意点。真正有用的监控必须是三层结构：进程内的实时记账、平台侧的硬性预算闸门、每天一次的对账与预测，缺任何一层都会在某个时刻漏掉。
一个很常见的误解是：额度快用完的时候，服务方会自动帮你降级到便宜的模型，或者至少限个速，不至于突然断掉。这个想象很符合直觉，但至少在 GitHub Copilot 转向按用量计费之后并不成立——按官方说明的机制，额度耗尽时没有自动降级到便宜模型的机制，如果你没有允许超额，就是直接阻断到下个计费周期。这意味着”没监控”的代价不只是多花钱，还可能是整个团队某天上午突然用不了工具。
先搞清楚你在监控的计量单位是什么
监控之前先回答一个问题：你的账，到底以什么为单位在跳？这一步跳过去，后面所有的仪表盘都是自我安慰。
以 GitHub Copilot 为例，2026 年这里发生了体制性变化。2026-06-01 起，全部 Copilot 计划转为按用量计费（usage-based billing），用 GitHub AI Credits 取代了原来的 premium requests 计数。换算关系很直白：1 credit = 1 美分（$0.01），用量按 token 消耗计算——输入 token、输出 token、缓存 token 分别按各模型的 API 费率折算成钱，再折算成 credits。
这个变化对监控的影响是根本性的。旧的 premium request 制下，你数的是”次数”，一次交互扣几个请求是相对可预测的；换成 credits 之后，你数的是”钱”，而同样一次交互，塞进去 3000 token 的上下文和塞进去 30000 token 的上下文，成本可以差一个量级。所以从 2026-06 之后，“我今天问了几次”已经不是有效的成本指标了，“我今天喂进去多少 token”才是。
顺带说一句，网上大量讲 Copilot 计费的文章还停留在 premium requests 的口径上，那些内容不是写错了，是过期了。你在做成本模型的时候，先确认参考资料的时间点。
第一层：进程内的 token 记账
这是唯一能做到”实时”的一层，也是最多人跳过的一层。原因也不难理解——它需要你在自己的代码里动手，而不是打开一个现成的面板。
做法其实不复杂。任何主流的 API 响应里都会带 usage 字段（不同厂商字段名不同，但都有），里面是这次请求真实消耗的输入 token、输出 token，缓存类的计费还会单独给出缓存写入和缓存命中的 token 数。你要做的是：
- 在 API 客户端外面包一层薄封装，所有调用都走这层，不允许业务代码直接 new 一个原始 client 出来。这是整件事的前提，一旦有旁路，统计就永远对不上。
- 每次调用结束把 usage 落一条结构化日志，至少记：时间戳、调用方标识（哪个服务、哪个功能、哪个用户）、模型名、各类 token 数、以及你自己按当前单价折算出来的估算金额。
- 把这条日志写进能聚合的地方，最简单的就是一张数据库表，或者直接打到你已有的日志系统里按字段索引。不要只 print 到控制台。
多说一句折算金额：你自己算出来的数一定和最终账单有出入，这很正常，缓存命中口径、地域路由、批处理折扣都会造成偏差。但估算值的作用不是对账，是给你一个每分钟都在更新的相对指标。今天下午三点的曲线比上午十点陡了五倍，这个信号本身就够你去查发生了什么，不需要精确到分。
还有一个实践上的细节：流式（stream）调用的 token 统计口径可能和非流式不完全一样，有些实现下增量返回时不带完整 usage，需要在流结束后取汇总。如果你的应用大量用流式，第一件事就是验证你到底有没有拿到完整的 usage，别记了半天记的全是零。
第二层：平台侧的预算闸门
进程内记账能让你”看见”，但它拦不住任何东西——代码里的一个死循环照样能在你看到告警之前把钱烧掉。真正能兜底的是服务方提供的硬性预算限制，因为那是在服务端执行的。
还是拿 Copilot 举例，它的预算控制是分层的：管理员用美元预算控制超额部分，按 $0.01/credit 扣减（也就是 $10 预算等于 1,000 credits），而预算可以设在四个层级上——user（单个用户）、cost center（成本中心）、enterprise spending limit（企业支出上限）、organization（组织）。
这四层不是重复设置，它们各有各的用法：
- user 级适合防单点失控，比如某个成员在跑批量任务。但要注意一个坑：把某个用户的预算设成 $0，会立即阻断该用户，不是”用完再停”，是马上停。这个动作在排查问题时很有用，但别当成”暂时不给他加钱”的默认配置随手一设。
- organization / cost center 级适合按团队分摊，把研发、测试、外包分到不同的池子里，出问题时能快速定位是哪块在涨。
- enterprise spending limit 是最后一道天花板，它的价值就在于”这个月无论如何不会超过这个数”。
设预算这件事最重要的心理建设是：预算不是省钱工具，是熔断器。 它的目标不是让你花得更少，而是保证任何一次事故的损失有上限。所以数值应该按”我能接受的最坏情况”来定，而不是按”我预计要花多少”来定。
第三层：日频对账与预测
前两层解决实时和兜底，第三层解决趋势。这一层的产出物只有一个：当前节奏跑到月底会是多少钱。
计算方式很朴素——取本月至今的实际用量，除以已过天数，乘以本月总天数。别追求复杂模型，因为 AI 用量的波动主要来自”有没有人在跑新东西”，任何精巧的时间序列模型都预测不了这个。粗糙的线性外推加上人工判断，已经够用。
有一个时间节点值得单独拎出来说：GitHub 给既有 Business / Enterprise 客户在按量计费的头三个月（2026-06-01 至 2026-09-01）提供了更高的促销额度——Business 每用户 3,000 credits、Enterprise 每用户 7,000。促销结束之后，会回落到标准的 1,900 / 3,900。
这意味着什么？如果你是这类客户，你在 6、7、8 月看到的”额度还很宽裕”是被促销垫高的。回落之后，Business 的每用户额度大约只有促销期的六成多，Enterprise 大约只有一半多一点。建议在 9 月之前就去计费面板看”预测用量”那个数，把它和回落后的标准额度比一比——那个差值就是你 9 月开始要真金白银补的钱。这件事拖到 9 月账单出来才发现，正好就是标题里说的”等账单出来就晚了”。
顺带提一下各档的包含额度大致口径：Pro $10/月含 $15 credits，Pro+ $39/月含 $70，Max $100/月含 $200，Business $19/用户/月约 1,900 credits，Enterprise $39/用户/月约 3,900。付费档的基础额度大致等于其价格，GitHub 另外还加一份浮动的 flex 额度，所以实际可用总额可能比表里的数更高；Business 和 Enterprise 走的是组织池化余额，不是每人一个独立钱包。需要说明的是，上面这些数字来自第三方公开资料汇总口径，具体金额以 GitHub 官方计费页当时显示的为准，做预算的时候请以你自己控制台里看到的为准。
几个特别容易漏记的口径
监控做得再勤，漏掉计量口径一样会失准。列几个实际会被漏掉的：
- 额度不结转。 未用完的额度不会累积到下个月，每个自然月 1 号重置。所以”这个月省着点，下个月好用”这个策略是无效的，该用就用。
- 还在老制度上的人算法完全不同。 月付的 Pro / Pro+ 用户在 2026-06-01 自动迁移到了新制度，但年付的 Pro / Pro+ 用户在计划到期前仍然走 premium request 制。同一个团队里两种计费方式并存是完全可能的，做统一报表时得分开算。
- 年付用户的模型倍率上调了。 仅针对年付用户，2026-06-01 起模型倍率有上调，例如 Copilot code review 的模型倍率为 13——每发起一次 PR 评审或 IDE 里的代码评审，扣 13 个 premium request。如果你团队里有人给每个 PR 都挂了自动评审，这一项的消耗会比直觉高得多。
- code review 还会额外吃 Actions 分钟数。 自 2026-06-01 起，code review 同时消耗 GitHub Actions 分钟数。这条特别容易漏，因为它出现在另一张账单上——你盯着 Copilot 的用量面板看得很仔细，结果 Actions 那边悄悄涨了，两边分开看谁都不觉得有问题。
团队场景：怎么知道是谁、超在哪
个人用的时候，成本失控基本只有一个原因：某次任务喂了超大上下文。团队场景要复杂得多，通常需要能回答三个问题：哪个人、哪个功能、哪个模型。
对应的做法是在第一层记账时就把维度打全。最小可用的一组标签是：调用方（服务/功能名）、用户或团队标识、模型名。有了这三个维度，绝大多数异常都能在几分钟内定位——是某人在跑批量、是某个新上线的功能上下文构造有问题、还是某个模型被误配成了贵档。
如果用的是带组织池化余额的方案（比如 Copilot 的 Business / Enterprise），还有一个额外的注意点：池化意味着一个人的超量会消耗所有人的余额。所以组织级预算之外，仍然建议保留 user 级的上限作为分摊纪律，不然池子被一个人抽干的时候，其他人只会感受到”工具突然不能用了”，而完全不知道原因。
这套做法的局限，以及不适用的场景
诚实地说几条边界：
- 第一层的估算金额永远不等于账单。 缓存计费、批处理折扣、地域路由溢价都会造成偏差。它是趋势指标，不是财务凭证。要精确金额，只能以服务方账单为准。
- 规模很小的时候不值得做全套。 如果你一个人用，每月开销很低，直接设一个平台侧的预算上限就够了，不必为几十美元的支出去搭日志管道。三层结构的收益是随规模非线性上升的。
- 跨多个服务商时没有统一口径。 不同厂商的 token 计数方式、缓存计费规则、免费额度政策都不一样，想做一张”所有 AI 支出”的总表，只能自己在第一层统一折算，各家控制台之间是拼不起来的。
- 政策会变。 2026-06-01 这次变更本身就说明了这一点：一整套原本正确的成本模型，可能因为计费体制变化在一夜之间全部失效。所以监控体系里应该留一条”定期回看官方计费说明”的人工动作，别指望代码能自动感知政策变化。
另外，如果你用的是 OpenAI、Gemini、Anthropic 这类官方不支持中国大陆直连的服务，成本监控还多一层复杂度：链路本身不在官方支持范围内，用量数据和账单的可见性会受影响。市面上确实存在第三方中转与聚合平台，但计费是否透明、用量数据是否可核对，需要自己核实，这篇不做背书也不推荐具体渠道。
小结
账单是结果，不是控制手段，成本监控必须发生在花钱的那一刻。最小可用的三层是：进程内包一层客户端把每次 usage 落成结构化日志，平台侧设一个按”最坏情况”定的硬预算当熔断器，每天做一次线性外推看月底会落到哪。搞清楚你的计量单位从”次数”变成了”钱”之后，很多旧习惯要跟着改。最后记住两个具体动作：别指望额度用完会自动降级，那个机制不存在；如果你是 Business 或 Enterprise 的既有客户，在 9 月促销额度回落之前，先去看一眼预测用量。