GitHub's HydraFusion Stops Picking a Model. It Builds a Workflow Instead.

The most interesting number in GitHub's newest Copilot experiment is not a quality score but a bill: 67% less, on a hard terminal benchmark, while scoring 4.9 percentage points higher than Claude Opus 5. That is the headline result GitHub published for Project HydraFusion, a research preview that stopped asking which model should handle a coding task and started asking how many should, and in what order.

Key takeaways

• HydraFusion beat a Claude Opus 5 baseline by 4.9 percentage points on TerminalBench 2.1 at 67% lower estimated cost, and roughly matched it on two other suites for 36% and 65% less.
• Rather than routing to one model, it assembles a per-request plan that can draft, escalate, or bring in a read-only critic from a rival model family.
• Every Copilot plan can switch it on inside the Copilot CLI, paying nothing extra beyond the standard token rate of whichever models the plan happens to invoke.

Why the cost line matters more than the quality line

Agentic coding has an economics problem that benchmark tables tend to hide. Teams that hand long, tool-heavy tasks to a frontier model pay frontier prices on every leg of the loop, including the legs that a cheaper model would have finished correctly. HydraFusion is GitHub's attempt to price each leg separately.

The evidence GitHub released comes from offline runs on three agentic suites, with Opus 5 and GPT-5.6 Sol as references and every model pinned to medium reasoning. Two of the three results are essentially parity buys: DeepSWE, which stresses cross-file repository work, finished within 1.5 points of Opus 5 for 36% less, and CheckpointBench came within 0.1 points for 65% less. Only TerminalBench 2.1 produced an outright quality gain, and GitHub notes that suite is comparatively saturated — which is part of why it ran the other two at all.

CheckpointBench is worth a second look because it is GitHub's own. The company assembled it from real Copilot session trajectories, anchoring each conversation to a public repository at an immutable commit so the run can be replayed, then balanced it across languages, task types and difficulty. It is closer to production traffic than a public leaderboard, and also impossible for anyone outside GitHub to audit.

The development record carries an unusually candid footnote: between 11 and 25 August, two operational failures inside the evaluation harness produced invalid runs that were thrown out before the trend line was drawn.

How a single prompt becomes a multi-model plan

HydraFusion reads capability signals — reasoning depth, code generation, debugging and tool use — and then picks the cheapest of three shapes it believes will clear the bar. One model may simply answer. Or a fast model drafts and a quality gate decides whether the draft ships or gets escalated to something stronger. Or, in the pattern GitHub likens to rubber-duck review, a drafter produces an artefact, a critic from a different model family reads it without any tools attached, and the drafter gets exactly one structured revision to respond.

Those thresholds were not set by hand. GitHub ran beam search over per-capability scores against a frozen baseline, tuning across all three suites at once instead of chasing any single one — the kind of choice that matters when the headline benchmark is the saturated one.

So far, the reasoning and task solving capability [of HydraFusion] is at or better than Opus.

That verdict came from a principal software engineer at Microsoft testing the system internally.

What GitHub had to lock down first

Pointing several models at one working tree introduces failure modes a single-model loop never has: a reviewer that edits the code it was asked to judge, a cancelled run that leaves a half-applied patch, a bill that nobody attributed because it was spread across six legs. GitHub's answer is a set of hard constraints — critics run tool-less and cannot write, patches are discarded entirely rather than partially applied when validation or cancellation intervenes, every leg carries a timeout and a cancellation handle, model bindings are verified before anything executes, and token spend is aggregated across drafting, critique, revision, escalation, retry and fallback so the whole workflow has one number attached to it.

Turning it on, and what it still cannot do

Access runs through the Copilot CLI: update the client, enable the experimental flag, and HydraFusion shows up in the model picker. The caveat is that a task which escalates twice or triggers a critique pass will cost more than the same task answered in one shot, because billing follows the models actually invoked.

GitHub is steering early users toward big, well-scoped, single-prompt work and says longer iterative sessions are the next engineering target. One rough edge it acknowledges up front: the preview withholds intermediate drafts until a single coherent answer is ready, on the reasoning that discarded work should not look finished — which in practice means staring at a progress indicator with little idea of what is happening. Feedback is being collected in the Copilot community thread.

Outlook

Treat the numbers as a hypothesis rather than a result. They are offline, tied to one model pool and one set of pricing assumptions, and the preview exists specifically to find out whether they hold when real developers throw messy work at it. If they do, the competitive question shifts away from whose model is strongest and toward who routes best — a shift that would suit a platform vendor with access to many providers rather better than it suits any single lab. It also arrives while GitHub is absorbing an agent-driven volume surge across its own infrastructure, which we covered in our report on the platform's commit growth.

FAQ

Is Project HydraFusion available outside the GitHub Copilot CLI?

Not yet. It ships only inside the Copilot CLI behind the experimental configuration. GitHub has given no timeline for bringing it to the IDE extensions or the Copilot app.

Does HydraFusion cost extra on top of a Copilot subscription?

No separate charge applies. You pay the normal token rate for each model the workflow calls, which means the price of a task varies with how many legs it takes to finish.

Which models does HydraFusion use?

GitHub has not disclosed the pool, describing it only as spanning multiple providers, and has said the critic is deliberately drawn from a different family than the drafter. Opus 5 and GPT-5.6 Sol served as evaluation baselines, not necessarily as pool members.