摘要： GitHub 於 2026 年 11 月 3 日宣布，Copilot usage metrics API 開始區分 BYOK（自帶金鑰）與企業自訂模型的用量，不再與 Copilot 託管模型混在一起。對負責治理 AI 用量與成本的企業管理員來說，這代表帳務歸屬和政策遵循終於有了可查的數據基礎。
為什麼過去算不清
BYOK 的問題在於名字會撞車。開發者用自己的 provider key，或跑一個名稱與 Copilot 託管模型相同的本地模型時，這些請求過去全部混進 Copilot 託管的總量裡。你沒辦法回答一個基本問題：這個月我們付給 GitHub 的錢，和開發者自己付給 provider 的錢，各佔多少？
這不是新問題。之前我寫過 Copilot usage metrics API 納入 OpenCode 等第三方工具用量，方向是一致的：先把用量按來源拆乾淨，才談得上治理和成本控制。這次是把拆分的顆粒度推進到「誰在用自己的金鑰」。
兩種 BYOK，兩種觀測方式
這次報告涵蓋兩類用量，觀測機制不同，值得分開看：
Local BYOK 是開發者在客戶端自己設定的，請求從 Copilot CLI 或 GitHub Copilot app 直接發到開發者的 provider key 或本地模型——包括 Ollama、Foundry Local、LM Studio、llama-server 這類工具。對應的欄位有 used_local_byok、totals_by_local_byok，以及日／週／月的活躍 BYOK 使用者數。totals_by_local_byok 還會按 byok_kind（local_managed、local_user、local_auto、remote_user）和 surface（copilot_cli 或 copilot_app）細分。
Enterprise custom models 則由管理員在 GitHub 設定中配置，請求經由 GitHub 路由到你的 provider。每個 totals_by_client[].totals_by_model[] 項目新增了布林欄位 is_custom_enterprise_model。因為 GitHub 是在伺服器端觀測這些請求，所以涵蓋所有客戶端，包括 IDE。
兩類報告都出現在 enterprise 和 organization 層級，提供使用者級與彙總級，各有 1 天與 28 天版本。如果同一個模型既是 Copilot 託管模型又是自訂模型，會拆成兩筆記錄，計數不會互相污染。
對管理員的實際用途
GitHub 在公告中列出幾個用途，我認為前兩個最實用：
一是治理。你可以查出誰在把請求送往自己的 provider key 或本地模型，對照公司的 BYOK 政策檢查是否符合規範。二是成本歸屬。把 Copilot 託管用量和由你自己的 provider 計費（或跑在免費本地模型上）的用量分開，每人成本才能真正反映 Copilot 實際服務的部分。
另外兩個是：跨工具取得單一視圖，不管開發者選什麼模型；以及把 BYOK 使用者與一般使用者分組，比較兩群在既有 Copilot 指標上的效率差異。
動手前先知道的三個限制
看到數字之前，有幾個邊界條件要記住：
- 本地 BYOK 是下限而非精確值。 這些欄位依賴客戶端遙測，遙測被停用時會漏算；部分本地 provider 也不回報 token 用量，token 計數同樣偏低。企業自訂模型因為是伺服器端觀測，沒有這個問題。
- 現有總量不變，也沒有回填。 BYOK 用量本來就計入總量——local BYOK 是
totals_by_cli和totals_by_copilot_app的子集——所以歷史總數不會跳動，但這次發布之前的報告日不會有is_custom_enterprise_model。 - 存取需要權限。 可查看的角色包括 enterprise owner、enterprise billing manager、organization owner，以及被賦予 View Copilot Metrics 權限的自訂角色，且 Copilot usage metrics 政策必須啟用。
如果你正在建立企業內的 AI 用量儀表板，務實的第一步是先在 aggregate 報告裡打開 daily_active_local_byok_users，確認你的環境裡本地 BYOK 的實際規模，再決定治理政策的鬆緊。
參考來源
在 X 上查看原貼文