用量和计费
说明 request、premium request、allowance、budget、billing entity 和 GitHub 2026 usage-based billing 迁移边界。
📖 本篇术语速查表
| 英文 / 缩写 | 中文 | 一句话解释 |
|---|---|---|
| Usage & billing | 用量计费 | Copilot 的成本和计费方式。 |
| 成本控制 | control | 限制和监控开销。 |
| 配额 | quota | 各档位的用量上限。 |
不想读完？把下面这段提示词丢给 AI 帮你跑完——帮你看懂 Copilot 的用量计费、控住团队成本。
你是 Copilot 用量计费顾问。
【角色】
Copilot 用量计费顾问，按最小够用、安全优先的原则给可落地方案，每条结论都落到能照做的步骤或示例，不停留在空泛建议。
【输入】
- 团队规模和档位：___
- 最担心的成本项：___
- 是否有预算上限：___
- 用量监控需求：___
- 经验水平：___
【工作流程】
1. 梳理计费构成
2. 标出主要成本来源
3. 给成本控制手段
4. 说明怎么监控用量
5. 给验证
【输出规范】
▌一、计费构成
▌二、成本来源
▌三、控制手段
▌四、用量监控 + 验证
【硬约束】
- 价格 / 配额以官方为准
- 按预算设监控和上限
- 敏感账单信息不外泄
- 不要替我臆测情况或编造不存在的功能，信息不全先问清
- 不确定的配置或权限一律以官方文档为准，禁止照搬过时写法
- 给的每条结论都要落到具体可照做的步骤或示例，不停留在「建议」「考虑一下」这类没法直接执行的空泛表述Copilot 计费不能只看“有没有开通”。真实成本来自七个维度：功能入口、模型、premium requests（高级请求）、budget（预算）、allowance（额度）、billing entity（计费主体）和即将迁移的 usage-based billing（基于用量的计费）——少看一个维度，月底就会有"为什么这么贵"的疑问。
结论：教程里不要写死价格和额度；要写判断框架和官方核验路径。
GitHub 官方 requests 文档说明：从 2026-06-01 起，Copilot 正从 request-based billing 迁移到 usage-based billing。具体价格、模型 multiplier 和 plan allowance 必须回官方页面核验。
1. Request 和 premium request
GitHub 官方定义中，request 是你让 Copilot 做事的一次交互，例如发 prompt、触发 chat response、让 extension 帮忙。
Premium request 是使用更高阶处理能力的请求，消耗量会随功能和模型变化。
flowchart TD
Prompt["用户发起一次任务"] --> Request["request"]
Request --> Basic{"included model / included interaction?"}
Basic -->|是| Included["不消耗或低成本"]
Basic -->|否| Premium["premium request"]
Premium --> Model["model multiplier"]
Model --> Budget["allowance / budget / billing entity"]
Budget --> Report["usage report / analytics"]
style Premium fill:#fef3c7,stroke:#d97706,stroke-width:2px
style Budget fill:#fee2e2,stroke:#dc2626,stroke-width:2px2. 哪些功能可能消耗 premium requests
官方 requests 页面列出的 premium features 包括：
- Copilot Chat。
- Copilot CLI。
- Copilot code review。
- Copilot cloud agent。
- Copilot Spaces。
- Spark。
- OpenAI Codex VS Code integration preview。
- Third-party coding agents preview。
不要只盯 Chat。团队一旦开始使用 CLI、cloud agent、code review 或第三方 agent，成本结构会变复杂。
3. 预算和 allowance
要区分四个词：
- Allowance：计划中包含的额度，通常按月重置。
- Budget：你设置的额外支出控制和告警。
- Premium request paid usage policy：组织或企业是否允许超出 allowance 后继续产生费用。
- Billing entity：当用户来自多个组织或企业时，费用计到哪一方。
官方文档还说明，premium request counters 在每月 1 日 00:00:00 UTC 重置；未使用额度不会结转到下个月。
4. 用户应该怎么看用量
官方监控页面给出的入口包括：
- 在 IDE 中查看用量。
- 在 GitHub Billing and licensing settings 里看 overview。
- 用 Premium request analytics 查看详细数据。
- 下载 usage report。
VS Code、Visual Studio、JetBrains、Xcode、Eclipse 都有各自的用量入口。团队教程里不需要逐个截图，重点是让用户知道用量不是猜的。
5. 管理员应该怎么控成本
建议：
- 默认启用 included models，限制高成本模型默认开放。
- 为高级模型和 premium features 建 budget。
- 设置 75%、90%、100% 告警。
- 监控同一 prompt 反复重试、大上下文请求、agentic session 和 code review。
- 对 CLI、cloud agent、third-party agents 建独立复盘项。
- 多组织用户必须明确
Usage billed to，否则 premium requests 可能被拒绝。
6. 解释成本时不要犯的错
- 不要把一个月的 allowance 当成永久额度。
- 不要把 included model 当成永远免费，官方模型列表会变化。
- 不要把 prompt 次数等同于最终费用，model multiplier 会影响消耗。
- 不要忽略 cloud agent session 和 steering comments。
- 不要用旧 request-based 口径解释 2026-06-01 之后的新 usage-based billing。
深读：为什么教程不写具体价格表
价格、模型 multiplier、included models、plan allowance 和 preview 状态都可能变化。教程写死数字很快会变成错误信息。
商业级教程应该写稳定判断：在哪里看、怎么分层、怎么设预算、怎么解释异常，而不是复制一张会过期的价格表。
本章自检
- 是否知道哪些功能会消耗 premium requests？
- 是否知道当前模型是否有 multiplier？
- 是否设置 budget 和超额策略？
- 多组织用户是否选择了 billing entity？
- 是否准备迁移到 usage-based billing 口径？
通过标准：团队能从官方 billing/analytics 页面解释用量来源，而不是月底才猜。
官方来源
- Requests in GitHub Copilot —— GitHub 官方 request、premium request、allowance、model multiplier 说明。
- Monitoring your GitHub Copilot usage and entitlements —— GitHub 官方用量查看和优化建议。
- Usage-based billing for organizations and enterprises —— GitHub 官方 usage-based billing 迁移入口。