Copilot's HydraFusion Cuts Cost. It Only Beats Opus Once.

GitHub published Project HydraFusion as a Copilot CLI research preview. The pitch is simple enough to put on a slide: stop sending every coding task to one frontier model. Build a small workflow per request, spend the expensive calls only where a cheaper draft fails.

The numbers that traveled are the TerminalBench 2.1 ones. Versus Claude Opus 5, HydraFusion posted 67% lower estimated cost and 4.9 more verified-quality points. That is the chart in the announcement. It is also the only chart where quality went up.

VentureBeat ran the rest of the table. DeepSWE: 36% cheaper, 1.5 points worse. CheckpointBench, GitHub’s own replay set from real Copilot sessions: 65% cheaper, 0.1 points worse. Cost fell three times. Quality won once.

If you already live in Cursor or pay Claude because the model feels smarter, this is not a reason to rip the editor out. It is a reason to look at how you are burning tokens in a CLI agent.

What actually shipped

HydraFusion is not a new model. It is a router with three execution patterns, available now on all Copilot plans through /experimental in Copilot CLI. Usage is billed at each underlying model’s normal token rate. There is no HydraFusion SKU. You pay for whatever legs run.

GitHub says the system reads capability signals for reasoning, code generation, debugging, and tool use, then picks the cheapest workflow that should still clear a quality bar. Baselines in the paper-like blog post are Claude Opus 5 and GPT-5.6 Sol, all at medium reasoning. Missing results were treated the same way across runs. Cost includes drafting, critique, revision, escalation, retry, and fallback. That last sentence is doing a lot of work. If you compare HydraFusion to “one Opus call,” you are not matching their ledger.

The three patterns, as MarkTechPost restated them:

• Single. One model, no extra review.
• Cascade. A cheaper model drafts. A quality gate either accepts or escalates to a stronger model.
• Critique. One model drafts, a read-only critic from a different family reviews, the drafter revises once. GitHub analogizes this to Rubber Duck.

Awan Farz’s read, quoted by VentureBeat, is the cascade in one line: you pay the cheap model on every cascade request. The expensive model only runs on the subset that fails the gate. That is not magic. It is an if-statement with an invoice.

Read the table without the press layer

TerminalBench 2.1 is multi-step work in a terminal. That is close to what Copilot CLI is for. A +4.9 quality bump at two-thirds off Opus is a real result on that distribution. If your day is “agent, fix this failing integration in this repo from the shell,” this is the number that applies.

DeepSWE is repository-level engineering: cross-file dependencies, end-to-end fixes. HydraFusion came in 1.5 points under Opus at 36% less money. GitHub calls that a compelling tradeoff. It is, if you were going to pay Opus for every DeepSWE-shaped task. It is not “frontier quality, cheaper.” It is “almost Opus, cheaper.” Those sentences are not interchangeable.

CheckpointBench is the one you should trust more and brag about less. GitHub built it from real Copilot trajectories, anchored to immutable public commits so runs replay. HydraFusion essentially tied Opus (0.1 points under) at 65% less cost. That is the honest product claim: on actual Copilot-shaped work, you can keep quality and stop lighting money on fire.

GitHub says they hill-climbed routing policies with beam search across all three sets rather than tuning for a single benchmark. Take that as an intention, not a guarantee your private monorepo sits in the same distribution.

What this is not

It is not a replacement for choosing Claude or Gemini as a default brain. We already wrote about that product-versus-intelligence split. HydraFusion assumes you will keep several brains on the account and let software pick the workflow.

It is not local. If your constraint is “the code cannot leave the machine,” last week’s LM Studio Bionic write-up is still the relevant piece. /experimental in Copilot CLI is a cloud bill with extra steps.

It is not a fix for the productivity paradox. Cheaper tokens can mean more accepted diffs that nobody wanted. A router that escalates when a gate fails can also escalate when the gate is wrong. You still need tests. HydraFusion does not add tests.

It is not free. “67% lower estimated cost” is versus Opus 5 on GitHub’s pricing assumptions. If your Copilot plan already bundles a cheaper default, your delta is smaller. If cascade retries run hot on a messy repo, you can spend more than a single mid-tier call. The blog is explicit that every invoked leg counts.

How I would turn it on without lying to myself

