How Project HydraFusion Works
The dropdown was always a bad idea
Open any AI coding tool and there is a model picker. A little dropdown with four or five names in it, and an unspoken instruction: you figure it out.
So you develop folk wisdom. Big expensive one for the hard stuff, fast one for renames. You get it wrong constantly, because you are being asked to predict how hard a task is before starting it, which is the moment you know least about it.
Project HydraFusion is GitHub's answer, shipped as a research preview in Copilot CLI on 4 September 2026. Instead of asking you to pick a model, it looks at the task and builds a workflow across several models at runtime.
The pitch: frontier quality at a fraction of frontier cost. The benchmarks mostly back that up, with one honest exception I will get to.
One thing to clear up first, because the word gets used loosely. Orchestration here does not mean running every model and taking a vote. That is an ensemble, and it costs you the sum of all of them on every single request. Orchestration means deciding, per task, how many models to involve and in what arrangement, and frequently deciding that the right answer is one.
The trilemma
Three things you want, and picking a model fixes all three at once whether you like it or not.
QUALITY
/\
/ \
/ \ pick the big model: quality yes, cost no
/ \ pick the small one: cost yes, quality no
/ \
COST ------ LATENCY
A static choice bets that every task in your session has the same difficulty. Renaming a variable and untangling a race condition are not the same job, and there is no reason they should cost the same.
HydraFusion treats the choice as a per-task optimisation instead of a setting.
Three shapes of workflow
This is the core of it. Rather than one model answering, HydraFusion picks one of three execution patterns.
SINGLE CASCADE CRITIQUE
task task task
| | |
[model] [cheap model] [model A]
| | | draft
answer draft |
| [model B] <- different
( quality gate ) | family,
/ \ | read-only
accept escalate critique
| | |
answer [strong model] [model A] <- revises once
| |
answer answer
Single is one model, straight through. If the task is easy, adding machinery only adds latency and cost, so the best orchestration is often none.
Cascade drafts with an efficient model, then a quality gate decides whether that draft is good enough. Accept it and you paid very little. Escalate and you paid a small tax on top of the strong model you would have used anyway. The whole bet is that the gate is right often enough for the savings to beat the tax.
Critique is the interesting one. One model drafts, a second model reviews it, and the first model revises once. The review runs tool-less and read-only, so the critic cannot edit files or run commands. It can only say what it thinks is wrong.
When a cascade actually saves money
Cascade sounds obviously good until you notice it can cost more than doing nothing clever. If the gate escalates, you paid for the draft and the strong model. So it is worth doing the arithmetic.
c = cost of the cheap draft
S = cost of the strong model
p = fraction of drafts the gate accepts
always strong: S
cascade: c + (1 - p) * S
cascade wins when: c + (1 - p) * S < S
c < p * S
p > c / S
The break-even point is just the cost ratio. If your drafter costs a tenth of the strong model, the gate only has to accept one draft in ten to come out ahead, and everything above that is profit.
That is a startlingly low bar, and it explains why cascade is worth shipping even with a mediocre gate. The economics are forgiving in the cost direction.
They are not forgiving in the other direction. A gate that wrongly accepts a bad draft does not show up as cost at all. It shows up as quality, silently, in the answer you were given. Which is precisely why the results table further down has two columns and not one.
Why the critic comes from a different family
The detail I would have missed on a skim: the critic is drawn from a different model family than the drafter. GitHub currently orchestrates Claude Opus 5 and GPT-5.6 Sol.
This matters more than it sounds. Models from the same family share training data, share architecture, and therefore share blind spots. Asking a model to review its own output, or the output of its sibling, gets you a reviewer that is confidently wrong in exactly the same places.
same family review cross family review
blind spots blind spots
A: [ x x . . ] A: [ x x . . ]
A: [ x x . . ] B: [ . . x x ]
------- -------
missed: x x . . missed: . . . .
You want the errors to be uncorrelated. That is the entire statistical argument for ensembles, and it is why the critique pattern uses a stranger rather than a twin.
The asymmetry of privileges is also deliberate. The solver gets full agent capabilities. The reviewer gets none. A critic that can run commands is a second agent, with a second chance to break something, and you now have two things to debug.
How it decides
Routing works off capability signals: separate scores for reasoning, code generation, debugging, and tool use. A task that is mostly tool orchestration and a task that is mostly algorithmic reasoning get scored differently and can be routed differently, even at similar apparent difficulty.
The part I liked is how the thresholds were set. They were not hand-tuned. GitHub ran beam search over decision policies, evaluated against three benchmarks.
That reframes it. Routing is not a heuristic somebody wrote in a meeting. It is a learned policy over a discrete search space: which workflow, which models, which thresholds, optimising quality per unit cost.
The stated rule is to pick the least complex workflow expected to meet the task's needs, and spend extra model calls only when they are likely to improve the result. Escalation is the exception, not the default.
Five principles that read like scar tissue
The blog lists five operating principles. They are the least glamorous part of the post and probably the most useful, because each one reads like the fix for a specific outage.
Complete accounting. Cost is aggregated across every leg: drafting, critique, revision, escalation, retry, fallback. This one matters enormously and is easy to fake:
"cheap" cascade that escalated
draft (small model) #### cheap
gate (evaluation) # cheap
escalate (strong model) ########## not cheap
------------------------------------------------
actually billed ###############
what a naive dashboard reports: ####
If you only count the leg that produced the final answer, every orchestration system looks brilliant. Counting all of them is what makes the benchmark numbers mean anything.
Bounded execution. Explicit timeouts and cancellation. A workflow that can escalate can also loop, and unbounded retries on a paid API is how you lose money in your sleep.
Isolated review. Review steps are read-only and tool-less, as above.
Fail-safe application. If the workflow fails or is cancelled, no patches are applied at all. No half-written files, no partial refactor. The unit of application is the whole workflow.
Validated routing. Workflow definitions, model bindings and availability are checked before execution, not discovered mid-run when a provider is down.
What the numbers say
Three benchmarks, measured against Claude Opus 5 as the baseline.
| Benchmark | Cost vs Opus 5 | Quality vs Opus 5 |
|---|---|---|
| TerminalBench 2.1 | 67% lower | +4.9 points |
| DeepSWE | 36% lower | 1.5 points lower |
| CheckpointBench | 65% lower | 0.1 points lower |
Read the middle row before the outer ones.
TerminalBench 2.1 is the headline: cheaper and better, by a clear margin. Multi-step terminal work benefits from a second opinion, and the critique pattern is doing real work.
CheckpointBench is the one I trust most. It was curated from real Copilot agentic sessions, anchored to specific repositories at immutable commits. A benchmark built from actual usage rather than puzzles, and pinning the commits keeps it reproducible instead of rotting. Statistically identical quality at a third of the cost is an excellent result.
DeepSWE is a regression. Repository-level tasks came out 1.5 points below Opus 5. GitHub published it anyway, which is the correct call, and it tells you something real: when a task genuinely needs sustained deep reasoning across a whole repo, splitting the work across a cheaper drafter and a reviewer does not fully substitute for just using the strong model. Orchestration recovers most of the gap, not all of it.
So the honest summary is not "better than frontier models." It is frontier-adjacent quality at roughly a third of the cost, with one benchmark where it gives up a point and a half. That is still a very good trade, and it is a more useful claim than the headline.
The thing you will actually notice
There is a user-facing cost worth knowing before you turn it on.
HydraFusion shows you workflow stages, but it holds intermediate drafts until it can return one coherent result. The reasoning is sound: a draft that is about to be rewritten by a critique pass should not appear on your screen looking final.
But the feedback loop feels different. You wait longer before seeing anything real. GitHub is explicit that it suits first-turn, well-scoped, single-prompt tasks in autopilot mode rather than tight conversational back-and-forth. That is the same tradeoff any batching system makes.
To try it in Copilot CLI:
/update
/experimental on
/model # then select "HydraFusion (Research Preview)"
It is available on all Copilot plan tiers, and you pay standard token rates for whichever models the workflow used, which is what "complete accounting" implies.
A fun coincidence
While researching this I found another HydraFusion entirely, a 2022 paper from UC Irvine on sensor fusion for self-driving cars. Different field, different people, no connection.
Seven branches: cameras, radar, lidar, and combinations. A small gate network looks at each frame and predicts which branches are about to perform badly. Only the best few run, and their outputs get merged.
Which is, structurally, the same idea. Several specialists, a cheap router that predicts who will fail on this specific input, and a merge step at the end. One does it for radar in fog, the other for language models on a stack trace.
Two teams, four years apart, in unrelated fields, arrived at the same architecture and independently named it after the same mythological animal. That is either a strong signal that the pattern is correct, or evidence that engineers have a limited supply of cool names. I lean toward both.
The takeaway
The pattern worth stealing has nothing to do with Copilot.
When you have several components that are each better in different conditions, the instinct is to benchmark them and crown a winner. HydraFusion's argument is that the winner depends on the input, so the choice belongs at runtime, made by something cheap that predicts which component is about to struggle.
The router does not need to be smart. It needs to be cheap and roughly right, because it is buying you the option to not spend the expensive call. And the accounting has to be honest across every leg, or you will build something that looks like a saving and is not.
That is the real lesson here. Not the models. The discipline around them.