GitHub Copilot Fusion: How It Works and When to Use It

Verified against GitHub's live documentation and announcements on 29 October 2026. This is a documentation-based assessment, not a hands-on benchmark.

What GitHub Copilot Fusion Changes

GitHub Copilot Fusion delegates model choice and, when useful, coordination between models. Think of a technical lead deciding whether a change needs a quick implementation, a reviewer, or an escalation. You still define the job and decide whether the resulting code is acceptable.

GitHub made Fusion generally available on October 28, 2026, combining Project HydraFusion's orchestration with Auto model selection. Existing Auto, HydraFusion and HydraFusion Max selections transition to corresponding Fusion effort levels. That makes the October research preview the predecessor, rather than a separate product you need alongside Fusion. GitHub's Fusion announcement.

The execution pattern is the arrangement of work:

• Single: a model handles the task directly.
• Cascade: a draft goes through a judge, which accepts it or escalates the work.
• Critique: a draft receives independent criticism before its author revises it.

These patterns came from GitHub's HydraFusion research. Current Fusion documentation describes parallel critics whose feedback is combined. It does not mean every prompt runs every pattern. Fusion behavior.

For example, correcting a label and investigating a race condition should not automatically receive identical treatment. Fusion makes that allocation inside the session. The broader model router explainer explains the underlying idea: match the work to suitable capability, then measure whether the selection helped.

Where It Runs and How to Turn It On

Use Fusion in the Copilot app, Visual Studio Code, Copilot CLI or JetBrains IDEs. GitHub lists those surfaces and availability across Copilot plans. That does not establish identical effort-level access for every account: models remain constrained by your plan and policies. Current availability.

Update your client before following these instructions. The old HydraFusion preview switches are not the current Fusion setup recipe.

GitHub Copilot App

Click the model name below the prompt box, turn on Copilot Fusion, and choose an offered effort level. To return to a named model, turn the switch off and select that model. The app remembers your choice for future sessions. App model selection.

Visual Studio Code

In Settings, verify that chat.copilot.dynamicAutoTiers.enabled is enabled. Start a new chat using the Copilot harness, the runtime that connects the model to the agent's tools. Select Copilot Fusion in the model picker and choose an available tier. The setting does not grant an entitlement: the picker can continue to show Auto when no eligible Fusion tier is offered. VS Code setup.

GitHub Copilot CLI

In an interactive session, enter /model, choose Fusion and its effort level, then confirm. For a bounded first look, GitHub documents the following command structure; this example asks for analysis without edits:

copilot --model fusion --fusion-tier standard -p "Explain how this repository runs its tests. Do not edit files."

That is the current Fusion option, without the old HydraFusion experimental flag. CLI model selection.

Which Models Fusion Can Use

The named Claude/GPT pool is a dated snapshot, not a permanent routing contract. GitHub's October 14, 2026 HydraFusion update explicitly listed:

• Anthropic's Claude Opus 5.5.
• OpenAI's GPT-6 Astra.
• OpenAI's GPT-6.1 Sol.
• OpenAI's GPT-6 Luna.

That update also introduced HydraFusion Max and more deliberate reasoning effort for drafting and review. These are the verified names in the preview announcement. October model-pool update.

The current Fusion overview does not publish a fixed, exhaustive cloud-model roster. It says the pool changes and lets you inspect the models used by hovering over the effort label below a response. Do not treat the complete Copilot model catalog as a promise that Fusion will route to every entry. Current model-pool behavior.

For an engineering lead, the actionable list is the allowed pool in your own account. Enterprise owners can open AI controls → Copilot → Models → Configure Copilot Fusion models. Those choices still sit inside the user's other model policies. Enterprise model controls.

There is a separate local-routing preview. It supports specific setups using MAI Code 1.1 Flash or Qwen3.8 Flash Next with Standard. Adding an arbitrary local model does not make it eligible, and local inference does not make Fusion offline: routing still happens in the cloud. Local-model boundaries.

Choose Standard First, Then Raise the Effort

Start with Standard; give additional review a job to do before selecting High or Max. GitHub describes Standard as everyday coding, High as challenging tasks and deeper reasoning, and Max as the most demanding work. Effort-level definitions.

The following task choices are editorial recommendations, not measured performance claims:

