GitHub's HydraFusion research preview lets Copilot choose how to solve a coding task, not just which model answers it. A request can go straight to one model, start with an efficient model and escalate, or receive a cross-family critique before revision. For a team paying for coding agents, that changes the comparison: the useful unit is the completed task, including every model call it needed.
GitHub highlighted the preview again in its September 10 Copilot release roundup. The September 4 technical announcement explains the routing and its limits. The strongest starting point is a substantial, well-scoped task that can be assigned in one prompt—not a long conversation that changes direction repeatedly.
One selection can lead to different execution paths
You select HydraFusion in Copilot CLI as you would select a model. Its runtime then chooses among these patterns:
Scroll sideways to see all 3 columns.
| Pattern | What runs | What the cost comparison must include |
|---|---|---|
| Single | One selected model handles the assignment. | That attempt's full usage. |
| Cascade | An efficient model drafts; a quality gate accepts or escalates. | The initial attempt plus any escalation. |
| Critique | A draft receives read-only, cross-family critique, then one revision. | Drafting, critique, and revision. |
GitHub says the runtime uses capability signals for reasoning, code generation, debugging, and tool use to choose the least complex approach expected to meet the task's needs. It also includes retries and fallback in its accounting.
Our earlier explanation of cross-family critique in Copilot covers the separation between a generated critique and release approval. Here, the question is economic: how much work went into the delivered result, including stages whose output you never see?
Count the whole attempt, including work that is discarded
HydraFusion usage is based on the tokens consumed by the models it invokes, priced at each model's standard rate. Selecting it does not establish one fixed price for a task.
GitHub describes complete accounting across drafting, critique, revision, escalation, retries, and fallback. That matters when an efficient model starts a task but cannot finish it. Comparing only the final model's output would omit earlier usage. A critique that leads to a better revision also adds usage and elapsed time, even if the final response looks like one answer.
Include unsuccessful attempts in the comparison. If a workflow repeatedly abandons a difficult task, a report containing only its successful runs will make it look more useful than it was. Start both alternatives from the same repository commit, give them the same task and required checks, and record what each actually delivers.
Separate the bill from the developer's time
A useful pilot report keeps unlike quantities apart. Record attributable charges where available, elapsed time from assignment to final response, and developer minutes spent inspecting or repairing the result. If you calculate a cost estimate from token usage and published rates instead, label it as an estimate and record the assumptions. Do not combine currency and developer time into a single savings percentage before deciding how your organization values that time.
For task cost, total the measured or estimated cost across all attempts in the pilot and divide it by the number of accepted completions. Define acceptance before starting. For the initial comparison, BaristaLabs recommends counting changes that meet the required checks as delivered, without developer repairs; report repaired completions separately. Keep the count of assigned tasks beside the cost figure. Otherwise, a low cost per completion can conceal the assignments that never finished. If nothing was accepted, report the cost and the lack of completions; there is no meaningful cost-per-completion result yet.
For elapsed time, retain individual durations rather than only an average. The Cascade path may finish after its initial draft or continue through escalation. Those experiences can feel very different to someone waiting for a change. A team handling urgent fixes may care more about unusually long runs than about a small reduction in average spend.
Human effort belongs in a separate column because billing data cannot tell you how much cleanup a change required. Note whether the developer accepted it as delivered, repaired it, or abandoned it. These are BaristaLabs' suggested measurement categories, not fields that GitHub promises HydraFusion will export.
GitHub says the runtime internally records each stage's role, outcome, cost, latency, and diagnostics. Its announcement does not establish a customer-facing export for all those details. Use the usage and execution evidence your environment actually exposes, and note any gap rather than guessing which path ran.
Read the benchmark as a preview result
GitHub reports controlled offline evaluations on TerminalBench 2.1, DeepSWE, and its internal CheckpointBench. The published table shows lower estimated workflow cost than the evaluated Opus 5 baseline in all three, with higher verified task quality on TerminalBench and slightly lower quality on the other two.
Those results describe the best tuned configuration under the stated model pool, pricing assumptions, and evaluation conditions. GitHub also says it refined the routing policies across these benchmarks during development. They are useful evidence for trying the approach, but they do not establish the savings or quality a different repository will receive.
A practical evaluation should answer a narrower question: does adaptive orchestration improve the cost and time needed to finish your recurring class of coding work? Choose tasks with outcomes that a reviewer can judge, such as a specified behavior change with relevant tests. Keep the task class recognizable across both the HydraFusion runs and the comparison runs.
Start with work that does not need constant steering
The research preview is available through /experimental in Copilot CLI on all GitHub Copilot plans. GitHub gives this setup sequence:
- Run
/updateto install the latest CLI version. - Run
/experimental on. - Run
/modeland select HydraFusion (Research Preview).
GitHub recommends substantial, well-scoped first-turn tasks for the current preview and identifies stronger multi-turn performance as future work. That makes a fully described implementation task a better initial trial than an exploratory session where requirements emerge through conversation.
The interface shows workflow stages but withholds intermediate drafts until it returns one coherent result. GitHub explains that drafts may be revised or discarded. If your developers normally redirect an agent by reading its work in progress, include that waiting experience in the trial: less visible intermediate output can change how comfortably they supervise the task.
Model choices, workflows, availability, and product behavior may change during the research preview. Record the CLI version and evaluation date with your results so a later run has a meaningful comparison point.
HydraFusion makes model coordination part of the product rather than something a developer has to arrange manually. For a first trial, keep the assignment fixed, count the complete attempt, and judge the delivered change. That will tell you more than the price of the model that happened to speak last.
Sources
- GitHub: Project HydraFusion—frontier quality via multi-model orchestration, September 4, 2026.
- GitHub Copilot weekly releases—September 7, published September 10, 2026.
Coding-agent evaluation
Compare coding agents on work your team actually ships
BaristaLabs can help define representative tasks, acceptance criteria, and cost measurements for a coding-agent pilot.
Bring a redacted task description and the checks your team requires.
Practical AI Workflow Notes
Want more practical AI operations ideas?
Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.