Project HydraFusion: GitHub Copilot will die Modellauswahl durch Workflows ersetzen

For the last year, the most consequential decision in a Copilot session has been the model picker. Opus for the hard refactor, a cheaper GPT for the boilerplate, Auto when you could not be bothered. Auto model selection makes that decision for you, one model per request, and gives you a 10% discount for trusting it.

On 4 September 2026 GitHub published Project HydraFusion, a research preview that changes the unit of decision. Instead of choosing a model, the runtime builds an execution plan per prompt: one model solves it directly, or a cheap model drafts and a quality gate decides whether to escalate, or one model drafts and a read-only critic from a different model family reviews it before a single revision. It launched in Copilot CLI and, on 30 September, reached VS Code and the GitHub Copilot app. GitHub's headline number is 67% lower estimated cost than Claude Opus 5 with higher verified quality on TerminalBench 2.1.

That headline deserves the scrutiny this article gives it. But the more durable story is architectural. Teams have been hand-rolling draft-then-critique and cheap-then-escalate patterns in their own agent code for eighteen months. HydraFusion moves those patterns into the Copilot runtime, with cost accounting per leg, bounded execution, and isolated review. That is what a DevOps engineer should evaluate, and this article gives you a way to do it on your own workload.

If you want the CLI fundamentals first, my Copilot CLI practical guide and evaluating LLM models in Copilot cover the ground this post builds on.

Status: research preview. The HydraFusion documentation is explicit: "there's no service level agreement (SLA), and HydraFusion isn't intended for production workloads."

Surfaces: Copilot CLI since 4 September, behind experimental mode. Since 30 September, also VS Code 1.140 or later (or VS Code Insiders) and the GitHub Copilot app. The documentation lists only those three surfaces, so Copilot cloud agent, JetBrains IDEs, Visual Studio, and Copilot Chat on github.com are not included.

Availability: The 30 September changelog says it "is available to Copilot Pro, Pro+, Business, and Enterprise users" and that "for Copilot Business and Enterprise, an administrator must enable preview features". The documentation adds that HydraFusion only uses models that your plan includes and your policies allow, and does not appear in the picker if none qualify. If your plan is not on the changelog's list, check the picker rather than assuming either way.

Billing: from the documentation, "you're billed for each model it uses, at that model's standard rate. There's no separate charge for HydraFusion, and the discount for auto model selection doesn't apply." Since 1 June 2026, all Copilot plans bill in AI credits (1 credit = $0.01) based on tokens per model, so a HydraFusion request costs the sum of every leg it runs. Model multipliers survive only for legacy annual plans on request-based billing. The documentation also says HydraFusion "keeps your main conversation on the same model whenever possible" to keep the benefit of cached tokens, and that assisting models such as a reviewer "receive only the context they need".

If HydraFusion does not appear in the CLI picker, the documentation suggests switching to the prerelease channel with /update prerelease. In an organisation, ask whether preview features are enabled for you. The new default enablement policy that takes effect on 22 October does not change that, because "preview features remain opt-in".

Scope guidance from GitHub: unchanged since launch. "First-turn, single-prompt coding tasks are the best place to start", ideally "substantial, well-scoped coding tasks that you can hand to Copilot in autopilot mode in a single prompt". Multi-turn performance is explicitly the next focus. The documentation now frames the choice plainly: use Auto for everyday work, and HydraFusion for tasks "such as fixing a complex bug or making a change across several files, where additional model passes may be worth the extra time and AI credits".

GitHub describes HydraFusion as treating "workflow selection as an optimization problem". Per prompt, it scores the task on capability signals (reasoning, code generation, debugging, tool use) and picks "the least complex workflow expected to meet its needs, using additional model calls only when they are likely to improve the result".

The Critique pattern follows the same approach as Rubber Duck in Copilot CLI, which GitHub documents as deliberately running "on a different AI model from the one driving your session", with "read-only access to your codebase" so that it "cannot edit files or run commands that change your environment". HydraFusion automates that invocation and bounds it to one revision.

GitHub describes the runtime guarantees as follows:

Two of these matter more than the others for operations, and one needs a caveat. Isolated review means the critic never touches your workspace and never has tools, which is the correct trust boundary for a step whose only job is to disagree. Fail-safe application is the caveat. The blog describes applying "no patch when the workflow is cancelled or fails validation", but the limitations section of the product documentation says: "If HydraFusion discards a draft, changes that the draft already made in your workspace, such as file edits, aren't undone automatically." Solver legs run in the shared workspace, so read the principle as HydraFusion will not knowingly finish on a failed result, not your working tree is protected. Review the diff before you commit, as you would with any agent.

GitHub did not hand-tune thresholds, instead using beam search to construct the decision policy, measuring each candidate "against a frozen baseline on quality, cost, and failure modes" across TerminalBench 2.1, DeepSWE, and an internal benchmark called CheckpointBench. The hill-climbing record they publish is refreshingly honest: two harness failures between 11 and 25 August produced invalid runs that were excluded, and the strongest configurations arrived on 25 August.