A vague request to improve an entire application is a poor Max trial. You cannot tell whether extra reasoning helped when you never defined success. Narrow it to an observable problem, such as preserving retry behavior while removing a duplicated request path.

Fusion Max is an effort choice, not the name of a required subscription. Fusion Fast also exists, but is not user-selectable and is limited to VS Code inline chat. Effort options.

How Fusion Spends AI Credits

The bill follows the work performed by the selected models. Input, output and cached tokens are priced by model, with cache-write charges where applicable, then converted into AI credits. There is no published fixed credit charge for a Fusion task. GitHub's billing mechanics.

Fusion has no separate orchestration fee. Paid Copilot plans currently receive a 30% discount on Fusion model costs through November 30, 2026. Fusion billing. The plan ladder and allowances belong in the GitHub Copilot pricing guide.

A drafting pass, critique and revision each contribute usage. Reasoning effort, context size, tool activity and caching also affect consumption. Consequently, a multi-pass run can consume more credits than a single-model request even when routing is working as designed. VS Code's explanation of AI credit consumption.

For your trial, count failed attempts and corrective prompts too. A cheap draft that needs repeated repair can lose to a more expensive run that produces an acceptable change. Conversely, paying for a critique of a straightforward rename may buy nothing useful. Compare the completed work, not the cheapest individual response.

What GitHub's Benchmark Does and Does Not Show

GitHub reports a promising result; it does not establish your repository's savings. In its Universe announcement, GitHub says:

The named evaluation is the Artificial Analysis Coding Agent Index. This is GitHub's reported benchmark claim, not an independent test performed for this article. GitHub Universe announcement.

The detailed changelog names the comparison as Claude Code with Opus 5.5 Max and describes the cost metric as average API cost per task. That is more specific than saying Fusion halves a Copilot invoice. GitHub's benchmark context.

The useful inference is that orchestration may make strong results more efficient than always selecting a heavyweight configuration. The unsupported leap is that every bug fix will be faster or cheaper. Your task mix, acceptance criteria and repair work decide whether the result transfers. The temporary billing promotion and the benchmark comparison are also different claims; do not combine them into a promised saving.

What It Means for Developers, Leads and Buyers

Developers gain a model-choice shortcut. If you repeatedly interrupt work to decide which model should attempt the next task, Fusion is worth a bounded trial. Keep the issue description, expected behavior and review standard explicit. Delegating selection should reduce a distraction, not make the task less precise.

Engineering leads need an effort policy and an acceptance record. A useful starting rule is Standard for routine work, High for scoped changes needing review, and Max by deliberate choice. Record why an escalation helped. Otherwise, choosing the highest label can become a habit without evidence that it improves shipped work.

Buyers comparing Copilot with Claude Code or Cursor should test the workflow they would adopt. A benchmark is a reason to evaluate an option, not a reason to migrate an organization. Evaluate review burden, repository fit and completed outcomes alongside credits. Use the Claude Code vs GitHub Copilot comparison for the broader choice; Fusion changes one part of that decision.

What Is Overhyped, and Who Should Leave It Off

More model involvement does not remove your responsibility for the diff. GitHub documents a particularly consequential limit: discarded drafts can leave file edits behind. Fusion also has no combined context window of its own and does not start subagents. Fusion limitations.

Leave Fusion off when you need a specific model for a controlled comparison, a reproducible investigation or an explicitly approved workflow. Fix the model choice so routing does not become another variable. This does not make a language model deterministic; it simply removes one source of variation.

If a familiar named-model setup already handles your bounded task with little correction, you are unaffected until a trial shows a practical gain. There is no obligation to switch.

Also wait if your requirement is an offline workflow, or if you cannot define and review an acceptable change. For tiny routine requests, the better adjustment may be leaving orchestration-heavy effort levels unused while retaining Standard. “Leave Max off” and “leave Fusion off” are different decisions.

GitHub Copilot Fusion Tutorial: Try One Repo This Week

Keep the trial small enough that you can inspect every result. Choose a repository you know, then compare Fusion with the model configuration you already use.

Your move this week: assign a developer and reviewer to that repository, agree on the acceptance checks, and decide the default only after looking at the resulting changes. A readable decision record is more useful than a screenshot of the fastest response.

Subscribe to the newsletter for practical guides to choosing and operating AI development tools.