GitHub 在 2026-06-19 更新 Copilot 使用量指標程式介面（Copilot usage metrics API），在使用者層級報表（user-level reports）加入 ai_credits_used。企業管理員現在可以在同一份 Copilot 使用者報表裡，同時看某位使用者是否活躍，以及他在單日或 28 天期間消耗多少 AI Credits。
這篇主要給企業管理員、FinOps 與工程平台主管看。先做的事很簡單：把 2026-06-15 的每日活躍使用者（DAU）統計口徑變更、2026-06-19 的每人 AI Credits 欄位新增，標成兩個不同切點；週報裡分開呈現「多少人在用」、「哪些功能有明細」、「每人額度消耗」與「真正帳務金額」。
如果只看一條總趨勢，很容易把資料定義更新誤解成導入成效，或把高額度使用者直接當成浪費。比較穩的做法是先建立對帳欄位，再問：這些 AI Credits 是來自雲端代理、程式碼審查、聊天輔助、模型選擇，還是單純因為某個團隊剛開始大量試用？
先把兩次更新分開看
GitHub 6 月中連續調整 Copilot 相關報表。這兩件事都會影響 dashboard，但管理動作不同：
| 日期 | 官方變更 | 會影響什麼 | 管理員先做什麼 |
|---|---|---|---|
| 2026-06-15 | Copilot usage metrics 納入伺服器端遙測（server-side telemetry） | enterprise single-day report 與 28-day report 的 active users / DAU 可能比以前高 | 在 dashboard 加上基準切點，分開看 top-line DAU 與可歸因明細 |
| 2026-06-19 | user-level reports 新增 ai_credits_used | enterprise / organization 的 users-1-day 與 users-28-day 使用者報表可看到每人 AI Credits 總量 | 新增每人額度欄位，但不要把它直接當成發票金額 |
第一個更新處理的是「有多少活躍使用者被報表捕捉到」。第二個更新處理的是「某位使用者消耗多少 AI Credits」。兩者可以並排分析，但不要用其中一個欄位替另一個欄位下結論。
如果團隊還在整理 Copilot 方案、CLI、Agent 模式與基本導入範圍，可以先搭配站內的 GitHub Copilot 費用與 CLI 指南 建立共通語言，再處理 metrics dashboard。
一個企業週報情境：DAU 沒暴增，AI Credits 卻集中
假設平台團隊週一打開 BI dashboard，看到 GitHub Copilot DAU 大致穩定，但 users-28-day 裡有幾位使用者的 ai_credits_used 明顯高於同組同事。
這時候不要急著把名單丟給主管。更好的第一步是把問題拆成五格：
| 對帳問題 | 要看的欄位或來源 | 期待輸出 | 驗證方式 | 風險提醒 |
|---|---|---|---|---|
| 這些人是否真的活躍？ | Copilot usage metrics active users / DAU | 使用者有沒有被列入活躍使用者 | 對照單日與 28 天報表 | 6/15 前後口徑不同，趨勢線要加註 |
| 額度集中在哪些人？ | ai_credits_used | 每人 AI Credits 排序與部門分布 | 先看 7 天或 28 天，避免只看單日 | 單日高峰可能是專案切換或集中測試 |
| 能不能拆到功能或模型？ | Copilot usage metrics feature / model breakdown | 可歸因的 IDE、功能、模型使用 | 檢查 breakdown 是否有空白或未歸因 | GitHub 說 ai_credits_used 目前是每人總量，沒有拆到 feature、model 或 surface |
| 帳單要看哪裡？ | AI usage / usage-based billing report | quantity 與 gross_amount 等帳務欄位 | 由 billing report 對帳，不用 usage metrics 取代 | ai_credits_used 是分析訊號，官方提醒它不等同 billed total |
| 要不要調整政策？ | 部門 rollout、代理工作流、模型規則 | 限額、教育、模型可用範圍或工作流調整 | 和專案負責人確認真實工作內容 | 避免只用額度排名懲罰高價值實驗 |
這個情境的重點是：每人 AI Credits 讓管理員更快找到「需要追問的用量」，但追問方向應該放在工作流、模型選擇、代理任務與預算保護，先避免把高用量視為錯誤。
如果團隊已把雲端代理或自動開 PR 接進流程，可以再看 Copilot Agent tasks REST API 自動化流程；若高用量來自把 AI 代理放進 GitHub Actions，則接著看 GitHub Agentic Workflows 的 AI Credits 與安全控管。如果重點是限制哪些 organization 能使用哪些模型，則回到 GitHub Copilot Model Rules 企業模型治理 的 policy 設計。
ai_credits_used 可以回答什麼？
GitHub changelog 對新欄位給了幾個明確邊界：
| 問題 | 目前可回答的程度 |
|---|---|
| 哪些報表有這個欄位？ | enterprise 與 organization 層級的 user-level reports，包含單日 users-1-day 與 28 天 users-28-day |
| 欄位代表什麼？ | 某位使用者在期間內所有 Copilot 活動消耗的 AI Credits 總量 |
| 資料從哪裡來？ | GitHub 說它來自 usage-based billing API 使用的 AI Credits consumption data |
| 可以和活躍使用一起看嗎？ | 可以，因為它出現在管理員已經用來看 Copilot usage 的 user-level reports |
| 可以用來預估預算嗎？ | 可以觀察日與日之間的消耗範圍、部門分布與異常尖峰 |
| 可以直接當帳單嗎？ | 不宜。GitHub 明確說這是 consumption analysis 的 metrics signal，發票與 billed total 要回到 billing |
| 可以拆到 feature、model 或 surface 嗎？ | 目前不行。官方說 ai_credits_used 是 per-user overall total，尚未依功能、模型或使用介面拆分 |
對企業來說，這個欄位的價值在於把同一位使用者的活躍狀態與額度消耗放在同一張檢視裡。這會讓平台團隊更快回答三種管理問題：
- 哪些 team 已經真的把 Copilot 放進日常工作？
- 哪些使用者或部門的 AI Credits 消耗需要預算提醒？
- 哪些高用量其實來自合理的試點、代理任務或短期專案？
DAU、功能明細、AI Credits、帳務要分成四欄
建議 BI 或資料團隊把 Copilot dashboard 拆成四個層次，避免把所有欄位混成一個「使用量」：
| 層次 | 主要用途 | 常見誤讀 | 建議呈現方式 |
|---|---|---|---|
| Top-line active users / DAU | 看有多少人被計為活躍使用者 | 6/15 附近跳升被直接當成導入成功 | 在圖上加註 telemetry coverage change，前後趨勢分段 |
| 可歸因使用明細 | 看 IDE、功能、模型、程式碼行數等可拆解訊號 | 以為 breakdown 加總必須等於 DAU | 保留 attributed 與 unattributed bucket |
ai_credits_used | 看每位使用者的 AI Credits 總量 | 直接拿來分攤發票或懲罰高用量 | 用於週報排序、預算提醒與工作流訪談 |
| Billing / AI usage report | 看帳務、額度與金額 | 和 usage metrics 混用欄位定義 | 由帳務報表提供 quantity、gross_amount 等正式金額訊號 |
這樣拆開後，管理員可以同時看採用、資料品質、額度消耗與帳務風險。若四個層次指向同一個團隊或流程，再進一步檢查是否需要模型規則、額度溝通、代理工作流限制或教育訓練。
REST API 與權限要先確認
GitHub 官方文件對 Copilot 使用量指標程式介面（REST API）的描述，有幾個實務條件值得放進資料管線文件：
| 檢查點 | 管理員要確認的事 |
|---|---|
| Usage metrics policy | Copilot usage metrics policy 需要啟用，否則資料可能取不到 |
| 權限 | enterprise administrators、organization owners，或具備對應 fine-grained permission 的 token 才能取得資料 |
| 報表範圍 | API 涵蓋 enterprise、organization 與 user-level usage metrics，並提供 daily reports 與 download links |
| 歷史資料 | 官方文件寫明歷史資料從 2025-10-10 起算，最多可查到 1 年 |
| 觀察週期 | single-day report 適合看突變；28-day report 適合看平滑後趨勢 |
| 新欄位佈署 | 先確認下載後的 user-level report 是否已出現 ai_credits_used，再讓 BI pipeline 改 schema |
若平台團隊（platform team）已經把 Copilot 程式碼審查（code review）、雲端代理（cloud agent）或 Agent tasks API 接進流程，使用量 dashboard 應該和治理資料一起整理。相關功能邊界可參考 Copilot code review 企業控管指南 與 Copilot Agent tasks REST API 自動化流程，避免把互動式開發、PR 審查代理與報表對帳混成同一組指標。
管理員與 BI 對帳檢查表
| 檢查項 | 建議做法 |
|---|---|
| 標註 2026-06-15 切點 | 在 dashboard、BI 說明與月報加註「Copilot usage metrics 納入 server-side telemetry」 |
| 標註 2026-06-19 切點 | 在 schema changelog 記錄 ai_credits_used 進入 user-level reports |
| 保留 top-line vs breakdown 差異 | active users / DAU 用 top-line；IDE、feature、model、LOC breakdown 用各自維度說明 |
| 建立 unattributed bucket | 把沒有 IDE / feature / model / LOC attribution 的使用者或活動獨立呈現，不藏進其他欄位 |
| 新增每人 AI Credits 視圖 | 用 ai_credits_used 看每人、部門與 28 天趨勢，避免只看單日尖峰 |
| 分開帳務來源 | AI usage report 的 quantity / gross_amount 用來看 AI Credits 帳務；usage metrics 用來看使用者與活動 |
| 對照工作流脈絡 | 高用量先問是否來自雲端代理、模型切換、批次審查、訓練日或短期專案 |
| 固定權限與資料管線 | 確認 usage metrics policy、API token 權限、排程、失敗告警與資料更新時間 |
最後一點很重要。GitHub 2026-06-11 的 AI usage report update 提到，AI Credits usage 會使用標準欄位 quantity 與 gross_amount。6/19 的 ai_credits_used 讓使用量報表多了一個每人消耗訊號，但帳務、發票與金額仍應回到帳務或 AI usage report。
對主管和財務的說法
可以用這段話放在月報註解：
2026-06-15 起，GitHub Copilot 使用量指標在客戶端訊號（client signals）之外加入伺服器端遙測（server-side telemetry），活躍使用者（active users / DAU）可能比過去更高；這代表統計覆蓋變完整，前後趨勢要分段看。2026-06-19 起，使用者層級報表（user-level reports）新增
ai_credits_used，可用來觀察每位使用者的 AI Credits 消耗。此欄位是用量分析訊號，官方提醒它不等同帳單總額，也沒有依功能、模型或使用介面拆分。月報應分開列出 DAU、可歸因明細、每人 AI Credits 與帳務報表。
報表應同時保留四個視角：
- 整體活躍使用者（top-line active users / DAU）：看被計為活躍的使用者。
- 可歸因明細（attributed breakdown）：看 IDE、功能、模型與程式碼行數（LOC）使用分布。
ai_credits_used：看每位使用者的 AI Credits 總量與分布。- 帳務與 AI usage report：看正式帳務欄位與金額。
這樣處理，工程主管可以繼續看採用，FinOps 可以對帳，平台團隊也能保留資料品質註記，不會因為一次欄位更新就誤判 rollout 成效或預算風險。
下一步：把對帳結果變成治理動作
Dashboard 找出高用量人員後，先把原因分流成三種處理方式：
| 對帳結果 | 下一步 |
|---|---|
| 高用量來自一般開發與聊天輔助 | 回到 GitHub Copilot 費用與 CLI 指南 確認方案、額度與使用者教育，不要只用排名管理。 |
| 高用量來自雲端代理、自動開 PR 或批次任務 | 接著檢查 Copilot Agent tasks REST API 自動化流程，把任務範圍、審查與失敗告警寫清楚。 |
| 高用量集中在特定 organization、模型或實驗團隊 | 優先看 GitHub Copilot Model Rules 企業模型治理，用組織層級政策控制可用模型與 rollout 節奏。 |
如果三個方向都無法解釋用量尖峰，再回頭查 usage metrics policy、API token 權限、資料更新時間與 billing report。這能避免把資料管線問題誤判成員工亂用，也能讓預算討論建立在同一組欄位定義上。
FAQ
`ai_credits_used` 是帳單金額嗎？
它不等同帳單金額。GitHub changelog 明確說 ai_credits_used 是用量分析訊號（metrics signal），不等同 billed total。它可以幫管理員看每人 AI Credits 分布與預算風險；發票、金額與正式帳務仍要看帳務或 AI usage report。
可以用 `ai_credits_used` 看出是哪個模型或功能消耗最多嗎？
目前不行。GitHub 說這個欄位是每位使用者所有 Copilot 活動的總量，尚未依 feature、model 或 surface 拆分。若你需要判斷原因，應同時看可歸因的功能明細、部門 rollout 時程、雲端代理任務與專案脈絡。
為什麼 DAU 上升，但 AI Credits 或功能明細沒有同步變化？
DAU、功能明細與 AI Credits 回答的是不同問題。DAU 看使用者是否活躍；功能明細看可歸因的使用介面與活動；AI Credits 看每人消耗量。2026-06-15 的 server-side telemetry 更新還會讓 top-line active users 更完整，前後趨勢要先加註再比較。
看到某些人 AI Credits 很高，企業應該立刻限制嗎？
先不要只看排名。管理員應先確認高用量是否來自合理工作：例如雲端代理跑大量任務、批次 code review、模型切換、訓練週或短期專案。若高用量持續且沒有清楚產出，再評估模型規則、額度提醒、教育訓練或部門預算機制。
既有 AI usage report 還需要嗎？
需要。6/19 的更新讓 Copilot usage metrics API 多了每人 AI Credits 總量，適合用來分析使用者與部門分布；AI usage / 帳務報表仍是正式帳務來源，適合看 quantity、gross_amount 與金額。
參考來源
- GitHub Changelog：AI credits consumed per user now in the Copilot usage metrics API
- GitHub Docs：REST API endpoints for Copilot usage metrics
- GitHub Changelog：Copilot usage metrics now include more of your active users
- GitHub Changelog：AI usage report updates
- GitHub Docs：REST API endpoints for billing usage reports