Michael Johnson如果开发者通过第三方工具调用 Copilot，常规 IDE 统计数据可能无法显示请求来自何处。2026 年 10 月 23 日，GitHub 在 Copilot usage metrics API 中新增了 totals_by_client 字段，按客户端汇总模型使用情况，包括 OpenCode、Claude Code、Codex 和 Zed。对于管理员来说，这让他们能够了解编辑器之外的部分活动，并更准确地讨论内部 AI 使用规则。
新增统计维度包含哪些内容
totals_by_client 中的每个条目都包含客户端、成功的模型调用次数、会话数，以及 prompt 和 output 令牌总量及每次调用的平均令牌数。嵌套的 totals_by_model 会按模型拆分这些指标，并显示选择模式：用户直接选择了模型、系统自动选择了模型，或由产品指定模型。
该字段已加入企业、组织以及这些层级下用户维度的一日和 28 日报告。在汇总的 28 日报告中，每一天都会提供客户端细分数据。这是一项兼容性扩展：原有字段保持不变，没有数据时数组为空。GitHub 在新增 usage metrics 维度的公告中介绍了详情。
这些数据能回答哪些问题
团队可以比较通过不同工具产生的请求量和令牌量，并据此决定应该支持哪些集成，或将哪些集成纳入企业规则。例如，如果报告中 OpenCode 的占比上升，可能意味着开发者正在 IDE 之外将 Copilot 用作模型提供方。对照客户端和模型，还能帮助确认实际造成主要负载的是哪些模型。
进行预算分析时，可以先查看令牌数和调用次数，再对照现行计费条件。request_count 统计的是模型调用，而不是用户提示：一次提示可能触发多次调用。因此，该字段适合分析模型服务负载，但不能直接用于统计开发者的交互次数。
如何将这项指标纳入工作流程
- 确认访问权限。必须启用 Copilot usage metrics 策略。获授权的企业或组织所有者、计费管理员，以及拥有相应指标查看权限的角色可以获取报告。
- 比较相同时间段。使用一日报告检查启用工具后的变化，使用 28 日报告观察较稳定的活动分布。在每份报告中分别查看调用、令牌和会话：它们是负载的不同衡量维度。
- 设定调查阈值。例如，当某客户端的令牌或调用占比相较于其自身上一统计期明显上升时，将其标记出来。根据自身要求和基准负载设定阈值；GitHub 没有规定通用阈值。
- 将报告与访问设置对照。新增细分数据可作为讨论工具支持和管理的依据。报告反映的是已记录的使用情况，不能替代权限检查或集成清单盘点。
官方的Copilot usage metrics API 文档介绍了报告、权限要求和可用的统计维度。自动化之前，请在文档中核实所需报告的最新结构，并使用相应的访问权限。
客户端标签意味着什么
GitHub 根据工具随请求传递的 integration ID 来识别客户端。GitHub 明确表示，这种分组只能近似识别：该值有助于汇总流量，但本身不能证明用户身份或应用的真实性。未知客户端会归入 other，无法规范化的值可能显示为 unknown。
此外还有一些特殊情况：Copilot code review 和 Copilot cloud agent 的调用会采用 product_selected 选择模式，因为模型由产品选择；对于 code review，模型可能显示为 unknown。比较不同工具的模型统计数据时，需要考虑这一点。
总的来说，totals_by_client 填补了通过外部工具发起的 Copilot 服务器端调用统计方面的空白，为管理员分析负载和决定支持哪些工具提供了新数据。要将这些细分数据转化为可靠的使用情况概览，应将其与权限和其他内部数据源相互核对，并把客户端名称视为流量类别，而非已证实的身份信息。