What does GitHub Copilot's HydraFusion actually do when you pick it as a model?

GitHub has released a research preview called Project HydraFusion that picks and coordinates multiple AI models behind the scenes. You select it once in the CLI and it decides whether a task needs one model, a draft-then-escalate chain, or a draft-critique-revise loop.

How the thing chooses its own workflow

HydraFusion treats workflow selection as an optimization problem. For every request it evaluates capability signals — reasoning, code generation, debugging, tool use — and picks the least complex pattern expected to meet the quality bar. Three patterns exist today. Single sends the task to one model. Cascade lets an efficient model draft first; a quality gate then decides whether to accept that draft or escalate to a stronger model. Critique lets one model draft, a read-only critic from a different model family review it, and the drafter revise once. Each pattern targets a different quality-to-cost trade-off. Single preserves speed when one model suffices. Cascade keeps a path to stronger inference without always paying for it. Critique adds an independent perspective where review helps more than another unaided attempt.

The runtime records role, outcome, cost, latency, and diagnostics for every leg. Externally you see one coherent response and one permission-aware change set. Internally the system aggregates cost across drafting, critique, revision, escalation, retry, and fallback. Every leg gets an explicit timeout and cancellation behavior. Review steps run in isolated, tool-less contexts while solver steps use the shared workspace. No patch applies when the workflow is cancelled or fails validation. Workflow definitions, model bindings, fallback behavior, and model availability are verified before execution begins.

What the benchmarks show

Fixed HydraFusion policies were evaluated on three agentic coding benchmarks — TerminalBench 2.1, DeepSWE, and CheckpointBench — using Claude Opus 5 and GPT-5.6 Sol as baselines. Each policy used the same task inputs, tools, execution limits, pricing assumptions, grading conditions, and treatment of missing results. The evaluation measured verified task quality and complete estimated workflow cost. Cost accounting included every invoked leg.

On TerminalBench 2.1 the best tuned configuration improved verified task quality by 4.9 percentage points at 67 percent lower estimated cost compared with Opus 5. On DeepSWE it came within 1.5 percentage points of Opus 5 while reducing cost by 36 percent. On CheckpointBench it came within 0.1 percentage points at 65 percent lower cost. These controlled offline results are specific to the evaluated benchmark revisions, workflow configurations, model pool, and pricing assumptions, with all models evaluated at the same medium reasoning level.

TerminalBench 2.1 evaluates coding agents on complex multi-step tasks in terminal environments.

DeepSWE evaluates challenging repository-level software engineering tasks that require navigating large codebases, understanding cross-file dependencies, and producing end-to-end fixes.

CheckpointBench is an internal multi-turn benchmark curated from real GitHub Copilot agentic coding sessions. Each conversation is anchored to a specific public repository and immutable commit, ensuring every session is replayable. The benchmark is balanced across language, task type, difficulty, scrubbed for quality, resulting in a realistic evaluation set that closely mirrors production agentic sessions.

Tuning the routing

The routing policies were shaped by how developers use GitHub Copilot on real coding tasks. To make those workflows reproducible the team curated CheckpointBench from real Copilot coding-session trajectories. They refined the system repeatedly across CheckpointBench, DeepSWE, and TerminalBench 2.1, optimizing across the evaluation sets rather than for any single benchmark. Per-capability scores provided a consistent basis for comparing candidate routing policies. Instead of manually tuning thresholds they used beam search to build the optimal decision policy. Each candidate was measured against a frozen baseline on quality, cost, and failure modes.

This benchmark provides the most complete sequence of runs. The progression was not linear. Between August 11 and August 25 two operational failures in the evaluation harness produced invalid runs. Those failures were excluded from the performance trend, corrected, and followed by continued gains. By August 25 the system had reached its strongest operating points in the recorded series. This development record shows how the policies improved from repeated experiments. The research preview extends that learning loop to real developer workloads.

What you can try today

Access comes through /experimental in GitHub Copilot CLI for users on all GitHub Copilot plans. Usage is based on the tokens consumed by the models HydraFusion uses, priced at each model's standard rate. To try it: run /update to install the latest version, run /experimental on, run /model, then select HydraFusion (Research Preview). Feedback goes through /feedback in Copilot CLI or in the GitHub Community discussion.

For this preview first-turn single-prompt coding tasks are the best place to start. The team will focus on strong multi-turn performance with longer iterative sessions next. The preview is designed to learn which tasks benefit from compound workflows and how orchestration affects latency and cost in practice. For the best experience today start with substantial well-scoped coding tasks that you can hand to Copilot in autopilot mode in a single prompt.

The system shows workflow stages but holds intermediate drafts until it returns one coherent result. Those drafts may be reviewed, revised, or discarded, so showing them live could make unfinished work appear final. Waiting without enough visibility is a real trade-off for developers. The team is actively exploring better progress updates guided by feedback from the research preview.

Results, models, workflows, availability, names, and product behavior may change as they learn from the preview. The next real gain in coding agents will come from combining frontier intelligence with runtime orchestration. HydraFusion is their first bet on that idea: moving from choosing the best model to dynamically constructing the best way to solve each task.

The sources this article was written from

  • GitHub Blog
    https://github.blog/ai-and-ml/github-copilot/project-hydrafusion-frontier-quality-via-multi-model-orchestration/

Read next