GitHub 在 2026 年 7 月 31 日公布，Gemini 2.5 Pro 和 Gemini 3 Flash 已在所有 GitHub Copilot 體驗中停用。範圍包括 Copilot Chat、inline edits、ask mode、agent mode 和 code completions，因此影響的不只是聊天介面的模型選擇，也包括 IDE 內的程式編輯和 Agent workflow。
GitHub 建議以 Gemini 3.1 Pro（Preview）取代 Gemini 2.5 Pro，以 Gemini 3.6 Flash 取代 Gemini 3 Flash。官方亦提醒，Copilot Enterprise 管理員可能需要在 Copilot 設定的 model policies 中開啟替代模型，並在個別 Copilot 設定確認使用者是否真的看得到該模型。至於移除已停用模型，管理員不需要另外做清理動作。
這類變更的真正成本通常不在按一下替換，而在於既有 workflow 對模型名稱、輸出格式和上下文行為的依賴。使用 agent mode 的團隊可能有固定的工具權限、提示詞、測試 prompt 或審批流程；模型更換後，即使功能仍然可以執行，輸出長度、工具選擇、程式碼風格和失敗模式也可能改變。
企業應把 model identifier 當成受管制的配置，而不是寫死在操作手冊或自動化腳本裡。先列出受影響的 Copilot policy、IDE 設定、團隊 onboarding 文件和內部評測，再為替代模型建立最小回歸測試。Gemini 3.1 Pro 仍然是 Preview，不能假設它與已停用的 Gemini 2.5 Pro 完全等價；關鍵工作要保留人工 review、版本記錄和可回退的替代方案。
GitHub 今次公告也反映模型供應已變成平台管理問題。當 Copilot 同時覆蓋 Chat、completions 和 agent mode，企業的 AI 治理就不能只管理「誰可以使用 Copilot」，還要管理「團隊實際允許哪一個模型、何時替換、替換後怎樣驗證」。model policy、可觀測性和回歸測試會直接影響開發流程能否平穩過渡。
對開發者而言，現在最值得做的是檢查現有工作流有沒有直接指定兩個已停用的 model identifier，確認替代模型是否已在組織 policy 中開放，並重新驗證高風險的 agent 任務。GitHub 不要求額外移除舊模型，但企業仍然需要主動更新整合和測試，才不會把平台的 model lifecycle 變成生產中的突然中斷。
