GitHub tests HydraFusion, which routes your prompt across multiple AI models

GitHub announced Project HydraFusion, a Copilot research preview that treats code task execution as an optimization problem: instead of sending every prompt to a single fixed model, it builds an execution plan at runtime using models from multiple providers, chosen according to task complexity. The news was reported by InfoQ and is already available as a preview across all Copilot tiers, accessible via the /experimental setting inside GitHub Copilot CLI.

The point that matters for those running Copilot in production isn't yet another model, but rather an orchestration layer. HydraFusion evaluates the incoming prompt using explicit capability signals, designed for complex operations: multi-step reasoning, automatic code generation, structured debugging, and advanced tool use. Based on that, it decides how to execute.

The three execution patterns

Instead of a static model, HydraFusion routes the request through one of three runtime patterns, based on complexity and context:

• Single: a single selected model runs directly, when it has enough capability to solve the task on its own. Optimizes for speed and low latency.
• Cascade: a more efficient (and cheaper) model generates a draft solution, which goes through a quality gate. If it meets the requirements, it's accepted; if not, the task escalates to a stronger model.
• Critique: a drafting model produces an initial solution, evaluated by an independent, read-only critic model from a different model family, without access to tool execution (the text compares this to the Rubber Duck review pattern). The original model then makes a single structured revision based on that feedback.

In practice, it's the idea that "not every task needs the most expensive model" turned into architecture. A trivial autocomplete or refactor doesn't justify invoking a frontier model; a multi-step bug fix does, and it still gets a second opinion before the patch is applied.

The five rules that underpin execution

GitHub describes five operational principles that anchor the architecture, and it's worth paying attention to them, because that's where the difference between a "demo" and "something that runs in production" lives:

1. Full accounting: tracks token cost and usage at each leg of the flow (draft, critique, revision, escalation, retry, and fallback).
2. Bounded execution: strict timeouts and cancellation handles.
3. Isolated review steps: prevent modifying actions within a tool-free environment.
4. Failure-proof application: rejects patches if validation fails or execution is canceled.
5. Validated routing: checks model availability and bindings before the runtime starts.

The highlight, for the dev who worries about the bill, is per-leg accounting of the flow. Since a single prompt can go through drafting, critique, and revision, cost stops being "one call, one price" and becomes the sum of multiple calls, potentially across different models. Having this tracked per leg is what makes it possible to understand where the bill comes from.

The numbers GitHub presents

In controlled offline evaluations across three agentic coding benchmarks, GitHub claims the selective flows matched or exceeded baseline quality while substantially reducing estimated cost. The two results cited:

| Benchmark | Quality vs. baseline | Estimated cost | |---|---|---| | TerminalBench 2.1 | +4.9 percentage points in verified task quality | 67% lower than Claude Opus 5 | | CheckpointBench | technical tie (0.1 p.p. difference) | 65% lower |

CheckpointBench is an internal, multi-turn benchmark built from real, replayable agentic coding sessions from Copilot itself, anchored to specific public repositories and immutable commits. The comparison baseline in both cases is Claude Opus 5.

A necessary editorial caveat: these are GitHub's own numbers, from a controlled offline evaluation, not an independent measurement. "Matching quality while cutting two-thirds of the cost" is the central promise, and it's exactly the kind of claim that only real-world use, with your code and your context, can confirm or disprove.

How to turn it on in your environment

The feature is available as a preview for users on all Copilot tiers, via /experimental inside GitHub Copilot CLI. The described path is to update the CLI, enable experimental mode, and select HydraFusion in the model picker:

# update the CLI environment, then inside the session:
/experimental on
/model   # select HydraFusion in the interface

Billing follows the standard token rates of the models actually invoked during execution. In other words: there's no fixed HydraFusion price, you pay for whatever each leg of the flow consumes on the underlying models. Hence the importance of that full accounting, so you're not caught off guard.

What changes for those building in Brazil

For Brazilian teams already paying for Copilot in production, the practical takeaway is twofold. On one hand, multi-model routing is a way to buy frontier-level performance without paying frontier prices on every request, which matters in a scenario where AI costs are billed in dollars and every call weighs on the budget. On the other hand, the bill becomes less predictable: a prompt that escalates from Cascade to the strong model, or that triggers the Critique pattern, costs more than a Single one. For those doing AI FinOps, monitoring consumption per leg stops being optional.

It's also worth noting what remains open. There's no general availability date (it's still a research preview), we don't know exactly which models enter the routing pool beyond the reference to Opus 5, and the benchmarks are internal. The Critique pattern, with a read-only critic model from a different family reviewing the draft before applying a patch, is the one that promises the most in terms of quality, but it's precisely the one that adds the most calls, and therefore cost, per task. Testing on tasks representative of your repository, comparing quality and billing against your current model, is the only honest way to know if the trade-off pays off.