Runtime orchestration arrives in Copilot research preview
GitHub has launched Project HydraFusion, a research preview that treats model selection as an optimization problem rather than a simple pick-one-answer decision. Instead of asking a developer to choose a model for each task, HydraFusion constructs an execution plan at runtime, drawing from a pool of models across multiple providers to draft, review, revise, or escalate work as needed.
The feature extends the company's earlier Auto model selection work, but adds a layer of compound workflows. From the developer's perspective, HydraFusion appears in Copilot like any other model — the orchestration happens behind the scenes. Per request, the system selects one of three execution patterns based on capability signals for reasoning, code generation, debugging, and tool use:
- Single. One model handles the task directly.
- Cascade. An efficient model drafts a solution; a quality gate decides whether to accept it or escalate to a stronger model.
- Critique. A drafting model produces a result, an independent read-only critic from a different model family reviews it, and the original model revises once.
Each pattern targets a different quality-to-cost trade-off. Single preserves speed when one model is sufficient. Cascade gives a cheaper model first crack while keeping a path to stronger inference. Critique adds an independent perspective for tasks where review matters more than another unaided attempt.
GitHub frames this as bringing manual multi-model coordination — asking one model to review another's work, escalating hard problems — into the runtime. The system evaluates each request and picks the least complex workflow expected to meet the quality bar, adding model calls only when likely to improve the result. The model pool is designed to evolve as new models enter Copilot.
Operating principles
Making adaptive orchestration dependable for repository-level work required constraints on execution, review, cost, and repository state. HydraFusion is built around five principles:
- Complete accounting. Aggregate cost and usage across every workflow leg, including drafting, critique, revision, escalation, retry, and fallback.
- Bounded execution. Each leg has explicit timeout and cancellation behavior to keep execution and cost within limits.
- Isolated review. Review steps run in isolated, tool-less contexts while solver steps use the shared workspace and permission-aware agent loop — so reviewers can assess work without modifying the repository.
- Fail-safe application. No patch is applied when the workflow is cancelled or fails validation, preventing incomplete changes from landing.
- Validated routing. Workflow definitions, model bindings, fallback behavior, and model availability are verified before execution starts.
Internally, the runtime records the role, outcome, cost, latency, and diagnostics of each leg. The developer receives one coherent response and one permission-aware change set.
Evaluation results
| Benchmarks | Cost vs. Opus 5 | Quality vs. Opus 5 |
|---|---|---|
| TerminalBench 2.1 | 67% lower | +4.9 points |
| DeepSWE | 36% lower | -1.5 points |
| CheckpointBench | 65% lower | -0.1 points |
Fixed HydraFusion policies were benchmarked against Claude Opus 5 and GPT-5.6 Sol across three agentic coding benchmarks. All models ran at the same medium reasoning level. The evaluation measured verified task quality — the share of tasks confirmed as correctly answered — and complete estimated workflow cost, including every invoked leg. Results were controlled for task inputs, tools, execution limits, pricing assumptions, grading conditions, and treatment of missing results. The figures reflect the best tuned configuration.
TerminalBench 2.1. On this evaluation of complex, multi-step tasks in terminal environments, HydraFusion improved verified task quality by 4.9 percentage points at 67% lower estimated cost than Claude Opus 5.
DeepSWE. This benchmark covers repository-level engineering tasks requiring navigation of large codebases and cross-file fixes. HydraFusion came within 1.5 percentage points of Opus 5 while cutting cost by 36%.
CheckpointBench. An internal, multi-turn benchmark curated from real GitHub Copilot agentic coding sessions, anchored to public repositories at immutable commits. HydraFusion came within 0.1 percentage points of Opus 5 at 65% lower cost.
An internal tester echoed the results: "So far, the reasoning and task solving capability [of HydraFusion] is at or better than Opus," said a principal software engineer at Microsoft.
Policy tuning and the research loop
HydraFusion's routing policies were shaped by how developers actually use Copilot. CheckpointBench was curated from real Copilot session trajectories to make these workflows reproducible. The team refined HydraFusion iteratively across all three benchmarks, using beam search — not manual threshold tuning — to build the optimal decision policy. Each candidate routing policy was measured against a frozen baseline for quality, cost, and failure modes.
TerminalBench 2.1 provides the clearest record of that iterative improvement. Between August 11 and August 25, two operational failures in the evaluation harness produced invalid runs; those were excluded from the trend, corrected, and followed by continued gains. By August 25, HydraFusion had reached its strongest operating points in the recorded series. The development record is non-linear, which the team says highlights the need for the broader three-benchmark evaluation — including DeepSWE's more demanding tasks — before drawing firm conclusions.
Using the preview
First-turn, single-prompt coding tasks are the best place to start with HydraFusion. The team says it will focus on strong multi-turn performance next. The preview is designed to learn which tasks benefit from compound workflows and how orchestration affects latency and cost in practice. Feedback can be submitted via /feedback in Copilot CLI or the GitHub Community discussion.
HydraFusion remains an active research effort — results, models, workflows, and product behavior may change. The underlying bet is that the next real gain in coding agents comes from combining frontier intelligence with runtime orchestration, moving from choosing the best model to dynamically constructing the best way to solve each task.
