GitHub's HydraFusion Beats Claude Opus 5 at 67% Lower Cost

GitHub just rolled out a research preview called Project HydraFusion that treats model selection as a runtime optimization problem. Rather than locking you into one LLM, it plans an execution flow across multiple providers, deciding on the fly whether to draft, critique, revise, or escalate. You pick HydraFusion once and it manages the models and workflow behind the scenes.

The core claim is that this compound approach matches or beats a frontier baseline while spending far less. On TerminalBench 2.1, HydraFusion improved verified task quality by 4.9 percentage points at 67% lower estimated cost compared with Claude Opus 5.

Three workflows, one selector

For each request, HydraFusion picks one of three execution patterns based on internal capability signals for reasoning, code generation, debugging, and tool use:

• Single. One selected model solves the task directly.
• Cascade. An efficient model drafts a solution and a quality gate decides whether to accept it or escalate to a stronger model.
• Critique. One model drafts a result, an independent read-only critic from a different model family reviews it, and the drafting model revises once.

The critique pattern deserves attention: the reviewer runs in an isolated, tool-less context so it cannot modify the repo, while the solver keeps the shared workspace and normal permission-aware agent loop. This mirrors how developers already coordinate models manually, automated at runtime.

How to try it

HydraFusion is available on all GitHub Copilot plans through /experimental in the GitHub Copilot CLI. Billing is based on tokens consumed by whichever models HydraFusion uses, at each model's standard rate, with no orchestration surcharge. Enable it with:

/update
/experimental on
/model     # then select HydraFusion (Research Preview)

Benchmark numbers

GitHub evaluated fixed HydraFusion policies against Claude Opus 5 and GPT-5.6 Sol across three agentic coding benchmarks, with all models at the same medium reasoning level and full cost accounting for every leg, including drafting, critique, revision, escalation, retry, and fallback.

DeepSWE targets challenging repository-level tasks that require navigating large codebases, tracing cross-file dependencies, and producing end-to-end fixes. HydraFusion lands within 1.5 percentage points of Opus 5 there while cutting cost by 36%. CheckpointBench is GitHub's internal set built from real Copilot sessions anchored to specific public repos at immutable commits, making runs fully replayable.

How they tuned it

Rather than hand-tuning thresholds, the team ran beam search over routing policies, using HydraFusion's per-capability scores as a consistent basis for comparing candidates. Each candidate was measured against a frozen baseline on quality, cost, and failure modes. The team iterated across all three benchmarks jointly to avoid overfitting to any single one, and internal operational failures in the eval harness were excluded and rerun.

HydraFusion enforces five operating principles relevant to repo-level agents: complete cost accounting across every leg, bounded execution with explicit timeouts, isolated review contexts, fail-safe patch application (nothing gets applied if a leg fails validation), and validated routing before execution starts.

Strengths and rough edges

GitHub recommends first-turn, single-prompt coding tasks as the best starting point for this preview, with stronger multi-turn performance coming later. The notable trade-off: HydraFusion withholds intermediate drafts until it returns one coherent result, because those drafts may get revised or discarded. That reduces real-time visibility into what the orchestrator is doing, and GitHub acknowledges the wait is a genuine cost.

What changes for developers

Most coding assistants ask you to pick a model up front, forcing a static bet on cost versus quality. HydraFusion routes per task rather than per session, and if the offline numbers hold on real workloads, teams could get Opus-5-tier quality at roughly a third of the spend without changing how they invoke Copilot. It also gives GitHub a clean abstraction for absorbing new frontier models: when new models land in Copilot, the team can evaluate and fold them into the pool without users needing to track which one to reach for.