摘要： GitHub 在 2026 年 10 月 23 日更新 Copilot usage metrics API，新增 totals_by_client 陣列，把 OpenCode 這類原本不會回報編輯器遙測的工具用量也計進報告。過去這些在 IDE 之外使用 Copilot 的請求幾乎無法追蹤，現在改由伺服器端計數，企業與組織終於能看到哪些工具在真正消耗模型額度。
為什麼原本的報告會漏帳
越來越多開發者把 Copilot 當成 IDE 以外工具的 model provider。這些工具通常不送編輯器遙測，所以舊的 totals_by_IDE 統計看不到它們，用量帳目出現明顯缺口。GitHub 的做法是把計數搬到伺服器端：只要工具透過 Copilot 發出模型請求，就會被記錄下來，不再依賴客戶端自願回報。
對負責治理與預算的人來說，這代表可以比較不同工具的請求與 token 規模，再決定要支援哪些工具、要不要設限制。
totals_by_client 回報什麼
每一筆 totals_by_client 代表一個客戶端，包含幾個欄位：
- client：發出請求的工具，例如 opencode、claude_code、codex、zed、copilot_cli、github_app、cloud_agent、code_review、vscode 或 jetbrains；無法辨識的統一歸到 other。
- request_count：該客戶端成功的模型請求數。
- session_count：不重複的 session 數。
- token_usage：prompt tokens、output tokens 與平均每請求 token 數。
- totals_by_model：按模型拆分的同組指標，附上 model_selection_mode，標示模型是使用者直接指定（user_selected）、auto 機制挑選（auto），還是產品端決定（product_selected）。
尚未個別回報的選擇模式會顯示為 other，無法標準化的值則標為 unknown。
幾個容易踩解讀陷阱的地方
第一，request_count 數的是模型呼叫次數，不是 prompt 數。一個 prompt 可能觸發多次模型呼叫，拿它和 prompt 或互動數字直接比較會失真。
第二，client 是靠每個請求附帶的 integration ID 辨識，屬於 best-effort 分組，不是經過驗證的身分。做內部歸因時要把這點納入考量。
第三，Copilot code review 與 cloud agent 的請求一律報 product_selected，因為模型由產品決定；而 code review 的模型名稱目前回報為 unknown。
另外要區分的是，這個 API 量測的是模型流量（請求與 tokens），與 agent app activity 不同——後者計算的是 Claude、Codex 等 agent app 在 GitHub 上啟動的工作數量。
範圍、權限與相容性
這次更新涵蓋 enterprise、organization、enterprise-user 與 organization-user 四種報告，各有 1 天與 28 天版本；在聚合的 28 天報告中，totals_by_client 出現在每天的 day_totals 裡。
存取權限限於 enterprise owner、billing manager、organization owner，以及被授予 View Copilot Metrics 權限的自訂角色，且 Copilot usage metrics policy 必須啟用。
這是附加式變更：既有欄位不動，沒有用量時 totals_by_client 就是空陣列。現有的儀表板與腳本不會被破壞。
對 builder 的實際意義
如果你的團隊正在管理 Copilot 的用量與成本，這個欄位值得盡快接進自己的儀表板。它讓「誰在用什麼工具、吃掉多少 token」變成可量測的數字，而不是靠各工具各自的遙測拼湊。這也延續了 GitHub 把 Copilot 計費與用量越綁越細的方向——先前已寫過 Copilot 改用量計費、AI Credits 接棒 premium requests 的趨勢，這次等於把量測的底層補齊。
下一步很直接：確認 policy 已啟用、拉一次 28 天報告，看看 other 分類佔多大比例——那裡往往藏著還沒被辨識的工具。細節可參考 Copilot usage metrics API 文件。
參考來源
在 X 上查看原貼文