GitHub launches HydraFusion to make several AI models do one coding job

The Copilot preview routes tasks through single-model, cascade, or critique workflows, trading extra inference for lower estimated costs.

By · Published

Primary source: The GitHub Blog

Why it matters

HydraFusion moves competition in AI coding from choosing one frontier model to controlling the router that allocates tasks, inference spending, and provider traffic.

A futuristic workstation with a holographic display showing multiple glowing code streams merging into an optimized output, guided by a translucent hand.

GitHub launched Project HydraFusion on September 4th, a GitHub Copilot research preview that assembles coding workflows from multiple AI models instead of sending every prompt to one selected model.

The project was built across GitHub and Microsoft by a group including Aashna Garg, a principal applied scientist working on Copilot; Shengyu Fu, GitHub's partner applied science manager for Code AI; Carlos Castro, a partner architect for Copilot; Siddharth Singha Roy, a Code AI research scientist; and Andy Salerno, a principal software engineer on Copilot.

HydraFusion is available through the experimental menu in GitHub Copilot CLI for users on every Copilot plan. Developers enable experimental features, open the model picker, and select HydraFusion as though it were another model. The orchestration layer then decides how many models to call and what role each one should play.

GitHub is extending the routing strategy it introduced with Copilot's automatic model selection. Auto selection chooses a model based on factors including task complexity and system availability. HydraFusion can construct a longer execution plan, asking one model to draft, another to review, and the first to revise its work. It can also begin with a cheaper model and escalate only when a quality gate rejects the result.

That changes the unit GitHub is selling. Model access is becoming interchangeable inside Copilot; the orchestration system determines which provider receives a request, how much inference gets spent, and whether a second opinion is worth its cost.

Three routes through the model pool

HydraFusion currently selects among three patterns. A single workflow sends the task directly to one model. A cascade starts with an efficient model and escalates to a stronger one when the draft fails an acceptance check. A critique workflow sends a draft to a read-only reviewer from another model family, then gives the original drafting model one revision.

The critique pattern builds on Copilot CLI's existing rubber duck agent, which uses a separate model to inspect a plan, implementation, or test strategy. HydraFusion turns that second-opinion mechanism into one option inside a router that also accounts for cost and task difficulty.

GitHub says review models run without tools and cannot modify the repository. Solver models retain the shared workspace and Copilot's permission-aware agent loop. If a workflow is cancelled or fails validation, HydraFusion applies no patch. The runtime also records the role, outcome, cost, latency, and diagnostics for each leg while presenting one response and one proposed change set to the developer.

Users will still pay for the underlying inference. GitHub says HydraFusion usage is calculated from all tokens consumed by every model in the workflow, using each model's standard Copilot rate. A critique or escalation can therefore create several billable model calls for one prompt. The routing layer has to save enough expensive inference to cover that overhead.

GitHub's benchmarks show savings, with controlled conditions

GitHub evaluated fixed HydraFusion policies against Claude Opus 5 and GPT-5.6 Sol across Terminal-Bench 2.1, DeepSWE, and CheckpointBench. The published comparison table reports HydraFusion against Opus 5 and uses the best tuned HydraFusion configuration.

On Terminal-Bench 2.1, HydraFusion improved verified task quality by 4.9 percentage points while cutting GitHub's estimated workflow cost by 67%. Terminal-Bench 2.1 contains 89 container-based tasks and was released as a corrected version of Terminal-Bench 2.0 after maintainers modified tasks with dependency, timeout, resource, and grading problems.

On DeepSWE, HydraFusion finished 1.5 percentage points behind Opus 5 at an estimated cost reduction of 36%. DeepSWE measures agents on 113 long-running repository tasks with behavioral verifiers. On CheckpointBench, GitHub's internal benchmark drawn from Copilot coding sessions, HydraFusion came within 0.1 percentage points of Opus 5 while reducing estimated cost by 65%.

Those numbers remain GitHub-run offline evaluations. GitHub held task inputs, tools, execution limits, pricing assumptions, grading conditions, and reasoning levels constant, but the results cover selected benchmark revisions and tuned routing policies. CheckpointBench is also controlled by GitHub. The research preview is the first test of whether the same trade-offs survive real repositories, longer conversations, network delays, retries, and developers changing requirements halfway through a task.

GitHub recommends starting with substantial, well-scoped, first-turn coding requests. Multi-turn sessions are still a focus of development, and HydraFusion currently withholds intermediate drafts because a later critic or escalation may discard them. That produces a cleaner final response while giving developers less visibility during a long workflow.

HydraFusion's immediate advantage belongs to GitHub as much as to Copilot users. A successful router lets GitHub reserve costly frontier models for the prompts that need them, shift routine work to cheaper models, and incorporate new providers without forcing developers to rethink their workflow. The model picker remains visible. The consequential choice increasingly happens after the developer presses enter.

Reader comments

Conversation for this story loads after sign-in.