As noted in the GitHub Community announcement: "Auto V1 (Jan 2026, capacity/SKU-aware per-request selection) → Auto V2 aka. HyDRA (May 2026, intent-scored routing) → HydraFusion (Aug 2026, per-turn orchestration and cache-aware workflows)." The HyDRA paper describes a ModernBERT encoder that scores each query on reasoning, code generation, debugging, and tool use, the same four capability signals GitHub cites for HydraFusion. It states that HyDRA "is deployed to all users in GitHub Copilot's VS Code Chat auto-mode", and its first author, Aashna Garg, is also credited on the HydraFusion post. Community write-ups that linked HydraFusion to a routing research paper were right: HydraFusion builds on the router behind Auto and adds multi-model workflows on top.

The model pool is still not published, and that is now a stated policy. The same FAQ says "we don't publish a fixed roster" because "the lineup shifts as new models ship", and adds: "We know some teams need more control here and we're looking into it." The benchmark charts compare HydraFusion with Claude Opus 5, Claude Sonnet 5, and GPT-5.6 Sol, Terra, and Luna as solo models. Those are comparators, not a disclosed pool, and they are now a generation old: Claude Opus 5.5, GPT-6 Sol, GPT-6 Luna, Claude Sonnet 5.5, and GPT-6.1 Sol all arrived in Copilot between 22 and 29 September.

GitHub says new models can be evaluated and incorporated "into its model pool", but not when. In the feedback discussion, users reported between 2 and 5 October that HydraFusion was routing to GPT-5.6 Terra and GPT-5.4 rather than the newer GPT-6 family, and one wrote: "This is the main reason I've stopped using HydraFusion for now." That is anecdote, but it is the right question to put to any router.

GitHub's own FAQ puts the difference in one line: "Auto picks the optimal model, HydraFusion picks the optimal workflow, possibly using multiple models." It also says "we expect them to come together into a single experience over time." Mario Rodriguez, GitHub's Chief Product Officer, told VentureBeat that GitHub is "evaluating the possibility of converging HydraFusion into Auto". If you write team guidance today, cover both and expect to rewrite it.

GitHub's published table, relative to Claude Opus 5, all models at medium reasoning effort:

The blog's embedded charts carry the absolute figures, which are more useful for cost modelling:

A few observations that the headline does not tell you:

None of this is a criticism of GitHub's transparency, which is better than most model announcements. It is a reason to run your own numbers.

Cost variance becomes a workflow property. With a fixed model, cost per task scales roughly with task size. With Cascade, the same prompt can cost a cheap draft or a cheap draft plus a strong-model escalation depending on whether the quality gate fires. With Critique it is always at least two model calls plus a revision. Budget controls need to move from "which model" to "what is the cap per task", which Copilot CLI supports with --max-ai-credits. Note: CLI 1.0.89 rejects anything below 30 credits.

Latency becomes multi-modal. The documentation says it plainly: "The Single execution pattern behaves much like a request to one model. Cascade and Critique take longer, because they include review passes." Choosing the pattern is cheap. One early hands-on report describes a Cascade run of three to four minutes for a single prompt. That is fine for a task you hand off in autopilot, it is not fine for an interactive loop. GitHub's guidance to start with substantial, well-scoped single-prompt tasks is a latency statement as much as a quality one.

Visibility is better than at launch, but it is not yet operational telemetry. At launch you mostly saw the final answer, and the feedback discussion filled with requests to see what was happening. The CLI now shows the chosen pattern, each planned pass with its status, what the current pass is doing, and the elapsed time, and keeps a summary in the conversation afterwards. VS Code and the app show which models were used when you hover over a response. For bug reports, /collect-debug-logs captures "the execution pattern and the models used for each step".

Headless runs go further than the documentation does. With --output-format json, CLI 1.0.89 emitted session.fusion_resolved, assistant.fusion_phase_started, assistant.fusion_phase_completed, and session.fusion_completed events in my smoke test. Between them they carry the pattern, each phase's model and role, its duration, and its token and credit usage. None of that schema is documented, so build on it the way the harness below does: record what is present and tolerate its absence. If you use the OpenTelemetry tracing approach, nothing in GitHub's documentation says whether HydraFusion legs appear as separate spans, so check your own collector before you rely on it.

Enterprise policy behaviour is documented now, data handling less so. HydraFusion "only uses models that are available in your plan and allowed by your organization's or enterprise's model policies", and it does not appear at all if none qualify. That answers the most common admin question from launch. It does not answer the follow-up a user posted in the feedback discussion on 23 September: whether usage across critic, fallback, and escalation legs is "covered by existing data processing agreements". I found no HydraFusion-specific statement or staff reply on that point. If it matters to you, ask your account team before you enable preview features.

