Copilot 用量 API 纳入 BYOK：本地模型用量终于能从总额里剥出来

要点

• 2026-11-03，GitHub 给 Copilot 用量指标 API 加了两个维度：本地 BYOK 用量与企业自定义模型用量，依据 官方 changelog 原文。
• 本地 BYOK 指的什么（官方定义）：开发者在客户端自己配的 provider key，以及由 Ollama、Foundry Local、LM Studio、llama-server 这类工具提供的本地模型。请求从 Copilot CLI 或 Copilot app 直接打到你自己的端点，不经过 GitHub。
• 新增字段：用户级 used_local_byok（当天是否有过本地 BYOK 请求）、totals_by_local_byok（会话/请求/prompt/token 计数，按 byok_kind 与 surface 拆分）；聚合级 daily_active_local_byok_users / weekly_… / monthly_…。
• 拆分维度：byok_kind 取 local_managed / local_user / local_auto / remote_user；surface 取 copilot_cli / copilot_app。
• 企业自定义模型：totals_by_client[].totals_by_model[] 上新增布尔字段 is_custom_enterprise_model。这类请求由 GitHub 服务端观测，覆盖所有客户端（包括 IDE）。
• 同一模型可同时出现在两处：既作 Copilot 托管模型又作自定义模型时，会显示为两条独立条目，计数不合并。
• 官方明写「既有总额不变」："No change to existing totals"——本地 BYOK 本就是 totals_by_cli / totals_by_copilot_app 的子集，自定义模型用量本就在 totals_by_client 里。这次加的是拆分维度，不是新增计数。
• 本地 BYOK 是「下界」不是精确值：官方原文 "Local BYOK fields rely on client telemetry, so they undercount when telemetry is disabled." 且部分本地 provider 不报 token 用量，token 数可能偏低；企业自定义模型是服务端观测，没有这个问题。
• 覆盖范围：企业级与组织级报告、用户级与聚合级、1 天与 28 天窗口。历史数据不回填（发布日之前的报告没有 is_custom_enterprise_model）。
• 可见性门槛：企业 owner、企业账单管理员、组织 owner，或持有 View Copilot Metrics 权限的自定义角色；且必须已启用 Copilot 用量指标策略。

背景与分析

这条补的是「本地推理到底算不算钱」那个洞

10-28 GitHub 宣布 Copilot Fusion 开始路由本地模型 时，留下了一个很实际的问题：当请求落到你自己的本机模型上，Copilot 的用量报表里还能不能看清它在哪、花了多少？

当时的答案是「看不清」——本地模型和 Copilot 托管模型经常同名，用量混在总额里。这条公告就是来补这个洞的。官方把动机写得很直白："BYOK usage used to blend into Copilot-hosted totals, because local and custom models often share names with Copilot models."

四个字段组合起来，能回答四个问题

官方给的「Why this matters」四条正好对应这四行：治理（对着 BYOK 策略核谁是自带的 key）、成本归因（把 Copilot 托管用量与自己 provider 计费/免费本地模型分开）、跨工具统一视图、效率对比。

三个必须收窄的口径（官方自己写的）

这条最容易写成「现在能精确统计本地用量了」，而官方原文恰恰在反方向提醒:

① 关掉遥测就少记。 本地 BYOK 的字段来自客户端遥测。企业里为合规关掉 telemetry 的机器，这部分用量在报表里会偏低甚至缺失。这不是 bug，是采集方式的必然结果。

② token 数可能偏低。 有些本地 provider 根本不返回 token 用量。请求数可能准，token 数不一定。

③ 本地 BYOK 不按模型名拆。 官方原文 "Local BYOK usage isn't broken out by model name."——你能知道「有人用了本地模型」，但不能从这份报表知道「用的是哪个本地模型」。

结论很硬：这份数据适合做治理与趋势，不适合做账单或计费依据。 要精确知道本地花了多少，只能去你自己的 provider 侧看。

与 10-28 那条的分工

把两条公告放一起，逻辑是完整的：

• 10-28：能力侧——允许把请求路由到本机模型，并明确「BYOK 添加的模型不会自动获得 Fusion 路由资格」。
• 11-03：观测侧——能看见哪些请求走了本地 BYOK、哪些走了企业自定义模型。

先给能力，再给观测，这个顺序对采购评估很重要：10-28 时团队没法回答「开了本地路由我怎么管」，现在至少有了数据来源。但观测只到「有没有、多少」，不到「哪一个」。

对开发者的影响

• 企业管理员第一件事：先去确认 Copilot 用量指标策略开着。没开策略，字段再多也拉不到数据。
• 别拿它做计费。本地 BYOK 是下界，token 数还可能缺；要算账去自己的 provider 后台。报表用来发现异常，不用来对账。
• 同名模型会重复计数到两条，做 BI 看板时别把 totals_by_model 直接求和，否则托管模型和自定义模型会重复累加。
• 历史数据没有回填，想建趋势线的，从 2026-11-03 之后开始画，别拿之前的数据补齐。
• 个人用户基本无感：这套字段只在企业/组织级用量 API 里出现，个人订阅拿不到，也管不着。

AI 之家 观点

这条公告的分量不在「加了几个字段」，在于它承认了 BYOK 的一个长期事实：本地模型的用量，从来都是估算。

官方三句话把边界划得很清楚——依赖客户端遥测、provider 可能不报 token、不按模型名拆。这三条加起来意味着：任何拿这份报表做「本地推理更省钱」论证的做法，都会系统性地低估本地用量。 而低估的方向恰好对 BYOK 有利，这是个容易自我强化的偏差。

我们的建议很直接：把这份数据当「治理信号」，不当「成本真相」。 它的正确用法是发现「谁在绕过组织策略用自己的 key」「哪个团队的 BYOK 比例异常升高」；错误用法是拿它算 ROI。

另一条值得记的：GitHub 这次没有改任何既有总额。 这一点在企业里其实很重要——上游悄悄改了统计口径、导致历史看板断崖，是数据团队最常见的坑。官方明确写「No change to existing totals」，等于给既有报表发了个不破坏承诺。

相关阅读

• GitHub Copilot 工具卡——AI Credits 计费、预算管控与模型策略的完整口径
• Copilot Fusion 开始路由本地模型——能力侧的上一环，与本条配套看
• GitHub Copilot Automations 转共享——自动化用量的归因是同一套治理思路
• Copilot SDK 服务端认证——app_client_id 归因，与本条同属「把用量拆清楚」这条线

来源

• ⭐ BYOK and enterprise custom models in the Copilot usage API（GitHub Changelog 官方，2026-11-03）
• Copilot usage metrics API 官方文档（公告给出的入口）
• Copilot Fusion 本地模型路由（GitHub Changelog 官方，2026-10-28）

取证边界：本文事实来自 GitHub Changelog 官方原文，字段名、维度取值与三条限制均为官方原措辞。本文未调用该 API、未拉取真实报表（需企业/组织级权限），因此「字段在实际响应里的嵌套位置」「遥测关闭时的偏差幅度」「同名模型双条目的实际呈现」均为官方声明，不是本站实测。三处限制的严重程度官方未给量化数据，本文不作估计。