GitHub Copilot席位改为先付费：取消后也不按比例退款

GitHub 8月28日公告 写明，从2026年9月1日起，公司开始逐步恢复使用信用卡或PayPal付款的Copilot Business与Copilot Enterprise新客户自助注册。新分配席位必须先完成付款，用户才能获得访问权限；现有相关客户则从10月1日起，在账单周期开始时为当时已分配的全部席位预付费用。

截至9月1日，准确状态是恢复流程已经启动，并不意味着所有新账户、地区和购买渠道都已立即开放。ReleaseBytes的同期记录 也把变化概括为新客户席位先付费、现有客户转向周期初预付；对团队而言，关键不是席位标价上涨，而是扣款时间提前，月中撤销席位也不能换回当期未使用费用。

新客户与现有客户分两步转为预付

第一阶段只涉及使用信用卡或PayPal付款的Copilot Business与Enterprise新客户自助注册。恢复采用逐步重新启用的方式，并伴随更严格的账户审核，因此不能理解为面向所有客户和采购方式的全面同步开放。

新流程把付款与访问开通直接连接起来：每个新分配席位先产生费用，随后用户才能使用Copilot。进入后续账单周期后，周期开始时仍处于分配状态的席位会统一产生预付费用；月内后来增加的席位再单独结算。

现有的信用卡或PayPal客户将在适用的新账单周期进入同一预付机制。其他合同采购、销售代表协助购买或不同付款渠道是否采用完全相同的切换安排，目前没有足够公开信息支持一概而论。

新增、移除和撤销对应不同账单结果

GitHub许可证变更文档 区分了席位增加、移除与立即撤销：月中新增席位按分配日至本周期结束的剩余时间收费；移除席位要到下一周期才降低账单基数，当期未使用时间不退款。普通取消分配后，用户可继续使用至周期结束；若管理员直接撤销席位，访问会立即终止，但当期计费仍到周期末才停止。

第一种条件化场景是席位数量保持稳定。假设单席位月费为P，团队在周期开始时有100个已分配席位，周期初就会产生100P费用；名义席位成本未必改变，但资金离账时间前移。

第二种场景是团队在月中增加10个席位。新增部分按剩余周期计费，不会一律产生完整的10P月费；若所有席位恰好在周期中点分配，可近似计为5P，实际金额仍取决于分配日期和账单周期长度。随席位附带的包含用量也可能按照相同周期比例调整。

第三种场景是月中撤销10个已经预付的席位。当前周期不会退回这部分席位剩余时间对应的费用，席位基数到下一周期才下降；立即撤销改变的是访问状态，而不是已经形成的当期账单。

席位预付也不代表当月总费用封顶。团队用量超过计划所含额度后，继续使用Copilot可能需要额外付款；这部分支出独立于席位预付费用，现有的支出控制、用量跟踪和额外AI credits购买能力仍会保留。

价格没有上涨，现金流仍会改变

Copilot Business与Enterprise的席位价格没有随此次调整改变，但企业需要在周期开始时一次性覆盖全部已分配席位，并为月内扩编和超额AI用量预留空间。对于席位长期稳定且不产生额外用量的团队，名义年度席位支出可能不变，付款节奏却会明显前移。

人员流动较大的团队受到的影响更直接：周期开始后才发现闲置席位，即使马上撤销，也不能收回本期余款；项目中途扩员时，新席位又会立即产生按比例费用。因此，仅看周期末活跃人数无法解释当期账单，还要结合周期初席位数、月内新增日期以及额外用量。

以条件化算例计算：团队周期初为100席支付100P，月中新增10席产生约5P，同时撤销10个原有席位，本周期席位支出约为105P。虽然周期末仍是100席，但新增费用已经发生，撤销席位又没有当期退款；多出的5P来自计费时点和退款规则，而不是单价上涨。

恢复速度与实际账单呈现仍待观察

目前已经明确的边界包括：信用卡或PayPal新客户的自助注册逐步恢复，新席位须在开放访问前付款；现有相关客户随后进入周期初预付；月中新增继续按比例收费，撤销或取消不退还当期未使用费用。

尚不明确的是恢复流程覆盖全部符合条件新账户的速度，以及不同账户在结算页面和发票中会如何呈现预付席位、月中新增和超额用量。最终金额仍由周期初已分配席位、月内席位变化、包含用量折算及额外AI用量共同决定。

这项变化更准确的含义不是Copilot企业席位涨价，而是付款时间提前，已经发生的当期支出不会因月中撤销而按比例退回。接下来需要观察自助注册的实际覆盖范围，以及现有客户切换后的首批周期账单如何列示这些费用。