The design below compares HydraFusion against two fixed models on a handful of representative tasks, records wall time, AI credits, the models that actually ran, and the HydraFusion pattern, and applies a pass/fail check per task. It is deliberately modest: four tasks, three model configurations, two repetitions each is 24 runs, which is enough to see a pattern and cheap enough to actually finish.

Pick first-turn, single-prompt, verifiable tasks. Examples that have worked as evaluation prompts in my earlier model comparisons:

Each task needs a deterministic check: a test command that must pass, a file that must exist, or a lint rule that must be satisfied.

The evaluation harness in this article's code folder runs each task against each model configuration in a fresh git worktree. It calls Copilot CLI non-interactively with JSON output and a usage file, captures wall time, runs your check command, and appends a row to a CSV with the credits used, the models that ran, and, for HydraFusion, the execution pattern. The core HydraFusion invocation looks like this:

copilot --experimental ` -p $task. prompt ` --model hydrafusion ` --yolo ` --no-ask-user ` --max-ai-credits $MaxCreditsPerRun ` --usage-output-file $usagePath ` --output-format json ` --log-level none ` --no-color Enter fullscreen mode Exit fullscreen mode Fixed-model runs use the same options without --experimental. What the harness reads, and how far to trust it:

. /code/Invoke-HydraFusionEval.ps1 ` -RepositoryPath 'C:\src\eval-lab' ` -TasksPath './code/tasks.sample.json' ` -ModelIds @( 'hydrafusion', 'gpt-5.6-sol', 'claude-opus-5' ) ` -Repetitions 2 ` -MaxCreditsPerRun 300 ` -OutputCsv './hydrafusion-eval.csv' ` -TrustTaskFile Enter fullscreen mode Exit fullscreen mode Swap the fixed models for your team's current default. GitHub's benchmarks used GPT-5.6 Sol and Claude Opus 5, which keeps your results comparable with theirs, but the newer GPT-6 and Claude 5.5 models are the more useful baseline for a decision today.

The task file is a simple JSON array. A sample is included:

[ { "id": "validate-input", "prompt": "In src/orders.ts, add input validation to createOrder so that quantity must be a positive integer and customerId must be a non-empty string. Throw a ValidationError with a clear message. Add unit tests in tests/orders.test.ts covering both failure cases and one success case.

Run the tests and make sure they pass.", "check": "npm test -- --runTestsByPath tests/orders.test.ts" }, { "id": "fix-failing-test", "prompt": "The test suite currently has one failing test in tests/pricing.test.ts. Find the root cause in the implementation (not the test), fix it, and run the full test suite until it passes. Do not modify or delete tests.", "check": "npm test" }, { "id": "structured-logging", "prompt": "Add structured JSON logging to the CLI entry point in src/cli.ts.

Each log line must include timestamp, level, message, and a correlationId that is generated once per invocation. Keep existing behaviour and make sure the build and tests pass.", "check": "npm run build && npm test" }, { "id": "ci-workflow", "prompt": "Create.github/workflows/test.yml that runs npm ci and npm test on pull requests to main using ubuntu-latest and Node 20. Use a top-level permissions block with contents: read only, and pin actions/checkout and actions/setup-node to specific major versions.", "check": "node -e \" process.exit(require('fs').existsSync('.github/workflows/test.yml')?

0: 1) \" " } ] Enter fullscreen mode Exit fullscreen mode What to look at Load the CSV and compare per model:

Record the model configurations, CLI version, and date. The preview will change under you and a result without provenance is not evidence.

The realistic threat model here is not new, but the routing changes some of the numbers.

The direction is right, and the month since launch has made it more credible, not less. In September I would have listed three blockers: no visibility of the route, undocumented behaviour under enterprise model policies, and CLI-only availability. GitHub has addressed all three to a useful degree. The CLI shows the pattern and each pass, model policies are documented and honoured, and VS Code and the app have it. That is a fast response to feedback for a research preview, and it suggests GitHub is treating runtime orchestration as product direction rather than a demo.

The benchmark story is still more modest than the headline. Winning one of three, matching on the others, and doing it at a third of the cost of Opus 5 is a genuinely good result against the most expensive comparator. Against a sensible mid-tier default the saving is small, and the comparators are now a generation behind. The honest pitch remains "you no longer have to choose", not "67% cheaper".

What still stops me recommending it as a team default: no control over the pool, reports that it lags new models, an undocumented telemetry schema.

I expect HydraFusion to stop being a separate picker entry, because GitHub has said it expects Auto and HydraFusion to "come together into a single experience over time". When that happens, the habits in this article (a fixed baseline, a deterministic check, credits per passing task, and a record of which models actually ran) are what will tell you whether the merged Auto is good for your workload. Build them now, while you can still compare the two side by side.

Choosing a model was never the interesting problem. Constructing the right amount of work for each task is, and HydraFusion is GitHub's first public attempt at solving it inside the product rather than leaving it to you.

Like, share, follow me on: 🐙 GitHub | 🐧 X | 👾 LinkedIn