GitHub bills HydraFusion by every model leg its router decides to call
The Copilot research preview picks a single, cascade, or critique workflow per request, and you pay standard Copilot rates for every token in every leg. So the router has to save more expensive inference than the extra calls cost.
The Engineer · Build desk
What happened
- GitHub launched Project HydraFusion on September 4th, a Copilot research preview that builds a coding workflow from several models instead of sending every prompt to one selected model.
- It appears in the experimental menu of GitHub Copilot CLI for users on every Copilot plan, selected from the model picker as though it were just another model.
- Per request it picks one of three patterns: a single model, a cascade where a cheap draft can be escalated through a quality gate, or a critique with a cross-family reviewer and one revision.
Why it matters
- What it costs cost The overhead of a second opinion lands on the customer's token bill, so a router that misjudges difficulty converts one prompt into several billable calls and the savings evaporate before anyone notices.
- What it limits constraint Because the figures come from GitHub-run replays on selected benchmark revisions with pricing assumptions held constant, no team can lift 67% into a budget without rerunning its own traces.
- Who has to decide decision Evaluating Copilot now means evaluating a routing policy rather than picking a model, and the published table only lets you compare one tuned configuration against one baseline.
- What doesn't add up contradiction The mechanism a team would design against, a feature-based classifier over diffs and ASTs, is asserted by dev.to and absent from GitHub's own description, which leaves only vaguer capability signals to plan around.
Next story · Build · Oct 7
GitHub Copilot's on-device MAI Code 1.1 Flash peaks at 75.5GB of memoryConfirmed2 publishers
GitHub says HydraFusion usage is calculated from all tokens consumed by every model in the workflow, at each model's standard Copilot rate [8]. That is the invoice rule, and it sets the bar the router has to clear. A critique run therefore bills three legs for one prompt: the draft, the independent read-only review from another model family, and the one revision [7][8]. A cascade that escalates bills the cheap attempt that failed the acceptance gate, then the stronger model's work on top of it [24]. GitHub states the consequence itself: the routing layer has to save enough expensive inference to cover that overhead [9].
Now the table. On Terminal-Bench 2.1, GitHub reports 4.9 percentage points better verified task quality at 67% lower estimated workflow cost than Claude Opus 5 [10]. That suite holds 89 container-based tasks [11], so 4.9 points is roughly four tasks changing verdict (89 x 0.049 = 4.4) [23]. DeepSWE runs 113 long-running repository tasks with behavioral verifiers [22], and there HydraFusion finishes 1.5 points behind Opus 5, under two tasks [25], for a 36% estimated saving [20]. That saving is 31 percentage points smaller than the Terminal-Bench figure [26]. The quality deltas across the three benchmarks span 6.4 points, from plus 4.9 to minus 1.5 [21]. Savings compress on the long-running repository work, which is the workload most teams actually point an agent at.
For 67% to be your number, your task mix would have to resemble the Terminal-Bench 2.1 revision, itself a corrected release issued after maintainers fixed dependency, timeout, resource, and grading problems in 2.0 [11]. GitHub's pricing assumptions, held constant along with task inputs, tools, execution limits, grading conditions, and reasoning levels, would have to match your plan's rates [2]. And you would have to accept a tuned configuration: the published comparison uses the best tuned HydraFusion setup, against Opus 5, though GitHub also evaluated fixed policies against GPT-5.6 Sol [1]. The closest thing to a real-workload result is CheckpointBench, GitHub's internal benchmark drawn from Copilot coding sessions, where HydraFusion came within 0.1 points of Opus 5 at 65% lower estimated cost [12], and which nobody outside GitHub can replay.
On how routing decides, GitHub's own post is thin: capability signals for reasoning, code generation, debugging, and tool use, feeding what it calls an optimization problem over workflow selection [13]. A dev.to write-up describes a feature-based classifier over diff size, AST depth, dependency graph, user intent, and historical success rate, with no LLM-as-judge call before each subtask, while conceding that GitHub does not publish the model lineup and that the classifier is "likely" a gradient-boosted tree or logistic regression [27]. GitHub's own description does not support that mechanism, so a budget built on it rests on the vaguer capability signals GitHub does publish, not on the classifier dev.to describes.
The operating principles are good engineering, and worth naming. Review steps run in isolated, tool-less contexts while solver steps keep the shared workspace and the permission-aware agent loop [15], which is a polite way of saying the critic cannot fix what it complains about. No patch is applied when a workflow is cancelled or fails validation [16]. Cost and usage are aggregated across every leg, including drafting, critique, revision, escalation, retry, and fallback [14], and the runtime records role, outcome, cost, latency, and diagnostics per leg while showing the developer one response and one change set [17]. That per-leg ledger is the number that governs your spend.
What to watch
- Whether GitHub exposes the per-leg cost and role records in a form teams can query across sessions, not just inspect one workflow at a time.
- Whether anyone outside GitHub replays Terminal-Bench 2.1 or DeepSWE under their own pricing and reproduces the 67% and 36% estimated savings.
- Whether the GPT-5.6 Sol comparison numbers get published, given the released table reports only the Opus 5 baseline.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence55
- Adoption
- Not scored
- Hype gap+30
- Incentives70
- Confidence60
Perspective Coverage
3 publishers- Builder
- Builder 58%
- Operator
- Operator 28%
- Investor
- Investor 14%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
GitHub evaluated fixed HydraFusion policies against Claude Opus 5 and GPT-5.6 Sol across Terminal-Bench 2.1, DeepSWE, and CheckpointBench; the published comparison table reports HydraFusion against Opus 5 and uses the best tuned HydraFusion configuration.
- [2]
The numbers remain GitHub-run offline evaluations; GitHub held task inputs, tools, execution limits, pricing assumptions, grading conditions, and reasoning levels constant, but the results cover selected benchmark revisions and tuned configurations.
- [3]
GitHub launched Project HydraFusion on September 4th, a GitHub Copilot research preview that assembles coding workflows from multiple AI models instead of sending every prompt to one selected model.
- [4]
HydraFusion is available through the experimental menu in GitHub Copilot CLI for users on every Copilot plan; developers enable experimental features, open the model picker, and select HydraFusion as though it were another model.
- [5]
For each request, HydraFusion currently chooses one of three execution patterns: single, cascade, or critique.
- [6]
In the cascade pattern, an efficient model drafts a solution and a quality gate decides whether to accept it or escalate to a stronger model.
- [7]
In the critique pattern, one model drafts a result, an independent read-only critic from a different model family reviews it following the same review pattern as Rubber Duck, and the drafting model revises once.
- [8]
GitHub says HydraFusion usage is calculated from all tokens consumed by every model in the workflow, using each model's standard Copilot rate.
- [9]
A critique or escalation can create several billable model calls for one prompt, and the routing layer has to save enough expensive inference to cover that overhead.
- [10]
On Terminal-Bench 2.1, HydraFusion improved verified task quality by 4.9 percentage points while cutting GitHub's estimated workflow cost by 67% compared with Claude Opus 5.
- [11]
Terminal-Bench 2.1 contains 89 container-based tasks and was released as a corrected version of Terminal-Bench 2.0 after maintainers modified tasks with dependency, timeout, resource, and grading problems.
- [12]
On CheckpointBench, GitHub's internal benchmark drawn from Copilot coding sessions, HydraFusion came within 0.1 percentage points of Opus 5 while reducing estimated cost by 65%.
- [13]
GitHub says HydraFusion treats workflow selection as an optimization problem and uses capability signals for reasoning, code generation, debugging, and tool use to select the most efficient execution pattern to meet the quality bar.
- [14]
GitHub lists complete accounting as an operating principle: aggregate cost and usage across every workflow leg, including drafting, critique, revision, escalation, retry, and fallback.
- [15]
Review steps run in isolated, tool-less contexts, while solver steps use the shared workspace and the normal permission-aware agent loop.
- [16]
If a workflow is cancelled or fails validation, HydraFusion applies no patch.
- [17]
The runtime records the role, outcome, cost, latency, and diagnostics for each leg while presenting one response and one proposed change set to the developer.
- [18]
GitHub launched Auto model selection earlier this year, which reviews the task and matches it to the best-suited model; HydraFusion extends that routing strategy and can construct a longer execution plan.
- [19]
The project was built across GitHub and Microsoft by a group including Aashna Garg, Shengyu Fu, Carlos Castro, Siddharth Singha Roy, and Andy Salerno.
- [20]
On DeepSWE, HydraFusion finished 1.5 percentage points behind Opus 5 at an estimated cost reduction of 36%.
- [21]
Across the three published benchmarks, HydraFusion's quality delta versus Opus 5 spans 6.4 percentage points, from plus 4.9 to minus 1.5.
- [22]
DeepSWE measures agents on 113 long-running repository tasks with behavioral verifiers.
- [23]
A 4.9 percentage point gain on Terminal-Bench 2.1's 89 tasks is about 4.4 tasks.
- [24]
Because usage counts all tokens from every model in the workflow, a cascade that escalates bills the failed cheap draft as well as the stronger model's work.
- [25]
A 1.5 percentage point shortfall on DeepSWE's 113 tasks is about 1.7 tasks.
- [26]
The estimated cost saving on DeepSWE is 31 percentage points smaller than the saving reported on Terminal-Bench 2.1.
- [27]
A dev.to write-up says HydraFusion's classifier extracts diff size, AST depth, dependency graph, user intent, and historical success rate, does not use an LLM-as-judge before each subtask, and that GitHub does not publish the exact model lineup; it describes the classifier as "likely a gradient-boosted tree or logistic regression model".
Sources
2 independent publishers whose own reporting we read for this story.
- dev.toHydraFusion: How GitHub Routes Coding Tasks Across Multiple Models to Match Frontier Performance at Lower Cost
1 article · September 4, 2026
- github.blogProject HydraFusion: Frontier quality via multi-model orchestration
2 articles · September 4, 2026
- runtimewire.comGitHub launches HydraFusion to make several AI models do one coding job
1 article · September 4, 2026
Topics and entities
Topics
- LLM Routing
- Coding Agent Benchmarks
- AI Coding Agents
- AI usage pricing and limits