GitHub は、開発者が目の前のタスクに最適なモデルを得られるようにすることを目指してきました。先ごろ発表した Auto model selection は、リクエスト内容から最適なモデルを選ぶ仕組みです。今回発表した Project HydraFusion はその次のステップで、複数プロバイダーのモデルをランタイムで組み合わせて、タスクごとに最適な実行計画を自動構築するリサーチプレビューです。モデルは下書き・批評・修正を担当し、必要に応じてより強力なモデルへカスケードされます。開発者は通常のモデル選択と同じように HydraFusion を選ぶだけで、品質・コスト・レイテンシーのバランスは実行時に自動調整されます。
HydraFusion は、ワークフロー選択を最適化問題ととらえ、推論・コード生成・デバッグ・ツール使用などの能力シグナルから実行パターンを決めます。現在は次の3パターンがあります。Single（選んだ1モデルが直接解決）、Cascade（効率的なモデルが下書きし、品質ゲートが受理するか強力なモデルへエスカレーションするかを判断）、Critique（モデルが結果を下書きし、別モデルファミリーの独立した読み取り専用レビューアが確認し、下書きモデルが1回修正）です。それぞれ異なる品質とコストのトレードオフを持ち、追加のモデル呼び出しは結果改善が見込まれる場合にだけ行います。
固定ポリシーを使った3つのエージェント型コーディングベンチマーク（TerminalBench 2.1、DeepSWE、GitHub の実 Copilot セッションから作られた CheckpointBench）の制御されたオフライン評価では、Claude Opus 5 ベースラインと比較して次の結果が出ています。TerminalBench 2.1: 検証済みタスク品質が4.9ポイント向上し、推定コストは67%減。DeepSWE: 品質は1.5ポイント下回る一方、コストは36%減。CheckpointBench: 品質差は0.1ポイントで、コストは65%減。評価では GPT-5.6 Sol も比較対象とし、全モデルを同じ中程度の推論レベル、入力、ツール、実行制限、価格前提でそろえています。
HydraFusion は、完全な原価計算（各レッグの下書き・批評・修正・エスカレーション・リトライ・フォールバックを集計）、実行範囲の制限（タイムアウトとキャンセル動作）、分離レビュー（レビューはツールなしコンテキスト、解決ステップは共有ワークスペースで実行）、失敗時安全（キャンセルや検証失敗時はパッチを適用しない）、ルーティング検証（実行前に定義やモデルバインド、利用可能性を確認）という5つの運用原則で構築されています。内部では各レッグの役割・結果・コスト・レイテンシ・診断が記録され、開発者には1つの整合的な応答と権限認識済みの変更セットだけが渡ります。
TerminalBench 2.1 は端末環境での複雑なマルチステップ課題、DeepSWE は大規模コードベースの横断的依存関係を扱う現実的なリポジトリ課題、CheckpointBench は実セッションから収集した再生可能なマルチターン評価セットです。Microsoft のプリンシパルソフトウェアエンジニアは「今のところ、HydraFusion の推論とタスク解決能力は Opus と同等かそれ以上」と初期社内テストで述べています。
HydraFusion は開発者の実利用パターンをもとに、ユーザーが手動で行っていたモデル切り替えを自動化する試みです。ポリシーはビームサーチと凍結ベースラインに対する測定で最適化されました。TerminalBench 2.1 の開発履歴では、8月11日から25日の間に評価ハーネスで2回の運用障害があり、これらの無効なランは除外・修正され、その後も改善が続き、8月25日までに最強の構成に達しています。
今回のプレビューはまず、最初のターンで単一プロンプトのコーディングタスクを扱う場合に適しています。GitHub は今後、長いマルチターンセッションでの性能向上に取り組む方針です。開発者は、範囲が明確な実質的なタスクを1つのプロンプトで自動モードの Copilot に渡し、/feedback または GitHub Community で結果を共有できます。HydraFusion は現在も研究段階であり、モデル、ワークフロー、名称、製品動作は変更される可能性があります。GitHub は、フロンティアの知能とランタイムオーケストレーションを組み合わせることが、次世代のコーディングエージェントにつながると考えています。