团队的 Copilot credits 提前烧完了怎么办
数据截至 2026-07，价格与限额以各官网为准。
credits 提前烧完这件事，没有”临时救一下”的技术手段可指望——额度耗尽时不会自动切到便宜模型，只会直接阻断到下个计费周期，所以当月的处置本质上是一道分配题：把剩下的预算给谁、按什么顺序给，而不是去找一个能变出额度的开关。 真正能省下钱的动作发生在下个月，当月能做的只有止血和归因。
先承认一个很常见的误解：不少团队管理员以为额度是”用超了就降级”——以为超出包含额度之后，Copilot 会自动退回到某个更便宜的模型继续用，最多是回答质量差一点。这个预期在 2026-06-01 计费体制变更之后是不成立的。当前规则里没有任何自动降级机制，不允许超额就是直接停，人被挡在门外，直到下个自然月 1 号重置。把这一条搞错，事故当天就会浪费掉宝贵的两三个小时去翻设置找那个并不存在的”降级开关”。
先搞清楚现在的计费是怎么算的
2026-06-01 起，GitHub Copilot 全部计划转为按用量计费，用 GitHub AI Credits 替代了原来的 premium requests 计数。这个变更是体制性的，网上大量讲”高级请求还剩多少次”的旧文已经过期，按那套口径去估算团队用量必然对不上。
换算关系只有一条需要背下来：1 credit = 1 美分（$0.01）。用量按 token 消耗计算（输入、输出、缓存 token 分别计），再按各模型的 API 费率折算成 credits。这意味着两件事：
- 同样是”提一个问题”，扔一整个仓库上下文进去和只贴一个函数，消耗可能差出一两个数量级。计量单位是 token，不是次数。
- 预算金额和 credits 之间可以直接心算：$10 预算 = 1,000 credits。管理员在预算界面填的是美元，用量面板看到的是 credits，两个数之间就差两位小数。
各档包含的额度，按第三方公开资料的汇总口径大致是：Pro（$10/月）含约 $15 credits，Pro+（$39/月）含约 $70，Max（$100/月）含约 $200；Business 是 $19/用户/月、约 1,900 credits/用户，Enterprise 是 $39/用户/月、约 3,900 credits/用户。这些数字来自第三方汇总资料，具体额度请以 GitHub 官方计费页当时显示的为准。付费档的基础额度大致等于其价格，GitHub 另外会附加一份浮动额度，所以实际可用总量有时会比表上更高一点。
对团队来说还有一条结构性差异值得注意：Business 和 Enterprise 走的是组织池化余额，不是每人一个独立钱包。池化的好处是重度用户和轻度用户能互相调剂，坏处是——少数几个人的失控用法可以把全组的额度烧穿，而且在被烧穿之前，其他人完全没有感知。这是”月中突然全组都用不了”这类事故的结构性成因。
事故当天：按这个顺序处置
假设现在是月中，面板显示额度已经见底或者只剩一点。按下面的顺序做，能少走弯路。
第一步，确认阻断范围。 池化余额耗尽是全组一起停，还是只停了几个人，取决于你们把预算设在哪一层。GitHub 的预算可以设四个层级：user（单用户）、cost center（成本中心）、enterprise spending limit（企业整体消费上限）、organization（组织）。先去确认触发的是哪一层的上限，这决定了你能在哪一层去调。
第二步，别急着把用户预算清零。 这里有个很容易误操作的点：把某个用户的预算设为 $0 会立即阻断该用户。有些管理员在排查时想”先把嫌疑最大的人停掉止血”，一填 $0，那个人当场就用不了了——如果他正好在赶一个上线，这个操作的代价可能比省下的 credits 大得多。想限制而不是切断，就给一个小额度，不要填 0。
第三步，做一次分配决策而不是技术抢救。 如果这个月确实还要继续用，只能追加预算（按 $0.01/credit 扣减）；如果不追加，就得决定优先保谁。务实的做法是按交付节奏排：正在冲版本的小组保住，探索性、学习性的用途本月先停。这个决定越早宣布越好，让人知道自己这个月还能不能用，比让所有人反复试、反复撞墙强。
第四步，把话说清楚。 事故沟通里最容易漏的一句是”下个月 1 号会自动恢复”。额度是每个自然月 1 号重置的，不用申请、不用工单。很多团队的焦虑其实来自不知道什么时候能好。
归因：到底是谁、哪条链路在烧
止住血之后要做的是归因，否则下个月同样会烧穿。经验上，超额基本来自三类来源，值得逐一排查。
一是少数重度用户的长上下文习惯。 池化余额下，人均消耗的分布通常是很陡的长尾，前几名可能占掉大半。计费面板能看到按用户的用量分布，先看头部几个人的用法：是不是习惯性把整个目录塞进上下文、是不是反复让 agent 跑大范围重构。这类用法本身不一定是错的，但需要让当事人知道单次成本量级。
二是代码评审这条容易漏计的链路。 Copilot code review 有一个经常被忽略的计量：自 2026-06-01 起，code review 除了扣模型费用，还会同时消耗 GitHub Actions 分钟数。也就是说它踩在两张计量表上。如果你们把 code review 挂在了 PR 的自动触发上，一个改动频繁的仓库、一天几十个 PR，消耗会以一种没人盯着的方式持续累积。排查时优先看这一块的触发规则是不是”每次 push 都跑”。
三是模型选择。 credits 是按各模型 API 费率折算的，不同模型之间的单位成本差异很大。日常补全、写测试、改注释这类任务用便宜模型完全够用，把贵模型留给真正需要的复杂推理场景。这件事没有自动挡——前面说过，系统不会替你降级，只能靠团队约定和引导。关于各模型怎么在 Copilot 里切换和取舍，可以另看GitHub Copilot 怎么切换 Claude、Gemini 等模型。
顺带说一句大陆访问的前提：Copilot 里可选的模型来自多家厂商，这些厂商官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外。这跟你在 Copilot 里能不能选到某个模型是两回事，但如果团队还打算直接接这些厂商的 API 做自建工具，就需要提前把准入这一层想清楚，具体以各官网当前的地区政策页为准；本文不提供也不背书任何第三方中转渠道。
一个正在逼近的时间点：2026-09-01
这条对 Business / Enterprise 的既有客户尤其重要，也是当下最容易被忽略的一笔账。
按量计费上线后的头三个月（2026-06-01 至 2026-09-01），既有 Business / Enterprise 客户享受一份更高的促销额度：Business 3,000 credits/用户、Enterprise 7,000 credits/用户。促销结束后，会回落到标准的 1,900 / 3,900。
也就是说，如果你们团队 7 月的用量刚好卡在 3,000 credits/人上下，感觉”还行、没超”，那 9 月开始同样的用量就会直接超掉三分之一以上。这不是用量变多了，是额度变少了，而账单上不会有人提前提醒你。
现在能做的准备很简单：去 Copilot 计费面板看”预测用量”那个数。把它跟促销后的标准额度（1,900 / 3,900）比一比，而不是跟当前的促销额度比。如果按标准额度算已经超了，你有一个多月时间去调整——要么优化用法、要么现在就把预算和采购流程走起来，总比 9 月第一周全组被挡在外面好。
还有一条容易被误解的规则要一起说：未用完的额度不结转。有些团队会想”这个月省一点，攒到下个月赶工期用”，这个策略不成立，每个自然月 1 号清零重置。省下来的额度不会变成缓冲垫，所以与其攒，不如把用量在月内摊平——月初大手大脚、月末集体挨饿是最难受的曲线。
还有一部分人不在这套规则里
排查时如果发现有人的用量口径跟别人对不上，先确认他是不是还在老制度上。
月付 Pro / Pro+ 用户在 2026-06-01 已经自动迁移到 credits 制；年付 Pro / Pro+ 用户在计划到期前，仍然走 premium request 制。 这就意味着一个团队里可能同时存在两套计量口径，管理员按 credits 做的统计口径覆盖不到年付用户的那部分。
对还在老制度上的年付用户，有一个变化必须提醒：2026-06-01 起模型倍率上调了，其中 Copilot code review 的模型倍率是 13——每做一次 PR 或 IDE 里的代码评审，扣 13 个 premium request。如果年付用户按老习惯以为评审”扣一次”，实际额度会消耗得比预期快得多。前面提到的 Actions 分钟数消耗，对新旧两套制度同样适用。
这块的细节可以另看年付 Copilot 还在老计费上：倍率上调了哪些。
诚实说局限
这篇给的是处置顺序和排查方向，有几件事我没法替你确定：
- 具体额度数字会变。 上文各档的 credits 数来自第三方公开资料的汇总口径，GitHub 官方计费页可能与之有出入，也随时可能调整。做预算决策前，请以你们账号登录后看到的官方计费页为准。
- 不同组织的账单结构差别很大。 有没有 cost center、企业上限是谁在管、采购流程走多久，这些都会显著改变”追加预算”这一步的实际耗时。剧本里写的是逻辑顺序，不是保证一天能做完。
- 用量归因不可能做到精确到人到条。 面板给的是聚合视图，能定位到重度用户和大致的消耗结构，但没法告诉你”某次对话花了多少”。想做更细的核算，只能靠团队自己约定用法并记录。
小结
额度提前烧完不是技术故障，是分配问题：没有自动降级，超额就是阻断到下个自然月 1 号重置，当月只有止血和归因两件事可做。止血的顺序是先确认预算触发在哪一层，再决定追加还是保重点，注意用户预算填 $0 会当场把人切断。归因优先看三处：重度用户的长上下文习惯、code review 的自动触发（它同时消耗 Actions 分钟数）、以及贵模型的日常滥用。真正该提前动手的是 2026-09-01——Business / Enterprise 的促销额度到期后会从 3,000 / 7,000 回落到 1,900 / 3,900，现在就该拿计费面板的预测用量去对标准额度算一遍。额度不结转，所以别指望攒；把用量在月内摊平，比任何事后补救都有效。