GitHub 于 2026 年 9 月 16 日宣布 Copilot budget increase requests 一般可用。以往成员用尽 Copilot AI credits 后，会被阻止使用需要 credits 的功能；新流程让成员在达到上限时即时提出更多预算申请，并由有权限的人在设置页批准、调整或拒绝。
申请会自动送到负责支付该笔预算的 account。组织拥有的 budget 会出现在 organization settings，企业拥有的 budget 则出现在 enterprise settings。这个路由设计把用户的需求和实际付款责任连接起来，避免每个开发者自行处理额外用量，也让预算拥有者看到需求集中在哪些团队。
Organization owner、enterprise owner 或 billing manager 可以在 Requests from members 检视待处理申请，为每一宗设置新金额，再选择批准及增加。批准后，成员的 budget 会更新，AI credits access 会即时恢复。流程同时保留调整和拒绝选项，因此不等于用户达到上限后便自动获得无限制用量。
这项功能适用于 GitHub Copilot Business 和 GitHub Copilot Enterprise 的 usage-based billing。它不是模型更新，也没有宣称可以降低总支出；它解决的是 agent 和 AI coding tool 在实际工作中遇到额度上限时，如何在不中断工作和不放松支出控制之间取得平衡。
对采用 Copilot 的团队而言，预算申请其实是 agent governance 的一部分。当 AI 可以连续执行分析、修改和测试，credits 会变成工作流的限制和成本信号。把增加额度设计成有记录的批准事件，比直接开启更高的全局上限更容易追踪，也更容易比较不同团队的使用原因和结果。
部署前可以先定义预算 owner、申请响应时限、每个团队的额度、异常用量提醒和批准理由，并把 credits 消耗与已接受的代码变更、测试结果或交付时间一起检视。这些是运营建议，不是 GitHub 公告中的成效数据；真正的政策仍要按组织的付款、权限和风险要求设计。
同时要留意权限层级。能够批准 budget increase 的人，未必应该同时拥有 repository 写入、部署或 production access。预算恢复只代表可以继续使用 Copilot credits，不代表模型可以取得更多数据或执行更多 action。把 billing、code permissions 和 deployment approvals 分开，能减少单一账户承担过多权力。
这次更新反映企业 AI 正进入更细致的运营阶段：成本控制不再只是月底看账单，而是成为 agent 执行过程中的即时决策。GitHub 提供了请求、审批和恢复 access 的产品流程，企业仍要自行量度每次增加预算带来的实际价值、错误率和风险，才能决定哪些工作值得继续放大。
