GitHub 於 2026 年 9 月 14 日更新 Copilot auto model selection，加入 efficiency、balance 和 intelligence 三個取向。三者使用同一組可用模型，但會用不同權重處理成本、品質和回應速度。這不是推出一個新模型，而是把「由系統替每個 prompt 選模型」變成使用者可以調校的政策。
Efficiency 優先保持成本較低，適合簡單、直接的工作；balance 同時衡量成本、品質和 latency，定位為日常工作；intelligence 則優先品質，面向較複雜的任務。GitHub 的例子是，簡單的 docstring 可能使用較小和有效率的模型，即使使用者把 Auto 設為 intelligence。
Auto 仍然會逐個 prompt 評估，再選擇它認為最合適的模型。這表示取向不是一個永遠固定的 model pin，而是給 router 一個優化目標。對 agent workflow 來說，這可以把短任務、日常 coding 和深度分析放入同一個入口，但也令每次呼叫實際使用哪個模型較不直觀。
這項功能目前在 Visual Studio Code、Copilot CLI 和 GitHub Copilot app rollout。用量按 Auto 實際選出的模型收費，不會因為使用某個取向而改變收費方式；付費訂戶繼續享有透過 Auto 計算用量的 10% 折扣。企業若要估算成本，應查看實際 model mix，而不是只看取向名稱。
對開發團隊而言，三層取向提供了一個比「永遠用最強模型」更清晰的成本治理入口。效率取向可以用於格式化、簡短說明和低風險修改；balance 可以覆蓋一般 coding 和 review；intelligence 則留給需要較多推理的設計、除錯和跨檔案任務。這些只是工作流假設，實際仍要以團隊的錯誤率和接受率驗證。
Auto model selection 也帶來可觀察性要求。如果系統按 prompt 選擇不同模型，團隊需要知道哪些任務被路由到哪個模型、成本如何變化、延遲是否改善，以及是否出現品質回歸。若只有一個總用量數字，管理員很難分辨是取向設定有效，還是某一類任務不斷重試。
在企業環境中，取向還要配合政策和權限。組織可以按 repository、team 或工作類型定義預設取向，再用 spend controls、model allowlist 和 audit log 限制可用範圍。Auto 選擇模型的能力，不應繞過資料分類、程式碼權限、秘密保護或需要人工批准的 agent action。
這次更新把模型選擇由隱藏的基礎設施行為，變成較容易討論的產品設定。它不會自動證明成本下降或品質提升，但提供了一個可以做 A/B 比較的控制面。成熟採用方式，是為每類任務定義成功標準，再同時量度成本、延遲、結果品質和人工介入，而不是單純選擇 intelligence 便期待所有結果更好。
