GitHub 一直希望為開發者的每個任務提供最合適的模型。今年早些時候的 Auto model selection 已經能讓 Copilot 根據請求自動匹配模型；今天發佈的 Project HydraFusion 則把這一目標向前推進了一步：它不再只挑選一個模型，而是在請求到達時生成一個完整的執行計劃，從多個提供商的模型池中選擇模型，讓它們起草、評審、修改解決方案，或在必要時將任務級聯給更強的模型。開發者看到的是一個普通模型選項，HydraFusion 會在後台根據質量、成本和延遲進行平衡。
HydraFusion 把工作流選擇視為優化問題。它會根據推理、代碼生成、調試和工具使用等能力信號，選擇最可能滿足質量要求的高效執行模式。目前，每個請求會從三種模式中選擇：Single（單個模型直接解決）、Cascade（高效模型先起草，質量門決定接受還是升級到更強模型）、Critique（一個模型起草，來自不同模型家族的獨立只讀評審者按 Rubber Duck 的類似模式檢查，然後起草模型修改一次）。每種模式對應不同的質量成本取捨。
在 TerminalBench 2.1、DeepSWE 和 CheckpointBench 三個 agentic 編碼基準的受控離線評估中，固定 HydraFusion 策略的表現優於或接近 Claude Opus 5 基線。以 Opus 5 為基準：TerminalBench 2.1 經核實任務質量提高 4.9 個百分點，估算成本降低 67%；DeepSWE 質量僅低 1.5 個百分點，成本降低 36%；CheckpointBench 質量僅低 0.1 個百分點，成本降低 65%。評估還以 GPT-5.6 Sol 作為對照，所有模型均使用相同的中等推理等級、輸入、工具、執行限制與定價假設。
HydraFusion 的設計圍繞五個原則：完整核算（統計每一條工作流的起草、評審、修改、升級、重試和回退成本）、有界執行（顯式超時與取消）、隔離評審（評審步驟在無工具上下文運行，而解決步驟使用共享工作區）、故障安全應用（工作流取消或驗證失敗時不打補丁）以及經過驗證的路由（執行前驗證工作流定義、模型綁定、回退和可用性）。執行過程中，內部會記錄每個步驟的角色、結果、成本、延遲和診斷，但開發者最終只收到一個連貫的響應和一組權限感知的變更。
基準細節顯示，TerminalBench 2.1 主要衡量終端環境中的複雜多步任務；DeepSWE 需要跨文件依賴和大型代碼庫端到端修復，HydraFusion 在此以接近 Opus 5 的質量換取顯著成本下降；CheckpointBench 是 GitHub 內部從真實 Copilot 會話構建的可回放多輪基準，HydraFusion 的成本優勢明顯。微軟的一位首席軟件工程師在早期內部測試中評價：“到目前為止，HydraFusion 的推理和任務解決能力達到或優於 Opus。”
HydraFusion 的策略也經過反覆調優。團隊從真實 Copilot 會話軌跡構建 CheckpointBench，並在三個基準上使用束搜索優化路由策略，而不是手工調整閾值。TerminalBench 2.1 的運行序列顯示，8 月 11 日至 25 日評估工具曾出現兩次操作故障，相關無效運行被排除並修正後，配置繼續改進，8 月 25 日達到最強運行點。
目前研究預覽最適合第一輪、單提示編碼任務，GitHub 表示下一步會主攻更長的多輪迭代會話。官方建議開發者從範圍清晰、內容充實的單提示任務開始，使用 Copilot 的自動模式試用，並可通過 /feedback 或 GitHub Community 討論反饋。HydraFusion 仍是活躍研究項目，模型、工作流、可用性和產品行為都可能隨預覽學習而改變；GitHub 相信，編碼代理的下一個真實進展來自前沿智能與運行時編排的結合。