Models & Agents
GitHub put a research preview called HydraFusion into Copilot. You pick HydraFusion the way you used to pick Claude or GPT. Copilot then decides how many models to run on that one task, and in what order.
GitHub introduced HydraFusion on September 4, 2026 as a research preview for GitHub Copilot. It is routing software. It is not a new frontier model.
The pressure behind it is simple. Copilot now offers many models in one product. If every developer always picks the strongest one, two things happen. The token bill jumps. The flat Copilot plan has to absorb work that was priced for a mix of cheap and expensive calls. Other coding tools already route a prompt to a model, or tell the developer which model to use. GitHub had Auto model selection for that. Auto still sends the whole task to one model. HydraFusion is GitHub’s answer when one model is either too weak or too expensive for the whole job.
A coding task does not need the same amount of intelligence all the way through. Some tasks a mid-tier model can finish. Some need a stronger model. Some get better if a second model reads the first draft. Developers already switch models mid-task. HydraFusion moves that choice into the Copilot runtime. You still turn it on. You still read the result. You do not pick the next model yourself.
Enterprises will buy coding agents this way as well. They will not only buy access to one named model. They will buy a plan for extra inference: when to spend more tokens, when to stop, and when a second model may look at the work.
What you select
In Copilot CLI you run /update, turn on /experimental, open /model, and choose HydraFusion. Copilot treats that name like any other model. Underneath, it builds a short plan and can use models from more than one provider.
It currently uses one of three plans.
Single. One model does the whole task.
Cascade. A cheaper model writes a first version. A quality check keeps that version or sends the same task to a stronger model.
Critique. One model writes a first version. A model from a different family reads it and cannot edit the repo. The first model revises once.
You get one answer. If the run succeeds, you get one set of code changes. If the run fails or is cancelled, GitHub says no patch is applied.
Auto model selection, shipped earlier in 2026, picks one model for the task. HydraFusion can use more than one model on the same task.
What the tests showed
GitHub compared a tuned HydraFusion setup with Claude Opus 5 on three agentic coding benchmarks. Cost is GitHub’s estimated cost of every step in the workflow, including draft, review, revision, and escalation.
| Benchmark | Estimated cost vs Opus 5 | Quality vs Opus 5 |
|---|---|---|
| TerminalBench 2.1 | 67% lower | +4.9 points |
| DeepSWE | 36% lower | -1.5 points |
| CheckpointBench | 65% lower | -0.1 points |
TerminalBench 2.1 tests multi-step work in a terminal. DeepSWE tests fixes across a real codebase. CheckpointBench is GitHub’s internal set, built from real Copilot sessions on public repositories.
Estimated cost was 36 percent to 67 percent lower than Opus 5 on those three tests. Quality was 4.9 points higher on TerminalBench 2.1, 1.5 points lower on DeepSWE, and 0.1 points lower on CheckpointBench. Those are GitHub’s offline figures, using GitHub’s model pool and pricing assumptions.
GitHub says start with a clear first prompt. Longer sessions on the same repo are the next test.
How you pay
HydraFusion is available on all GitHub Copilot plans through Copilot CLI. GitHub did not announce a separate HydraFusion product fee. You pay the standard token rate for each model it called. If two models ran, you pay for both.
The bill is lower than Opus 5 when a cheaper model finishes the work. The bill is higher than one cheap model when HydraFusion escalates or adds a review.
What a CIO or CTO should compare it to
Most teams already have a version of this on paper. Use Model A for boilerplate. Use Model B for hard refactors. Use Model C only with approval. Some developer tools already recommend a model before you send the prompt.
HydraFusion is that list, running inside Copilot, with permission to call a second model on the same task.
If you turn it on, developers stop switching models by hand for each prompt. A task can start cheap and spend more only if the first pass is weak. A second model can review a draft without writing to the repo. The extra spend shows up as tokens.
You still decide which work may escalate, whether a review is required before a patch is accepted, and who watches the token mix when the expensive path runs often. If that rule already exists, HydraFusion can automate it. If nobody owns the rule, the preview will not create one.
How to try it
In Copilot CLI: /update, then /experimental on, then pick HydraFusion under /model. Send feedback with /feedback or in GitHub’s community thread for the preview.
Take tasks you already give Copilot. Run the same prompts once with a single model you trust and once with HydraFusion. Compare whether the change was accepted, how long it took, and what the tokens cost.
CIO/CTO viability question
Do you already have a written rule for which coding work may use a frontier model, and who pays when a second model is called? If that rule exists, HydraFusion is an automated version of it inside Copilot. If developers pick a model in the moment, turn the preview on only after you write the rule. Otherwise the router will spend tokens on a policy nobody approved.
Sources
- GitHub. “Project HydraFusion: Frontier quality via multi-model orchestration.” The GitHub Blog, 4 Sept. 2026. github.blog
- GitHub Changelog. “GitHub Copilot weekly releases — September 7.” 10 Sept. 2026.
- GitHub Community. Discussion #206492, HydraFusion research preview.
Personal views only. Does not represent Info-Tech Research Group. Check GitHub’s post before you brief anyone on the benchmark numbers.
