GitHub 在 2026-07-02 再次更新 Copilot 使用量指標程式介面（Copilot usage metrics API）：CLI 活動開始回報建議新增／刪除行數，只透過伺服器端遙測看得到的使用者會補上 IDE 與插件版本，AI Credits 消耗也修正了兩種漏歸屬情況。既有 dashboard 的分母、歸因與每人消耗會變得更完整；如果沒有重標 7/2 基準，月報容易把官方修正看成預算失控或採用暴增。
企業管理員、FinOps 與工程平台負責人最容易踩到的坑，是週報突然看到 CLI 行數、IDE 分布或 ai_credits_used 變動，就急著判斷某個 team 用太兇、某個工具終於被採用，或預算快爆。比較穩的第一步，是把 2026-06-15 active users 口徑變更、2026-06-19 每人 AI Credits 欄位、2026-07-02 歸因修正，標成三個不同切點，再分開看「多少人在用」、「哪些介面有明細」、「每人額度消耗」與「真正帳務金額」。
如果只看一條總趨勢，很容易把資料定義更新誤解成使用成效，或把高額度使用者直接當成浪費。比較好的週報流程是：先重標基準，再問這些 AI Credits 是來自 CLI、雲端代理、程式碼審查、聊天輔助、模型選擇，還是某個團隊剛開始大量試用。這樣主管看到數字變化時，討論會落在任務、資料品質與預算保護，而不是只看排名抓人。
先把三次更新分開看
GitHub 6 月中到 7 月初連續調整 Copilot 相關報表。三次更新都會改變 dashboard，但它們對應的管理動作不同。
2026-06-15 處理的是「有多少活躍使用者被報表捕捉到」：Copilot usage metrics 納入伺服器端遙測後，enterprise single-day report 與 28-day report 的 active users / DAU 可能比以前高，dashboard 要加上基準切點。2026-06-19 處理的是「某位使用者消耗多少 AI Credits」：user-level reports 新增 ai_credits_used，可看每人總量，但不該直接當成發票金額。2026-07-02 補的是歸因盲點：CLI 的 loc_suggested_to_add_sum / loc_suggested_to_delete_sum 不再固定為 0，更多 server-side-only 使用者會出現在 totals_by_ide，部分原本顯示 0 的 credits 也會補回正確 organization 或 enterprise。
三者可以並排分析，但不要用其中一個欄位替另一個欄位下結論。7/2 前後尤其要重標資料品質切點，避免把歸因補齊誤讀成突然爆量。
如果團隊還在整理 Copilot 方案、CLI、Agent 模式與基本開始用的範圍，可以先搭配站內的 GitHub Copilot 費用與 CLI 指南 建立共通語言，再處理 metrics dashboard。
一個企業週報情境：DAU 沒暴增，CLI 與 AI Credits 卻變了
假設平台團隊週一打開 BI dashboard，看到 GitHub Copilot DAU 大致穩定，但 CLI 的建議行數開始出現、totals_by_ide 補回一批先前沒有 IDE 的使用者，users-28-day 裡也有幾位使用者的 ai_credits_used 明顯高於同組同事。
這時候不要急著把名單丟給主管。更好的第一步是先問五個問題：一、這些人是否真的活躍，單日與 28 天報表是否都把他們列入 active users；二、CLI 行數為什麼突然出現，7/2 前後是否只是官方補上 loc_suggested_to_add_sum / loc_suggested_to_delete_sum；三、額度集中在哪些人，7 天與 28 天分布是否都指向同一個部門；四、帳單要看哪裡，quantity 與 gross_amount 是否回到 AI usage / billing report 對帳；五、要不要調整政策，先和專案負責人確認真實工作內容，再評估模型規則、額度提醒或教育訓練。
每人 AI Credits 與 CLI/IDE 歸因會把「需要追問的用量」提早浮出來；追問方向應該放在工作流、模型選擇、代理任務、CLI 版本與預算保護，先避免把高用量視為錯誤。
如果團隊已把雲端代理或自動開 PR 接進流程，可以再看 Copilot Agent tasks REST API 自動化流程；若高用量來自把 AI 代理放進 GitHub Actions，則接著看 GitHub Agentic Workflows 的 AI Credits 與安全控管。如果重點是限制哪些 organization 能使用哪些模型，則回到 GitHub Copilot Model Rules 企業模型治理 的 policy 設計。
ai_credits_used 與 7/2 修正分別回答什麼？
6/19 的 ai_credits_used 回答的是「某位使用者在單日或 28 天期間總共消耗多少 AI Credits」。它出現在 enterprise 與 organization 層級的 user-level reports，可以和 active users 放在同一張檢視裡，但目前仍不是 feature、model 或 surface 級別的拆分。
7/2 的修正補的是資料品質。GitHub 說 Copilot CLI 活動現在會回報 loc_suggested_to_add_sum 與 loc_suggested_to_delete_sum，新版 CLI 也會避免同一個建議／接受編輯被重複計算；只透過 server-side telemetry 被看見的使用者，會在 totals_by_ide 補上 IDE 與插件版本；原本因為 organization 歸屬或 billing match 問題而顯示 0.0 的 AI Credits，會被歸到正確的 organization 或 enterprise。
對企業來說，這些修正讓平台團隊更快回答三個管理問題：哪些 team 真的把 Copilot 放進日常工作，哪些 CLI／IDE／代理活動原本被低估，哪些使用者或部門需要預算提醒。正式帳務仍要回到 AI usage / billing report；usage metrics 適合拿來找異常、訪談工作流、確認資料管線，不適合直接拿來分攤發票。
DAU、CLI、AI Credits、帳務要分欄看
建議 BI 或資料團隊把 Copilot dashboard 拆成五個層次，避免把所有欄位混成一個「使用量」。Top-line active users / DAU 用來看有多少人被計為活躍，6/15 附近跳升時要在圖上加註 telemetry coverage change。IDE / feature / model breakdown 用來看可拆解的使用介面、功能與模型分布，7/2 後要重看 server-side-only users 的 IDE 歸因。CLI suggested LOC 用來看命令列建議新增／刪除行數，先確認 CLI 版本與報表口徑，再比較任務量。ai_credits_used 用來看每位使用者的 AI Credits 總量，適合週報排序、預算提醒與工作流訪談；Billing / AI usage report 才看 quantity、gross_amount 等正式金額資料。
這樣拆開後，管理員可以同時看採用、資料品質、CLI／IDE 歸因、額度消耗與帳務風險。若五個層次指向同一個團隊或流程，再進一步檢查是否需要模型規則、額度溝通、代理工作流限制或教育訓練。
REST API 與權限要先確認
GitHub 官方文件對 Copilot usage metrics REST API 有幾個實務條件，建議直接寫進資料管線文件。第一，enterprise 的 Copilot usage metrics policy 需要啟用，否則報表可能取不到；第二，呼叫者要是 enterprise administrator、organization 管理者，或持有對應 fine-grained permission 的 token；第三，API 涵蓋 enterprise、organization 與 user-level usage metrics，daily report 會以有限時效的 signed URL 提供下載。
資料範圍也要先寫清楚。官方文件提到歷史資料從 2025-10-10 起算，最多可查到 1 年；single-day report 適合看突變，28-day report 適合看平滑後趨勢。7/2 後若 BI pipeline 要新增 CLI 行數或更完整的 totals_by_ide，先確認下載檔 schema、CLI 版本與排程時間，再讓 dashboard 自動比較前後趨勢。
若平台團隊（platform team）已經把 Copilot 程式碼審查（code review）、雲端代理（cloud agent）或 Agent tasks API 接進流程，使用量 dashboard 應該和治理資料一起整理。相關功能邊界可參考 Copilot code review 企業控管指南 與 Copilot Agent tasks REST API 自動化流程，避免把互動式開發、PR 審查代理與報表對帳混成同一組指標。
管理員與 BI 對帳檢查表
把這段加到 Copilot dashboard 的變更紀錄會最有幫助：一、標註 2026-06-15：「Copilot usage metrics 納入 server-side telemetry，active users / DAU 前後分段看。」
二、標註 2026-06-19：「user-level reports 新增 ai_credits_used，可看每人 AI Credits 總量，但不等同發票金額。」
三、標註 2026-07-02：「CLI suggested LOC、server-side-only users 的 IDE 歸因、AI Credits organization / enterprise 歸屬修正，7/2 前後不要直接比較。」
接著保留 top-line 與 attributed breakdown 的差異，不要把沒有 IDE、feature、model 或 LOC attribution 的資料硬塞到其他欄位。每人 AI Credits 視圖適合看 7 天、28 天與部門分布；AI usage report 的 quantity、gross_amount 才適合看正式帳務。若高用量出現，先把原因對照到雲端代理、模型切換、批次審查、訓練日或短期專案，再決定是否需要模型規則或預算提醒。
最後固定資料管線責任：usage metrics policy 是否開啟、API token 權限是否足夠、每日報表何時下載、失敗告警誰處理、CLI 版本何時更新。這些欄位清楚後，主管月報才不會把 GitHub 修正歸因當成團隊突然失控。
對主管和財務的說法
可以用這段話放在月報註解：
2026-06-15 起，GitHub Copilot 使用量指標在客戶端資料（client signals）之外加入伺服器端遙測（server-side telemetry），活躍使用者（active users / DAU）可能比過去更高；2026-06-19 起，使用者層級報表（user-level reports）新增
ai_credits_used；2026-07-02 起，CLI 建議行數、server-side-only users 的 IDE 歸因與部分 AI Credits 歸屬更完整。這三次更新都會讓 dashboard 變動，月報應分開列出 DAU、CLI/IDE/功能明細、每人 AI Credits 與帳務報表，不要把資料口徑修正解讀成採用或成本本身的突然變化。
報表應同時保留五個視角：整體活躍使用者（top-line active users / DAU）看被計為活躍的使用者；可歸因明細看 IDE、功能、模型與程式碼行數（LOC）使用分布；CLI suggested 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、功能明細、CLI 行數與 AI Credits 回答的是不同問題。DAU 看使用者是否活躍；功能明細看可歸因的使用介面與活動；CLI 行數看命令列建議新增／刪除；AI Credits 看每人消耗量。2026-06-15 的 server-side telemetry 更新會讓 top-line active users 更完整，2026-07-02 的修正則會補上 CLI、IDE 與 credits 歸因；前後趨勢要先加註再比較。
看到某些人 AI Credits 很高，企業應該立刻限制嗎？
先不要只看排名。管理員應先確認高用量是否來自合理工作：例如雲端代理跑大量任務、批次 code review、模型切換、訓練週或短期專案。若高用量持續且沒有清楚產出，再評估模型規則、額度提醒、教育訓練或部門預算機制。
既有 AI usage report 還需要嗎？
需要。6/19 的更新讓 Copilot usage metrics API 多了每人 AI Credits 總量，適合用來分析使用者與部門分布；AI usage / 帳務報表仍是正式帳務來源，適合看 quantity、gross_amount 與金額。
參考來源
- GitHub Changelog：Improved accuracy and coverage in Copilot usage metrics reports
- 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