年付 Copilot 还在老计费上：倍率上调了哪些
数据截至 2026-07，价格与限额以各官网为准。
如果你是按年付费买的 Copilot Pro 或 Pro+，那么从 2026-06-01 开始，你和你的月付同事其实活在两套完全不同的计费制度里——他们已经被迁到 AI Credits 的按用量计费上，你还留在旧的 premium request 计数上，而且旧制度的模型倍率在同一天被上调了。 这不是一句”计费方式微调”就能带过的事：两套制度的额度单位不同、超额行为不同、连你在网上搜到的教程适用对象都不同。搞不清自己站在哪一边，最直接的后果就是你按别人的经验估预算，估出来的数是错的。
先承认一个很常见的误解：不少人以为 2026-06-01 的变更是”全员一刀切换”，看到官方博客标题写着 Copilot 转向 usage-based billing，就默认自己账号里的 premium request 计数已经作废了。实际情况是分批的——月付 Pro / Pro+ 在那一天自动迁移，年付用户则在当前订阅周期到期之前继续走旧制度。也就是说，同一个月里你可能看着一份还在按”次”扣的额度，同事看着一份按美元扣的余额，两个人对着同一篇文章讨论半天，结论都对不上。
分界线到底划在哪：谁走新制，谁走旧制
把规则拆开看其实很清楚，只有两条：
- 月付 Pro / Pro+：2026-06-01 自动迁移到 AI Credits 制。
- 年付 Pro / Pro+：在计划到期前仍走 premium request 制，到期后才进入新制度。
所以判断自己在哪一边，不用去猜，也不用看模型名或者插件版本，只看一件事：你这笔订阅是按月扣的还是按年扣的。年付的人到期日在哪一天，那一天就是你的制度切换日。
这个分界线之所以重要，是因为它决定了你该看哪套文档。GitHub 现在把 premium request 相关的说明归到了”legacy（旧制）“标题下——文档还在，但它明确是给存量用户看的历史制度。你如果是年付用户，那篇 legacy 文档才是当下对你生效的规则；反过来，如果你是月付，再去研究 premium request 怎么算就是白费功夫了。
新制度长什么样：先看一眼你到期后会落到哪
哪怕你现在还在旧制上，也值得先了解一下新制，因为到期那天你会被直接推过去，没有缓冲期。
新制的核心是 GitHub AI Credits 取代了 premium requests，1 credit = 1 美分（$0.01）。用量不再按”请求次数”数，而是按 token 消耗算——输入 token、输出 token、缓存 token 都计，按各模型的 API 费率折算成 credits 扣。
各档包含的额度，按第三方公开资料的汇总口径大致是这样（这几个数字来自第三方汇总，GitHub 官方 pricing 页未逐字核对，请以官方计费页为准）：
| 计划 | 月费 | 包含额度 |
|---|---|---|
| Pro | $10/月 | 含 $15 credits |
| Pro+ | $39/月 | 含 $70 |
| Max | $100/月 | 含 $200 |
| Business | $19/用户/月 | 约 1,900 credits/用户 |
| Enterprise | $39/用户/月 | 约 3,900 credits/用户 |
可以看出一个规律：付费档的基础额度大致等于甚至略高于它的价格，GitHub 另外还叠了一份浮动的 flex 额度，所以实际总额可能比表上更高。Business / Enterprise 走的是组织池化余额，不是每人一个独立小钱包。
从”按次”换成”按 token”，最实际的影响是：同样一次对话，成本不再是固定的。你甩一个几千行的文件进去让它重构，和你问一句”这行报错什么意思”，在旧制里都算一次请求，在新制里差出来的可能是几十倍。想控成本的方向也随之变了——从”少提问”变成”少喂无关上下文”。
年付用户真正要盯的两处变化
回到旧制。GitHub 并没有让年付用户原地不动，2026-06-01 起对仅年付用户做了模型倍率上调。这里必须说清楚一件事：能明确点出具体数字的，目前只有一项——
Copilot code review 的模型倍率是 13，也就是说每触发一次 PR 评审或 IDE 里的代码评审，扣掉 13 个 premium request。
其他模型各自调到了多少，这篇不替官方列表，以你账号里当前生效的官方倍率表为准。我不想凭印象给你一张看着完整、实则可能已经错了的倍率表——倍率这种东西，写错一个数，你按它做的预算就整个歪了。你要做的是打开 Copilot 的用量/计费页面，对着当前列表核一遍你常用的那几个模型。
第二处变化更容易漏，因为它根本不在 Copilot 的额度里体现：code review 自 2026-06-01 起同时消耗 GitHub Actions 分钟数。
这意味着一次代码评审现在是双重计量——既扣 13 个 premium request，又吃掉一段 Actions 分钟。如果你的仓库本来 Actions 分钟就用得紧（CI 跑得勤、矩阵构建多），那么”这个月 CI 怎么突然不够用了”的答案可能就藏在这里，而不是你的流水线配置出了问题。
对年付用户来说，这两条合起来的结论很直白：code review 是当前旧制下单次成本最高的功能之一，13 倍不是小数目。如果你习惯每个 PR 都点一下自动评审，一个月下来的额度消耗会比你预期的高不少。合理的做法不是彻底不用，而是分场景用——核心逻辑改动、外部贡献者的 PR、涉及安全边界的改动，值得让它评一遍；改个文案、调个配置、纯格式化的 PR，人眼扫一下就过了，没必要为它花掉 13 个额度加一段 Actions 分钟。
额度用完会怎样：新制的四层预算和”没有降级”
到期切到新制之后，超额逻辑跟旧制不是一回事，这块提前知道能避免踩坑。
新制下管理员用美元预算控制超额，按 $0.01/credit 扣减——换算很直接，$10 预算就是 1,000 credits。预算可以设在四个层级上：user、cost center、enterprise spending limit、organization。
几条容易吃亏的规则：
- 把某个用户的预算设为 $0，会立即阻断该用户。这不是”降级到低配”，是直接用不了，做权限收紧时要留意别顺手把人锁死。
- 额度耗尽时没有自动降级到便宜模型的机制。旧印象里”用超了就自动切个小模型继续用”在这里不成立——如果不允许超额，就是直接阻断到下个计费周期。
- 未用完的额度不结转，每个自然月 1 号重置。所以”这个月省着点，攒到下个月大改一波”的策略是无效的，省下来的直接清零。
最后一条尤其影响用法节奏：既然不结转，那把重活均匀摊到每个月，比攒起来集中爆发更划算。
团队管理员：促销额度 2026-09-01 到期，现在就该去看那个数
这一节跟年付个人用户关系不大，但如果你同时管着团队订阅，这是当下最有时效性的一件事。
既有的 Business / Enterprise 客户在转按量计费的**头三个月（2026-06-01 至 2026-09-01）**享受更高的促销额度：Business 3,000 credits/用户、Enterprise 7,000 credits/用户。促销一结束，就回落到标准的 1,900 / 3,900。
这个落差不小——Business 从 3,000 掉到 1,900，相当于少了约三分之一；Enterprise 从 7,000 掉到 3,900，几乎腰斩。危险之处在于：你团队过去两个月的用量体感，是在促销额度下形成的。如果大家用着没觉得紧张，那种”够用”的感觉很可能是促销撑出来的假象。
具体建议是：在 9 月之前，打开 Copilot 的计费面板去看”预测用量”那个数字。那个数基本就是你 9 月账单要面对的量。拿它跟回落后的 1,900 / 3,900 一比，缺口有多大一目了然。如果确实超了，你有两个月时间做选择——是加预算、是收紧高倍率功能的使用、还是调整团队的模型使用习惯，都比 9 月账单出来之后再救火从容得多。
到期切换前，年付用户可以先做的三件事
不用等到期那天才手忙脚乱，有三件事现在做就有用：
第一，先摸清自己的用量结构。 在旧制下你能看到的是 premium request 的消耗次数，重点看两个方向：哪些功能吃掉了大头（code review 是不是占了很大比例），以及你的日常提问是”小而多”还是”大而少”。这个结构直接决定了你切到按 token 计费之后是变贵还是变便宜——小而多的提问在新制下通常更划算，大上下文的重活则相反。
第二，把 code review 的触发方式改成有选择的。 前面算过，13 倍加上 Actions 分钟，是当前旧制下最值得管理的一项开销。别一刀切关掉，按 PR 类型分流就行。
第三，别照着旧文章估新预算。 网上大量讲 Copilot 计费的文章还停留在 premium request 时代，那些”一个月 300 次够不够用”的经验，在按 token 计费的新制下没有换算关系可言。到期后请重新观察一两个计费周期，用你自己账号里的实际 credits 消耗来定预算，这比任何二手估算都准。
这套判断不适用的场景
也说说局限。上面的分析建立在你能看到自己账号计费面板的前提上——如果你用的是公司统一采购、你个人看不到用量明细的席位，那么这些估算方法你执行不了，只能找管理员要数据。
另外，本文引用的各档 credits 数字来自第三方公开资料的汇总口径，方向和量级可以参考，但别拿它去做财务测算。真要报预算，请以 GitHub 官方计费页当次显示的数字为准。倍率表同理——除了明确的 code review 倍率 13，其余项请自行对照官方列表核实，我不做补全。
计费规则本身也还在动。2026-06-01 是一次体制性变更，促销额度 9 月又要回落，这种密度下任何一篇文章的保鲜期都有限。养成一个习惯比记住任何具体数字都有用：每次要做跟成本相关的决定之前，先去计费面板看一眼当前的实际数。
相关阅读
- GitHub Copilot 五档套餐怎么选？含「高级请求」额度说明
- GitHub Copilot 怎么切换 Claude、Gemini 等模型
- GitHub Copilot Coding Agent 怎么用
小结
年付 Copilot 用户目前处在一个尴尬的过渡位：一边留在旧的 premium request 制上，一边又承受了 2026-06-01 起的倍率上调。要盯的具体变化其实只有两条——code review 倍率为 13，以及 code review 同时开始消耗 GitHub Actions 分钟数，这两条叠加让自动评审成了当前最值得精打细算的功能。到期切换到 AI Credits 之后，规则会换一套逻辑：1 credit = $0.01、按 token 计量、额度不结转且用完不自动降级。团队管理员还要额外记一个日期，促销额度 2026-09-01 到期后 Business / Enterprise 会回落到 1,900 / 3,900，现在就该去计费面板看预测用量。所有具体数字请以 GitHub 官方计费页为准，本文只帮你把该看哪、该盯什么理清楚。