Use it on the work that looks like TerminalBench: shell-shaped, multi-step, bounded. Leave architectural refactors and “please understand this 400-file service” on a model you picked on purpose, at least until you have a week of traces.

Keep a log for five days. For each HydraFusion run, write down: pattern the CLI reported (if it reports one), whether you accepted the patch, whether CI went green, and a rough feel for cost. Five days is enough to see if cascade is doing the job or if everything is escalating anyway.

Do not point it at secrets. A multi-model workflow means more providers see the prompt. If your company already forbids Copilot on some repos, HydraFusion does not create a loophole. It makes the existing policy more important, because the same snippet may now touch two vendors.

Watch the quality gate. If you notice the cheap draft getting accepted on tasks where you would have wanted a second reader, you are living in the DeepSWE miss. Turn the experiment off for that class of ticket.

GitHub’s own framing is a research preview. Treat it that way. /experimental is not an SLA.

One more operational detail that did not make the charts: HydraFusion is a Copilot CLI flag, not a VS Code toggle and not a Cursor competitor. If your team lives in the editor sidebar, this preview does not arrive there. You have to be in the terminal product. That sounds obvious. It is how a lot of “we turned on Copilot” rollouts will miss it entirely. The person who pays the invoice may never type /experimental. The person who does may never see the cost dashboard.

If you are already paying for several model endpoints outside Copilot, HydraFusion does not merge those keys. It only orchestrates whatever Copilot is allowed to call. Bringing your own router with OpenRouter or a self-hosted gateway is a different architecture. Do not mix the two in a postmortem. When a bad patch lands, you need to know which switch was on.

The part that will age well

The interesting idea is not “we mixed Claude and GPT.” Everyone is mixing Claude and GPT. The interesting idea is picking a workflow before the first token: single, cascade, or critique, based on a guess about the task.

That is closer to how a careful human already works. Easy grep: do it once. Nasty bug: draft cheap, then pay for a review. Cross-family critic is the only piece most people skip, because opening a second tab is friction. Automating that friction is the product.

Whether GitHub’s beam-searched policy is the right one for your repo is an empirical question you cannot answer from a blog table. The table is still useful. It tells you the failure mode in advance: cost will look great in screenshots, quality will be “Opus-ish” on two of three public tests, and the one win lives in a terminal-agent benchmark that flatters a terminal-agent product.

If that trade is the one you wanted, turn /experimental on and keep the receipt. If you were hoping the router would make Opus obsolete, the DeepSWE line is the one to screenshot instead.

A boring eval you can run on Monday

Pick ten tickets you already closed this month. Replay them in Copilot CLI twice: once with your current default model, once with HydraFusion. Same repo state, same prompt text, same timeout. Score four things only: did it compile, did tests pass, did you have to rewrite more than a third of the diff, and what did the usage meter say.

Ten is not a paper. Ten is enough to catch a turkey. If HydraFusion wins on cost and you still rewrote most of the diffs, you did not save money. You moved the cost into your afternoon. If it ties on quality and the meter drops, keep it on for shell work and leave the editor alone.

Critique pattern deserves its own check. Cross-family review only helps if the second model disagrees in a useful way. If both families share the same bug — a wrong API, a stale internal type — you get a polite rubber stamp. For that class of error, a test is cheaper than a second vendor.

Do not run this eval on a Friday against production. Research preview. Your incident channel does not care that TerminalBench went up 4.9 points.

Also write down which pattern you think you got, even if the CLI is vague. If nine of ten runs feel like Cascade and the tenth feels like a long critique loop, your tickets are not TerminalBench. They are DeepSWE with extra meetings. In that world the 36% discount is the number that matters, and the 4.9-point win is a poster.

GitHub will iterate the policy. Beam search over frozen benches is how you get a good demo. Production traffic will drift. Re-run the ten-ticket set when they bump the preview, not when a social post says quality is now frontier everywhere. The only changelog that counts is the one on your meter and your CI.

Community thread #206492 is linked from the MarkTechPost recap if you want the unfiltered bug list. Read it before you roll this past a platform team. Preview software collects the stories that did not fit on the blog. Then decide in writing, with the ten-ticket sheet attached to the note. Keep that sheet. The table is public. The bill will not be.