登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  业界新闻

GitHub Copilot 政策与计费即将调整:团队如何核对模型用量和预算边界

来源:17golang原创

时间:2026-08-29 11:54:46 256浏览 收藏

如果团队准备在 9 月继续扩充 GitHub Copilot 席位,真正需要提前核对的不是“价格会不会涨”,而是席位何时收费、超出包含用量后谁能继续使用,以及代码审查的默认投入会不会改变。GitHub 在 2026 年 8 月 28 日公布了三组即将生效的调整,价格本身并未改变,但管理员的预算和策略检查要前移。

最稳妥的做法是先把席位、AI 用量报告和组织级策略列成一张核对表,再决定是否保留 Default;不要把“价格不变”理解成“预算不变”。

要点速览

  • 2026 年 9 月 1 日起,信用卡或 PayPal 付费的新 Copilot Business、Enterprise 注册将逐步重新开放。
  • 新分配席位需要先支付该席位费用;10 月 1 日起,现有相关客户进入下一个账期时也会按分配席位预先计费。
  • 包含用量之外的使用可能产生额外费用,但价格、Spend controls 和用量跟踪仍保留。
  • 9 月 28 日起,Copilot code review 中 Default 的默认投入级别从 Lite 变为 Balanced。

三项变化分别影响哪一层

这次公告把三个容易混在一起的动作放在同一页:Business/Enterprise 的计费行为调整、github.com 与移动端的 Copilot 体验合并、代码审查的默认 effort level 改变。它们影响的对象不同:第一项落在账单和席位,第二项落在访问策略和数据保留,第三项落在自动请求的审查成本与时延。

公告明确写出 Business 和 Enterprise 的价格不变,撤销席位也不会在当月产生按比例退款;账期中途新增席位仍按分配日至账期结束计算。因此管理员要看的不是一个单价,而是“席位数量 × 分配时间 × 包含用量”的组合。

GitHub Copilot 席位分配、包含用量和超额费用之间的预算核对链路

先把 Copilot 席位和用量报告对上

最小核对路径可以压缩成四步:统计当前 Business 或 Enterprise 席位,标出账期中途新增和即将撤销的席位;打开 billing settings 中的 AI usage 页面,下载 AI usage report;按模型查看 input、output、cache read 和 cache write tokens;最后把超出包含用量的团队、仓库和高频模型列入预算复盘。

GitHub 在 8 月 11 日已经为用量报告增加了按模型的 token 拆分。这个字段的价值在于解释 AI credits 到底被什么消耗,而不是用一张总量图猜测费用来源。注意,额外使用是否继续可用仍取决于账号的购买和 Spend controls 设置,不能仅凭一行 token 数量推断最终账单。

核对表:
席位数 -> 分配日期 -> 包含用量 -> 模型 token 明细 -> 额外使用设置 -> 负责人确认

统一体验上线前检查访问策略

不早于 2026 年 9 月 28 日,Copilot cloud agent、github.com 上的 Copilot Chat 和 GitHub Mobile 中的 Copilot Chat 将合并为单一体验,并默认启用。原本分开的策略会替换成统一策略,github.com 的聊天数据保留期也会从 28 天调整为账号存续期,这对企业合规审查比界面变化更重要。

Business 和 Enterprise 管理员应在上线前查看 Copilot settings,进入 Copilot cloud agent 的策略选项,确认团队是否接受统一体验。公告给出的关键边界是:不需要操作就能继续使用,但如果主动退出统一体验,github.com 和 GitHub Mobile 上的 Copilot 访问会在上线后失效。不要把“默认启用”当成“所有人自动获得更高权限”,权限仍受组织和企业策略约束。

代码审查的 Default 为什么值得单独验收

Copilot code review 的 Default effort level 将从 Lite 变为 Balanced,生效时间同样是 2026 年 9 月 28 日。组织和仓库都可以设置默认值:组织默认值覆盖没有单独配置的仓库,仓库默认值作用于自动请求的审查;手动请求审查时,则可以在 Pull Request 的 Reviewers 栏选择投入级别。

如果团队当前希望保持 Lite,不要只记录口头约定,而应在组织或仓库设置中显式选择 Lite。这样 Default 的全局变化不会覆盖明确选择。上线前抽查几类仓库:有组织默认值但没有仓库覆盖的仓库、已经固定 Lite 的仓库,以及经常手动请求审查的关键仓库。

Copilot 统一策略与代码审查 Default 变为 Balanced 的迁移验收关系

团队现在可以执行的最小迁移顺序

  1. 冻结基线:保存当前席位、账期、Spend controls、用量报告和代码审查默认值,标注数据负责人。
  2. 检查账单:把 9 月新席位的预付影响和 10 月 1 日后的账期变化放进预算,而不是只复制旧单价。
  3. 检查策略:在 Copilot settings 中核对统一体验选择,并确认数据保留变化是否需要补充内部说明。
  4. 显式固定审查投入:对不接受 Balanced 的组织或仓库直接选 Lite,对接受变化的仓库记录一次 Pull Request 审查结果。
  5. 复盘用量:用按模型 token 明细解释 AI credits 变化,给超额使用设置负责人和上限,而不是等月底看总账。

常见问题

Copilot Business 和 Enterprise 这次要涨价吗?

GitHub 公告称价格不变,但席位预付、超出包含用量的额外支付和账期分配方式会影响实际预算。

撤销席位能退回当月费用吗?

公告说明撤销席位不会产生按比例退款,移除会体现在下一个月度账期。

代码审查一定会从 Lite 变成 Balanced 吗?

只有仍使用 Default 的组织或仓库会随默认值变化;如果提前显式选择 Lite,GitHub 表示会保留该选择。

统一 Copilot 体验需要管理员手动开启吗?

公告称上线后默认启用,但管理员应在 Copilot settings 中复核策略;主动退出会影响 github.com 和 GitHub Mobile 的访问。

把新闻变成可追踪的管理员事项

这次调整的核心不是某个新按钮,而是默认策略开始同时影响账单、数据保留和审查投入。团队只要把“席位账期”“模型用量”“统一体验”“代码审查默认值”分开留痕,9 月 28 日和 10 月 1 日两个时间点就不会混成一次模糊升级。后续若 GitHub 更新公告,按同一张基线表复核差异即可。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>