AIREITERA coding task can look simple until a cross-file dependency appears. Project HydraFusion chooses a workflow it expects to clear a quality bar, but the research preview still hides the exact route and does not promise the same savings on every repository.
The routing decision in one view
Project HydraFusion is a runtime orchestration layer in GitHub Copilot CLI, not a new foundation model. You select HydraFusion (Research Preview); the runtime selects the models and execution pattern.
| Workflow | Runtime sequence | Main benefit | Main trade-off |
|---|---|---|---|
| Single | One selected model solves the task directly. | Lowest workflow overhead and simplest latency path. | No built-in escalation or independent review. |
| Cascade | An efficient model drafts; a quality gate accepts the result or escalates to a stronger model. | Avoids using the strongest model when the first pass is sufficient. | A failed gate can add model calls, tokens, and waiting time. |
| Critique | A model drafts; an independent read-only critic from another model family reviews it; the solver revises once. | Adds a second perspective for error-prone changes. | Adds serial work, and the critic cannot run tools or edit the repository. |
To try the preview, run /update, then /experimental on, then /model, and select HydraFusion (Research Preview). GitHub documents this sequence in its official HydraFusion announcement. The preview is available across Copilot plans, although organization-managed access can depend on the Copilot CLI policy enabled by an administrator.
These are execution patterns, not three public switches for manually forcing a request. The launch material documents selecting HydraFusion and letting the runtime balance performance, cost, and latency.
What the runtime is trying to predict
GitHub says HydraFusion uses capability signals for reasoning, code generation, debugging, and tool use. It chooses the most efficient execution pattern it expects will meet the request’s quality bar, but GitHub does not publish the thresholds or a deterministic rule such as “three files means Cascade.”
Task shape is therefore a guide, not a routing guarantee: a narrow edit with an obvious test path is conceptually suited to Single, a possibly difficult request fits Cascade’s selective escalation, and a change that benefits from independent review fits Critique. The announcement does not provide a fixed per-request model roster or readable route trace.
Can you force Single, Cascade, or Critique?
GitHub documents selecting HydraFusion and letting its runtime choose the workflow; it does not document a public command for forcing one of the three patterns. Use a fixed Copilot model when predictable routing matters.
When each workflow earns its extra call
Single: direct execution when the path is obvious
Single sends the task through one solver in Copilot’s normal permission-aware agent loop. It fits a small, well-specified edit, a short explanation, or a fix with a clear implementation and test path.
Its advantage is a simpler cost and latency profile. The workflow does not deliberately add a quality gate or second opinion, so the developer remains the primary reviewer if the solver misunderstands the task.
Cascade: escalate only when the first pass misses
Cascade starts with an efficient model. A quality gate evaluates the candidate and can escalate the task to a stronger model when the candidate does not clear the bar.
The economic logic is conditional:
- The first model handles work it can complete adequately.
- The quality gate filters weak or uncertain candidates.
- Only tasks that need more capability take the stronger path.
This can reduce average workflow cost compared with sending every task to a frontier model. An escalation, retry, or fallback can still create a more expensive and slower tail, and GitHub has not published a universal escalation rate for repository-specific planning.
Critique: pay for a second perspective
Critique is a draft-review-revision loop. The first solver creates the result, a critic from a different model family reviews it in an isolated, tool-less, read-only context, and the original solver revises once.
The critic cannot run project tests, inspect a generated file through a command, or apply a repair itself. Critique buys review diversity, not independent end-to-end implementation.
The benchmark ledger: lower cost is not one quality promise
GitHub evaluated fixed HydraFusion policies against Claude Opus 5 across three agentic coding benchmarks. The following figures come from GitHub’s official announcement.
| Benchmark | HydraFusion quality vs. Claude Opus 5 | Estimated workflow cost vs. Claude Opus 5 | Practical reading |
|---|---|---|---|
| TerminalBench 2.1 | +4.9 percentage points | 67% lower | Higher verified task quality at lower estimated cost in this evaluation. |
| DeepSWE | −1.5 points | 36% lower | A meaningful saving with a measurable quality concession on difficult repository work. |
| CheckpointBench | −0.1 point | 65% lower | Near-parity quality at substantially lower estimated cost. |
The mixed quality results are the point: HydraFusion is intended to add inference when the expected quality gain justifies the cost and latency, not to use more models on every request.
GitHub says the evaluation kept inputs, tools, execution limits, pricing, and grading consistent and counted drafting, critique, revision, escalation, retry, and fallback legs. These remain controlled offline estimates tied to the evaluated policies, model pool, benchmark revisions, and pricing assumptions.
They do not establish that a normal Copilot task will cost 67% less or that HydraFusion will beat Claude Opus 5 in a given codebase. GitHub recommends beginning with substantial, well-scoped, first-turn coding tasks that fit in one prompt while the preview is tested on live workloads.
The cost equation has three parts
Separate expected token cost, tail cost, and waiting time when judging HydraFusion.
| Factor | Single | Cascade | Critique |
|---|---|---|---|
| Initial work | One solver | Efficient solver first | Drafting solver first |
| Extra work | None by design | Stronger model after a failed gate | Critic plus one solver revision |
| Cost shape | More predictable | Conditional; rises on escalation or retry | Structurally higher than a direct draft |
| Latency shape | Simplest path | Short when accepted; longer after escalation | Extra review and revision extend the path |
| Quality mechanism | Solver capability | Quality gate plus escalation | Independent review plus revision |
Lower estimated workflow cost does not automatically mean a faster response: Cascade may slow escalated cases, Critique adds serial review, and Single returns quickly while leaving more validation to the developer.
GitHub’s Copilot CLI usage documentation says /usage displays session duration, AI Credits consumed, edited lines, and per-model token-use breakdown. Those observations help compare real tasks, but they do not explain every routing decision or expose discarded intermediate drafts.
The black box between prompt and patch
GitHub describes complete accounting across workflow legs, bounded execution with timeout and cancellation behavior, isolated review, validated routing, and fail-safe patch application after invalid or cancelled workflows. These controls reduce operational risk; they do not prove that the route or final code is correct.
GitHub also says the preview holds intermediate drafts until it can return one coherent result. That makes it harder to tell whether a task stayed Single, escalated through Cascade, or went through Critique and revision.
A real user identified the observability gap directly:
“The product feature I’d want next is a readable trace of which model did what and why the router switched.” — @_Mazzana on X
Without a route receipt, developers cannot fully connect a task’s cost, latency, and final patch to the workflow that produced it.
How to use the preview without over-reading it
Treat HydraFusion as an experiment before making it a team default:
- Create a clean branch or worktree and record the starting commit.
- Test one routine fix, one cross-file change, and one ambiguous task with a reproducible acceptance check.
- Put expected behavior, constraints, and test commands in the first prompt.
- Inspect the final diff, check for unrelated file changes, and run the relevant tests yourself.
- Record session duration, visible AI Credit or token usage, test outcome, and any visible retry or escalation signal.
- Repeat across several tasks before comparing HydraFusion with a fixed model.
Do not infer the hidden mode from response length alone. A long response can reflect repository complexity rather than Critique. Keep a fixed-model fallback for long, multi-turn, latency-sensitive, or high-consequence work: GitHub recommends first-turn tasks for the current preview and identifies stronger multi-turn performance as a future focus in its launch guidance.
HydraFusion FAQ
Can I manually select Single, Cascade, or Critique?
Not through a documented HydraFusion mode command. The current control is to select HydraFusion and let its runtime choose; use a fixed model when deterministic routing matters.
How is HydraFusion billed?
GitHub says usage is based on the tokens consumed by the models HydraFusion uses, charged at each model’s standard rate, as described in the official announcement. A benchmark reduction is not a universal customer discount, and multi-leg workflows can consume more than a direct request.
HydraFusion is most compelling when a task is important enough to benefit from selective escalation or review, yet structured enough for verification. For quick work, Single’s simplicity may matter more; for long or high-stakes work, predictable fixed-model behavior can still be the better operational choice until repository evidence supports the extra orchestration.