AIREITERGitHub HydraFusion is a research-preview orchestration system for Copilot CLI; its offline benchmark results do not guarantee performance on long, messy repositories.
The answer before the setup
GitHub HydraFusion is worth trying if you have a GitHub Copilot plan and a substantial, well-scoped coding task that can be described in one prompt. I would not make it the default for critical production changes or long back-and-forth sessions yet, because GitHub still labels it a research preview and says stronger multi-turn support is future work.
HydraFusion is not a new foundation model. It is a runtime orchestration system inside GitHub Copilot CLI that decides whether a task needs one model, an escalation path, or an independent review before returning a result.
Enable HydraFusion in Copilot CLI
The preview is enabled from Copilot CLI rather than from a normal VS Code model picker. GitHub’s official announcement says it is available across Copilot plans through an experimental command sequence, while the Copilot CLI quickstart covers installation and authentication separately.
- Update Copilot CLI by running
/update. - Enable experimental features with
/experimental on. - Open the model picker with
/model. - Select HydraFusion (Research Preview).
- Start with one substantial, clearly bounded coding task rather than a long conversational project.
If HydraFusion does not appear, update the CLI first and confirm that your Copilot account, organization policy, and CLI build support the preview. GitHub’s official announcement is the source of truth for the current command sequence; preview names and availability can change.
Search results also surface AICPS/hydrafusion, an autonomous-vehicle sensor-fusion research repository. That project is unrelated to GitHub’s Project HydraFusion for Copilot.
Match the workflow to the task
HydraFusion chooses among three execution patterns based on the task’s expected quality, cost, and latency needs. The practical choice is not a manual “mode” switch in the current preview; GitHub presents HydraFusion as a model-like option that selects the underlying workflow at runtime.
| Workflow | What happens | Best initial fit | Main trade-off |
|---|---|---|---|
| Single | One model solves the task directly. | Straightforward edits, explanations, or small fixes. | Lowest apparent overhead, but no escalation or independent review. |
| Cascade | An efficient model drafts first; a quality gate can escalate the task to a stronger model. | Tasks that may be easy but could need more capability. | Saves cost when the first pass works, but adds a gate and possible second call. |
| Critique | One model drafts, an isolated critic from another model family reviews it, and the drafter revises once. | Changes where a second perspective can catch mistakes. | More calls and latency, with no direct tool access for the critic. |
Single: direct execution
Single is the simplest path. GitHub says one solver receives the task and works in the normal permission-aware Copilot agent loop, making it a natural fit for a request with a clear implementation and short test path.
The benefit is lower workflow overhead, but Single provides no built-in second opinion.
Cascade: cheaper first, stronger only when needed
Cascade starts with an efficient model and uses a quality gate to decide whether the result is good enough or should be escalated. Its economic argument is selective escalation: routine requests should not consume the strongest available model by default.
Cascade can save money when its first pass clears the gate, but GitHub does not publish a universal escalation rate; evaluate it by observed task outcomes rather than assuming that every request follows the cheap path.
Critique: draft, independent review, one revision
Critique adds a separate reviewer from a different model family. GitHub says the critic runs in an isolated, tool-less context, reviews the draft, and sends feedback to the original solver for one revision; it cannot directly edit the repository.
That makes Critique automated peer review, but it adds a model call and latency.
Read the benchmark table as a trade-off, not a promise
GitHub’s offline tests show benchmark-specific quality-cost trade-offs, not a promise of 67% lower cost for every Copilot task.
| Benchmark | HydraFusion quality vs. Claude Opus 5 | Estimated cost vs. Claude Opus 5 | What to take from it |
|---|---|---|---|
| TerminalBench 2.1 | +4.9 percentage points | 67% lower | The strongest reported result: better verified task quality at lower estimated cost. |
| DeepSWE | −1.5 points | 36% lower | A meaningful saving with a measurable quality concession on difficult repository work. |
| CheckpointBench | −0.1 points | 65% lower | Near-parity quality in GitHub’s internal replay-style benchmark, at much lower estimated cost. |
GitHub used consistent evaluation settings and counted all workflow calls, including retries, critiques, escalations, and fallbacks, according to its official HydraFusion announcement.
CheckpointBench is described as replaying curated Copilot sessions against immutable public-repository commits. That makes it more relevant to coding-agent work than a simple text-generation test, but it is still a controlled benchmark. DeepSWE’s lower HydraFusion quality result is important because it prevents the table from being read as a universal win.
Independent real-world evidence is still thin. @DoDataThings on X, an independent builder, identifies the key validation concern:
“The model that plans doesn't have to be the model that writes the code. GitHub's note says HydraFusion matched or exceeded the Opus 5 baseline in controlled offline evals, and offline eval to messy real repo is where orchestration usually loses its margin. Curious how much of the cost gap survives that.”
The post is a question, not a measurement, but it identifies the right test: cost and quality on messy repositories.
The operational details that matter in a real repository
HydraFusion’s value depends on more than selecting a cheaper model. GitHub documents controls for accounting, cancellation, routing validation, review isolation, and patch application because multiple model calls create more operational states than a single direct request.
| Control | What it means for a user |
|---|---|
| Cost and time controls | HydraFusion tracks calls across workflow legs and supports bounded execution, but critique, escalation, retries, and fallbacks can still increase latency or total usage. |
| Routing and patch controls | GitHub says it validates routes and applies no patch after an invalid or cancelled workflow; neither control proves that the selected route or final code is correct. |
| Review isolation | Critics are read-only and tool-less while solvers use the shared workspace, reducing direct reviewer changes but leaving diff review and testing necessary. |
The GitHub announcement also documents a visibility trade-off: intermediate drafts are withheld until the final result, giving a cleaner response but hiding draft, retry, escalation, and discard behavior while you wait.
A sensible first test for HydraFusion
The best first test is a bounded repository task with an objective acceptance check, not an open-ended request to “improve” a codebase. Treat the preview as an experiment with a known starting commit and a fixed definition of success.
- Create a clean branch or worktree and record the starting commit.
- Choose one task with a narrow file boundary and a reproducible test command.
- State the expected behavior, constraints, and tests in the first prompt.
- Let HydraFusion complete the task, then inspect the diff rather than accepting it because the agent reports success.
- Run the relevant tests yourself and check for unrelated file changes.
- Record the latency, visible usage or cost data, retries, escalation behavior, and final test result if the CLI exposes them.
- Repeat with a few tasks before comparing HydraFusion with a fixed model or changing your team default.
Do not use one successful patch to validate the benchmark claims. The useful unit is a small set of tasks covering a routine fix, a cross-file change, and a deliberately ambiguous case where escalation or critique might matter.
What HydraFusion costs and what it does not promise
GitHub does not publish a separate dollar price for HydraFusion in the announcement. Instead, it says usage is charged according to the standard token rates of the underlying models, so the final cost depends on which models and workflow legs the runtime uses.
| Billing question | Current answer |
|---|---|
| Is there a separate HydraFusion subscription fee? | No separate HydraFusion fee is stated in GitHub’s announcement. |
| How is usage billed? | By tokens consumed from the constituent models at their standard rates. |
| Can one task use several billable calls? | Yes. Cascade and Critique can involve multiple workflow legs, and accounting includes retries and fallbacks. |
| Does a 67% benchmark saving equal a 67% customer saving? | No. It is an estimated comparison for a particular benchmark, policy, model pool, and pricing setup. |
| Is HydraFusion a stable production feature? | No. GitHub labels it a research preview and says models, workflows, availability, behavior, and name may change. |
Use HydraFusion first on inspectable, single-prompt tasks; keep a fixed-model fallback for long multi-turn or high-consequence work until repository-level tests support broader use.
HydraFusion FAQ
Is HydraFusion a model or a router?
HydraFusion is a runtime multi-model orchestration system in GitHub Copilot CLI, not a standalone foundation model; it selects models and execution patterns for a coding task.
How do I enable HydraFusion in Copilot CLI?
Run /update, /experimental on, and /model, then select HydraFusion (Research Preview).
Is HydraFusion available on every Copilot plan?
GitHub says the preview is available across Copilot plans through Copilot CLI, although account, organization, CLI-version, or availability changes can affect visibility.
Which underlying models does HydraFusion use?
GitHub describes selection across models from multiple providers but does not publish a fixed per-request roster, so do not assume a named model handles every task.
Does HydraFusion always beat Claude Opus 5?
No: GitHub reports a gain on TerminalBench 2.1, near-parity on CheckpointBench, and a 1.5-point deficit on DeepSWE.
Does HydraFusion cost extra?
Usage is billed at the standard token rates of underlying models, and a route can call multiple models; GitHub states no separate HydraFusion dollar price in the announcement.
Is HydraFusion available in VS Code?
The launch material documents the preview through Copilot CLI, so confirm any broader availability in current GitHub documentation.
Is HydraFusion safe to let edit a repository?
GitHub describes permission-aware solvers, isolated critics, validated routing, bounded execution, and no-patch behavior for invalid or cancelled workflows; still review the diff and run tests before merging.