GitHub Models 退休前怎麼盤點？從 endpoint、BYOK 到 brownout 的 repository 檢查表
GitHub 已公告 GitHub Models 會在 2026 年 7 月 30 日全面退休；playground、模型目錄、推論 API 與 bring your own key（BYOK）都在範圍內。若專案只在 README 寫了「用 GitHub Models」，最容易漏掉的往往不是程式碼，而是 CI、範例設定與已部署的環境變數。
官方也預告 7 月 16 日與 7 月 23 日會有短暫 brownout，請求會暫時回傳錯誤。把它當成演練窗口，而不是等到退休日才第一次發現依賴。
先用 repository 搜尋找出依賴面
在 repository 根目錄執行下列搜尋。它不是要猜替代服務，而是建立需要遷移或刪除的清單：
rg -n -i \ 'models\.inference\.ai\.azure\.com|github models|azure ai inference|GITHUB_TOKEN|BYOK' \ --glob '!node_modules/**' --glob '!dist/**' .命中結果先分成三類：
| 類型 | 要確認的事 |
|---|---|
| 執行期程式碼 | endpoint、SDK client、模型 ID 與錯誤處理是否依賴 GitHub Models |
| CI／自動化 | workflow、Actions secret、部署腳本是否會呼叫推論 API |
| 文件與範例 | .env.example、README、測試 fixture 是否會把新使用者導向已退休入口 |
不要把搜尋不到 github.com 當成沒有風險。實際 endpoint、環境變數名稱或封裝 SDK 往往才是線索。
Brownout 要驗證的是失敗路徑
若服務在 brownout 期間收到錯誤，應確認它不會悄悄回傳空字串、重複扣款或無限重試。最小檢查可以是：
- 以 staging 的相同設定執行一次會觸發模型呼叫的流程。
- 暫時把 endpoint 指向明確會失敗的測試位址，或在 client mock 回傳失敗，確認 UI、job 與 queue 的行為。
- 記錄 retry 上限、告警位置與人工處理入口；這些資訊才是轉換服務時可比較的基準。
若系統透過 GitHub Actions 觸發模型工作，也要看 token 是否只是 GitHub API 權限，或實際被用來取得模型存取。兩種情況的替換方式不同，不能只靠改一個 secret 名稱處理。
替換前先抽出可攜的介面
GitHub 的公告提到 Microsoft Foundry 可提供模型目錄，而 GitHub Copilot 適合直接在 GitHub 內建立 AI 工作流程；它們不是 API 的逐行替代保證。更安全的做法是先把目前呼叫周圍的四項契約寫下來：輸入格式、輸出結構、timeout／retry、成本與存取責任。
這樣選定下一個供應商或工具時，才可以在 staging 對照同一組測試，而不是把遷移變成一次不可回溯的設定替換。若你的工作流已經以 agent 方式在 GitHub 內跑，亦可參考 GitHub Agent Apps 的安裝與權限檢查 ，把應用程式權限與模型存取分開審核。
退休日前應留下的交接紀錄
一個可交接的 issue 就足夠：列出命中的檔案、實際呼叫的入口、負責人、brownout 測試結果，以及退休日以前的切換日期。先把依賴說清楚，才有辦法驗證替換後系統真的不再向 GitHub Models 發出請求。
參考資料：
GitHub Changelog：GitHub Models is being fully retired on July 30, 2026
回報錯字、失效連結，或告訴我你想看的延伸主題。