GitHub Copilot AI usage report 怎麼看?用逐模型 token 拆解查 AI credits
GitHub 在 2026 年 8 月 11 日把逐模型 token breakdown 加進 AI usage report。以前報表主要看到 AI credits,現在可以把每個模型的 input、output、cache_read 和 cache_write token 一起對照,知道一筆用量大致是由哪一種 token 組成。
先分清楚這份報表和 GitHub Copilot 網頁版的 token 提示:網頁版提示適合管理目前 conversation 或 session;AI usage report 則是帳務與管理層級的資料,適合依日期、模型和使用者做對帳。兩者不要互相替代。
AI usage report 多了哪些欄位
GitHub Billing reports reference 說明,AI usage report 會依 date、model 和 username 彙整 AI credits,並提供以下 token 欄位:
| 欄位 | 代表什麼 | 判讀時注意 |
|---|---|---|
input | 傳給模型的輸入 token | prompt、檔案脈絡和工具結果都可能增加輸入量 |
output | 模型產生的輸出 token | 長回答或長 diff 會提高輸出量 |
cache_read | 讀取已快取的 token | 不能直接當成一般 input 相加比較成本 |
cache_write | 寫入快取的 token | 是否計費與模型定價規則有關 |
報表的 date 使用 UTC。若團隊以台灣日期做日報,先把查詢區間與時區記錄下來,再轉換顯示日期;不要把午夜前後的使用量直接歸到錯的工作日。
從哪裡取得報表
到 GitHub 的 Billing settings,從 AI usage 頁面要求或下載 AI usage report。官方文件目前把 AI usage report 的詳細期間限制為最多 31 天;報表會以 email 寄到 GitHub 帳號的預設信箱,而且同一帳號同時間只能要求一份 usage report。
GitHub Changelog 指出,這項逐模型拆解可供 Copilot for individuals 使用,也可由 Copilot Business 和 Enterprise 的管理者查看;實際入口仍會受到方案、billing entity 和管理角色影響。看不到下載入口時,先確認登入的帳號、billing settings 權限與查詢期間,不要把瀏覽器快取或 Copilot extension 當成第一個嫌疑。
用三層維度讀報表
拿到 CSV 後,先不要直接加總所有 token。建議依這個順序檢查:
- 日期:先確認所有列的 UTC 範圍,避免報表跨日後和公司日曆對不上。
- 模型:比較同一模型在不同日期或使用者的變化;模型不同時,token 不能直接視為相同成本。
- 使用者:確認用量是否來自個人工作流、團隊共用帳號或自動化流程,再回到實際工作內容查原因。
對帳時保留 gross_amount、discount_amount 與 net_amount。GitHub 文件定義 net_amount 是套用折扣後的可計費金額,且 gross_amount - discount_amount = net_amount。如果只看 token 總數,不看 AI credits 和 net amount,容易把快取命中、方案內含量或模型單價差異誤判成異常。
token 報表適合用來排查什麼
它比較適合回答以下問題:
- 某個模型的 input token 是否在長期上升?是否有 prompt 或 repository 脈絡變得過大?
- 同一個模型的 output token 是否集中在某一種 agent 任務?
- cache read/write 是否和預期的長對話或重複脈絡相符?
- AI credits 增加時,究竟是模型變更、使用者增加,還是任務內容改變?
它不適合單獨回答「哪個模型品質最好」或「誰的產能最高」。同樣的 token 數可能來自不同難度、不同模型和不同工具工作流;若要做工程判斷,還要連回 PR、CI、revert、incident 或人工 review 的結果。
如果你要查的是目前 conversation 的 quota,而不是帳務報表,可以回到 GitHub Copilot 網頁版的最近對話與 token 控制。如果你仍使用舊的 Billing Preview 入口,則可參考 GitHub Copilot Billing Preview 退役後的 AI usage 與預算。
一份可回溯的對帳清單
每次下載報表時至少保留:
下載日期:UTC 查詢區間:Billing entity:原始 CSV 檔名:模型與使用者分組方式:AI credits 合計:gross_amount / discount_amount / net_amount:需要回查的 workflow、PR 或工作階段:先保存原始檔,再做轉換、去重或匯入 dashboard。若報表和內部總帳不一致,先比較日期範圍、billing entity、模型名稱與折扣欄位,最後才排查程式。不要用重新下載一次的結果覆蓋原始資料,否則很難追蹤 GitHub 後續修正或延遲入帳造成的差異。
結論:用 token 解釋 credits,不要用 token 排名
逐模型 token breakdown 讓 AI usage report 從「看得到 credits」變成「能追查 credits 由何而來」。實務上先依 UTC 日期、模型和使用者分組,再對照 input、output、cache 欄位與 net_amount;把成本異常連回實際工作流,才能做出可驗證的 prompt、模型或權限調整。
常見問題
Q: AI usage report 的 token 日期是台灣時間嗎?
A: 不是。GitHub Billing reports reference 將 date 定義為 UTC。若要做台灣日報,請保存原始 UTC 範圍,再在報表層轉換,不要直接用下載當天的本地日期代替。
Q: token 數量可以直接換算成 GitHub Copilot 費用嗎?
A: 不應只用 token 數量換算。實際 AI credits 取決於模型、各類 token 的定價、方案內含用量與折扣;應同時查看報表的 AI credits、gross_amount、discount_amount 和 net_amount,再對照 GitHub 的模型定價。
Q: 為什麼 AI usage report 看不到 workflow_path?
A: GitHub 文件把 workflow_path 列為 detailed usage report 的欄位;AI usage report 的主要分組是日期、模型和使用者,並提供 AI credits 與 token breakdown。需要 workflow 層級的帳務資料時,應使用對應的 detailed usage report 或其他 GitHub Actions metrics。
參考資料:
GitHub Changelog:Per-model token breakdown in the usage report
回報錯字、失效連結,或告訴我你想看的延伸主題。