如果你原本打算把 GitHub Models 當成新專案的模型沙盒，現在要改路線了。GitHub 已經宣布開始退休 GitHub Models；沒有既有使用紀錄的新 organization（組織）和 enterprise（企業帳號），看不到 GitHub Models，也不能開始新的使用。
但這不代表 Copilot cloud agent 不能選模型，也不代表所有 AI coding agent（AI 寫程式代理）都要立刻搬家。麻煩點在於：很多團隊把「模型沙盒」、「代理寫程式用哪個模型」、「企業允許哪些模型」混在同一個 GitHub AI 流程裡。GitHub Models 退場後，這三件事要拆開處理。
最容易出錯的是省錢模型。Copilot cloud agent 新增 0.33x 的 fast models，看起來可以降低成本；但如果便宜模型開出一堆需要工程師收拾的 PR，省下的模型費會被 review、CI 重跑和返工吃掉。這篇要解決的問題很具體：哪些任務可以交給 fast model，哪些任務應該保留高推理模型，企業又該怎麼用 model rules 控住風險。
先分清楚：哪個入口退場，哪個入口仍要分流
GitHub 在 2026-06-16 的 changelog 寫得很直接：GitHub Models 正在退休，第一步是不再開放新客戶。既有客戶今天還可以繼續使用 playground（互動測試介面）、程式介面（API）和 models；GitHub 之後才會公布更完整的退場時程。新專案如果需要模型存取，GitHub 指向 Azure AI Foundry。
這和 Copilot cloud agent 的模型選擇是不同層級。你可以用這張表先拆清楚：
| 入口 | 主要用途 | 現在該做的事 |
|---|---|---|
| GitHub Models | 模型目錄（model catalog）、提示管理（prompt management）、量化評測（quantitative evaluations）、原型測試 | 新專案不要再把它當長期依賴；改評估 Azure AI Foundry 或其他模型沙盒 |
| Copilot cloud agent model choice | 指派 Copilot cloud agent 修程式時，選較快、較便宜或較強的模型 | 依任務風險分流，不要讓所有代理任務預設同一種模型 |
| GitHub Copilot Model Rules | Enterprise owner 控管哪些 organization 可用哪些 Copilot models | 把資料敏感度、任務類型、模型層級寫成治理規則 |
如果你的問題是「新專案還能不能用 GitHub Models 做測試」，答案偏向否定；如果你的問題是「Copilot cloud agent 可不可以用便宜模型修簡單任務」，答案是可以試，但要設邊界。
0.33x fast models 適合省哪一種成本？
GitHub 2026-05-18 宣布 Copilot cloud agent 支援更多 fast、cost-efficient models。官方列出的新增模型包含 Claude Haiku 4.5 和 GPT-5.4-mini，兩者都是 0.33x multiplier。GitHub 的說法是：簡單變更可選小一點、快一點的模型；複雜工作保留能力更強的模型。
這句話不能只翻成「便宜模型可省錢」。工程團隊要看的成本至少有四種：
| 成本 | fast model 可能省下什麼 | 可能反噬在哪裡 |
|---|---|---|
| 模型費 | 0.33x multiplier 降低單次代理任務成本 | 任務失敗重跑，總成本反而拉高 |
| 等待時間 | 文件、小修、測試補強可能更快完成 | 修錯方向不對，工程師要重看整個 diff |
| Review 時間 | 小 PR 比較容易檢查 | 代理順手重構或改太多檔案，review 成本爆掉 |
| CI 資源 | 小任務可快速跑完 | 測試設計錯誤、重跑次數多，CI 時數被吃掉 |
Mason 的判斷很簡單：fast model 只適合「邊界清楚、可快速 review、失敗可回滾」的任務。它不適合拿來賭架構、權限、金流、資料庫 migration 或跨服務契約。
任務分流表：哪些可以交給 fast model？
| 任務 | fast model 適合度 | Review 重點 |
|---|---|---|
| README、註解、格式整理 | 高 | 確認語意沒有被改歪，diff 不要超出指定範圍 |
| 小型 typo fix | 高 | 檢查是否只修錯字，沒有順手重構 |
| 單元測試補齊 | 中高 | 必跑測試，確認測試沒有刻意迎合現有錯誤行為 |
| 型別註解補強 | 中高 | 確認型別沒有掩蓋真實資料形狀 |
| 明確重現步驟的小 bug | 中 | 看是否跨模組，是否需要更多上下文 |
| 跨檔案重構 | 低 | 需要高推理模型、完整上下文與雙人 review |
| 權限、金流、加密、資料庫 migration | 很低 | 人工主導，模型只能輔助產生測試或檢查清單 |
一個實用規則：如果 reviewer 需要先理解整個系統才能判斷對錯，這類任務不適合 fast model。reviewer 只要看 diff、跑測試、確認範圍時，便宜模型才值得試。
GitHub Models 退場後，新專案怎麼改路線？
新專案不要只問「GitHub Models 還能不能用」。更好的問法是：你原本想用它完成哪個任務？
| 原本想做的事 | 改成怎麼做 |
|---|---|
| 快速比較模型輸出 | 評估 Azure AI Foundry 或其他模型沙盒，確認模型目錄、資料處理、匯出能力 |
| 保存 prompt 與測試案例 | 把 prompt、測試集、評分規則放到可遷移的位置，不要只存在單一平台 UI |
| 給 Copilot cloud agent 選模型 | 這是 Copilot 工作流問題，使用任務分流表和 14 天試跑，不要拿 GitHub Models 當答案 |
| 企業控管可用模型 | 用 GitHub Copilot Model Rules 或內部政策表分 organization 管理 |
| 算代理寫程式成本 | 搭配 AI coding agent ROI 成本分析，把模型費、review 時間、CI 與返工放在同一張表 |
對台灣中小型工程團隊，最實際的處理是把 GitHub Models 視為「不適合新專案長期依賴的原型入口」。既有客戶可以先觀察 GitHub 後續時程；新專案應該直接規劃替代模型沙盒。
14 天模型分流試跑表
如果你正在把 Copilot cloud agent 接進日常開發，不要一開始就把所有任務交給 fast model。先挑一個 repository、兩三種低風險任務，跑 14 天。
| 欄位 | 怎麼記 | 為什麼重要 |
|---|---|---|
| 任務類型 | 文件、測試、bug、重構、資安修補 | 決定是否適合 fast model |
| 模型層級 | Fast、中階、高推理 | 避免只看單次成功案例 |
| 成本倍率 | 例如 0.33x 或更高倍率 | 讓 FinOps 能估算長期成本 |
| PR 大小 | 幾個檔案、幾行 diff | 大 PR 通常拉高 review 成本 |
| Review 時間 | reviewer 花幾分鐘 | 衡量模型是否真的省人力 |
| CI 結果 | 首次通過、重跑、失敗原因 | 找出模型常犯錯的地方 |
| 修正率 | 需要人類補幾輪 | 判斷任務是否該升級模型 |
| 回滾風險 | 低、中、高 | 決定是否需要雙人審查 |
兩週後，把任務分成三類：
- 可交給 fast model：文件、註解、小測試、低風險整理。
- 預設用中高階模型：跨檔案 bug、資料模型改動、複雜測試設計。
- 人工主導：權限、付款、隱私、加密、資料庫 migration、跨服務 API 契約。
省錢模型真正有價值的條件，是 review 時間和返工率也一起下降。只看 0.33x multiplier，會低估後面的人工成本。
企業治理：Model Rules 要管到 organization 層級
GitHub 2026-05-26 宣布 targeted model rules 進入 public preview，enterprise owner 可以為不同 organizations 指定可用的 Copilot models，不必只靠單一 enterprise-wide setting。
這對有多個產品線或客戶專案的團隊很重要。內部工具 repo 可以開放更多 fast model 試驗；碰到客戶資料、金流、醫療、法務或未公開核心程式碼的 organization，就要限制模型入口、記錄審查軌跡，甚至要求固定模型層級。
至少補一張治理表：
| 欄位 | 建議內容 |
|---|---|
| Organization / team | 哪個團隊可使用哪些 AI 工具 |
| 資料敏感度 | 是否碰到客戶資料、金流、醫療、法務或未公開程式碼 |
| 可用模型入口 | Copilot、Azure AI Foundry、內部模型 API、其他 SaaS |
| 可用任務 | 補文件、寫測試、修 bug、重構、資安修補 |
| 預設模型層級 | Fast、中階、高推理或固定供應商模型 |
| 例外流程 | 誰能批准 preview model、外部模型或高風險任務 |
| 稽核紀錄 | PR、prompt、工具呼叫、CI、人工 review 是否留存 |
如果主要問題是 VS Code 裡 Copilot 何時自動換模型，可以看 Copilot Auto model selection 說明。如果你已經把代理接進 GitHub Actions、問題單與 PR 流程，也應該一起檢查 GitHub Agentic Workflows 的安全與權限邊界。
Mason 的判斷
GitHub Models 停止開放新客戶，提醒團隊不要把模型目錄、coding agent 和企業政策綁成同一個入口。短期這樣很方便；平台改策略時，遷移成本會一次爆出來。
比較穩的做法是拆成三層：模型沙盒放在可遷移的平台，Copilot cloud agent 依任務風險選模型，enterprise owner 用 model rules 管控 organization 與資料敏感度。fast model 可以省錢，但只應該省在低風險、可 review、可回滾的任務上。
FAQ
GitHub Models 已經不能用了嗎？
新 organization 和 enterprise 如果沒有既有 GitHub Models 使用紀錄，已不能開始使用。既有 GitHub Models 客戶暫時仍可使用 playground、API 和 models；GitHub 尚未公布完整退場時程。
Copilot cloud agent 的 fast model 能替代 GitHub Models 嗎？
不能。GitHub Models 是模型目錄與測試入口；Copilot cloud agent 的 fast model 是代理寫程式時可選的任務模型。兩者解決的問題不同，不能互相替代。
0.33x 模型一定比較省錢嗎？
不一定。模型費可能下降，但如果 PR 需要更多 review、CI 重跑或人工返工，總成本可能更高。要用 14 天試跑表一起看模型費、review 時間、CI 結果和修正率。
哪些任務最適合 fast model？
文件、註解、格式整理、小型 typo fix、低風險測試補強比較適合。跨檔案重構、權限、金流、加密、資料庫 migration 和跨服務 API 契約不適合直接交給 fast model 主導。
企業應該先設定 Model Rules 嗎？
如果公司有多個 organization、不同資料敏感度或外包/客戶專案，應該先設定。Model Rules 可以讓 enterprise owner 按 organization 控管可用模型，降低 preview model 或外部模型被誤用的風險。