GitHub says HydraFusion usage is calculated from all tokens consumed by every model in the workflow, at each model's standard Copilot rate [6]. 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 [5][6]. A cascade that escalates bills the cheap attempt that failed the acceptance gate, then the stronger model's work on top of it [25]. GitHub states the consequence itself: the routing layer has to save enough expensive inference to cover that overhead [7].
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 [8]. That suite holds 89 container-based tasks [9], so 4.9 points is roughly four tasks changing verdict (89 x 0.049 = 4.4) [22]. DeepSWE runs 113 long-running repository tasks with behavioral verifiers [11], and there HydraFusion finishes 1.5 points behind Opus 5, under two tasks [23], for a 36% estimated saving [10]. That saving is 31 percentage points smaller than the Terminal-Bench figure [24]. The quality deltas across the three benchmarks span 6.4 points, from plus 4.9 to minus 1.5 [26]. 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 [9]. 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 [14]. 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 [13]. 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 [15]. 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 [16]. 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 [18], 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 [19]. Cost and usage are aggregated across every leg, including drafting, critique, revision, escalation, retry, and fallback [17], and the runtime records role, outcome, cost, latency, and diagnostics per leg while showing the developer one response and one change set [20]. That per-leg ledger is the number that governs your spend.
