GitHub’s Brand-New Project HydraFusion Crushes Opus 5 on Cost by Mixing Models Mid-Task

For the last couple of years, the AI coding question has been “which model should I use?” GitHub’s new experiment suggests that’s the wrong question entirely. The right one might be: why pick just one?

That’s the idea behind Project HydraFusion, which GitHub detailed on the GitHub Blog and launched today as a research preview in GitHub Copilot. Instead of routing your prompt to a single model, HydraFusion builds an execution plan on the fly — pulling from models across multiple providers to draft a solution, critique it, revise it, or escalate to something more powerful when the first attempt isn’t good enough. From the developer’s seat, it looks like any other model in the picker. Everything else happens backstage.

This is the natural next step from Auto model selection, which GitHub shipped earlier this year to match tasks with the best-suited model. HydraFusion goes further: it doesn’t just choose a model, it constructs a workflow.

Three ways Project HydraFusion attacks a problem

GitHub's Brand-New Project HydraFusion Crushes Opus 5 on Cost by Mixing Models Mid-Task

GitHub treats workflow selection as an optimization problem, scoring capability signals for reasoning, code generation, debugging, and tool use before committing to a plan. Right now there are three patterns it can pick from:

  • Single — one model handles the task directly. Fast and cheap when that’s all you need.
  • Cascade — an efficient model drafts a solution, then a quality gate decides whether to accept it or kick it up to a stronger model.
  • Critique — one model drafts, an independent read-only critic from a different model family reviews it, and the original model revises once.

The Critique pattern follows the same review approach as Rubber Duck, and notably the critic runs in an isolated, tool-less context. It can judge the work but can’t touch your repository. That’s a smart guardrail, and it’s part of a broader set of operating principles GitHub built the system around: complete cost accounting across every workflow leg, bounded execution with explicit timeouts, fail-safe patch application (nothing gets applied if the workflow fails validation), and validated routing before anything runs.

The selectivity is the whole point. Some tasks genuinely need three models arguing with each other. Most don’t. HydraFusion picks the least complex workflow it expects to clear the quality bar, spending extra model calls only when they’re likely to actually help.

The benchmark numbers

GitHub ran fixed Project HydraFusion policies against three agentic coding benchmarks, using Claude Opus 5 and GPT-5.6 Sol as baselines. All models were evaluated at the same medium reasoning level, with identical task inputs, tools, execution limits, and pricing assumptions.

BenchmarkCost vs. Opus 5Quality vs. Opus 5
TerminalBench 2.167% lower+4.9 points
DeepSWE36% lower−1.5 points
CheckpointBench65% lower−0.1 points

The TerminalBench result is the headline — better quality at a third of the cost. But the other two are arguably more interesting, because they’re harder. DeepSWE throws repository-level tasks that require navigating large codebases and cross-file dependencies, and HydraFusion landed within 1.5 points of Opus 5 at 36% less cost. CheckpointBench, GitHub’s internal benchmark built from real anonymized Copilot sessions anchored to immutable public commits, came in within 0.1 points at 65% lower cost.

Essentially a tie on quality, for a third of the price. One Principal Software Engineer at Microsoft quoted in the post said HydraFusion’s reasoning and task-solving capability is “at or better than Opus.”

Worth keeping in perspective: these are controlled offline evaluations tied to specific benchmark revisions, model pools, and pricing assumptions. GitHub says the preview exists precisely to find out how that translates to real workloads. The company was also refreshingly candid about the development process — two operational failures in the evaluation harness on August 11 and August 14 produced invalid runs that had to be excluded and rerun before the configurations kept improving through August 25.

How to try it

HydraFusion is available on all GitHub Copilot plans through the /experimental flag in GitHub Copilot CLI. Three commands to get going:

  1. Run /update to install the latest version
  2. Run /experimental on
  3. Run /model, then select HydraFusion (Research Preview)

Billing works on tokens consumed by whichever models HydraFusion invokes, each at its standard rate. So a Cascade or Critique run costs more per task than a Single run — though the benchmark data suggests the orchestration usually nets out cheaper than going straight to a frontier model.

GitHub recommends starting with substantial, well-scoped first-turn coding tasks you can hand off in a single prompt. Multi-turn performance is next on the roadmap. Feedback goes through /feedback in Copilot CLI or the GitHub Community discussion.

One known rough edge: HydraFusion shows you workflow stages but withholds intermediate drafts until it has a final answer, since those drafts might get revised or thrown out. GitHub acknowledges the waiting is a real trade-off and says it’s working on better progress indicators.

Why it matters

Copilot has been building toward this for a while. GitHub opened Copilot up to multiple models back in 2024, and has kept adding frontier options like Claude Opus 4.6 for agentic coding. But every one of those additions pushed the same decision onto developers: pick the right tool, and eat the cost of guessing wrong.

HydraFusion inverts that. And because the model pool is expandable, GitHub can fold in new models as they ship — routing each one to the tasks it’s actually good at rather than making it compete head-to-head across the board.

There’s a business angle too. Frontier model inference is expensive, and Copilot’s premium request pricing has been a sore point for some users. If orchestration can hit frontier quality at a third of the cost, that’s margin GitHub can keep or pass along.

GitHub is upfront that names, models, workflows, and behavior may all change. But the thesis is clear enough: the next real gain in coding agents won’t come from a bigger model, it’ll come from smarter runtime decisions about how to use the ones we already have.

For more coverage, see our GitHub tag and Azure & Cloud section.


Discover more from Microsoft News Now

Subscribe to get the latest posts sent to your email.