What changed
On September 4, GitHub introduced Project HydraFusion, a research preview that treats model selection as a runtime orchestration problem. Instead of asking developers to choose one model for every coding task, Copilot can select models from multiple providers and construct an execution pattern for the request.
HydraFusion currently chooses among three patterns:
- Single: one model solves the task directly.
- Cascade: an efficient model drafts first, then a quality gate escalates to a stronger model if needed.
- Critique: one model drafts, an independent read-only critic from another model family reviews it, and the drafting model revises once.
The preview is available on all Copilot plans through /experimental in Copilot CLI. GitHub says the workflow accounts for drafting, review, revision, escalation, retries, and fallbacks instead of measuring only the first model call.
Why it matters
This is a meaningful step beyond Copilot's existing Auto model selection. Auto already routes a task to a model using task complexity, system health, availability, and cache boundaries. HydraFusion adds a second decision: whether the task should be solved directly or benefit from a structured multi-model workflow.
The product implication is simple: the best answer may come from a cheaper model plus a targeted quality gate, not from sending every request to the most capable model. In GitHub's controlled offline evaluations, HydraFusion improved verified task quality by 4.9 percentage points at 67% lower estimated cost than Claude Opus 5 on TerminalBench 2.1. On DeepSWE it reduced estimated cost by 36% with a 1.5-point quality gap, and on GitHub's CheckpointBench it reduced cost by 65% with a 0.1-point gap. Those results are specific to the tested models, policies, pricing assumptions, and benchmark revisions—not a guarantee for every repository.
The product lesson
The interesting change is not merely that Copilot can call several models. It is that the orchestration layer is becoming the product surface. GitHub describes bounded execution, complete cost accounting, isolated read-only review, fail-safe patch application, and preflight validation of routing and model availability as design requirements. Those are the controls that make compound agents usable in a real repository.
There is also a deliberate UX trade-off. HydraFusion holds intermediate drafts until it can return one coherent result, because a draft that might be revised or discarded should not look final. The Copilot CLI command reference documents the preview switch and the surrounding experimental workflow, but the preview still needs real-world validation around latency, visibility, and failure recovery.
For teams building their own agents, the takeaway is to optimize the completed task rather than an isolated token count: route simple work cheaply, spend extra inference on review only when it is likely to help, and make every leg observable, cancellable, and reversible. GitHub's related engineering note on Copilot efficiency makes the same broader case: shortening one tool response can increase total cost if the agent has to recover the missing context.
Try it
If you want to test the research preview, GitHub's documented path is:
- Run
/updatein Copilot CLI. - Enable previews with
/experimental on. - Open
/modeland selectHydraFusion (Research Preview). - Start with a substantial, well-scoped coding task, then compare the result, total usage, and reviewability with a fixed model.
HydraFusion is still a research preview, so the practical question is not whether orchestration can look good on a benchmark. It is whether the runtime can make the quality-cost trade-off predictable enough that developers trust it with the whole task.