GitHub Copilot Fusion is GitHub’s multi-model orchestration system, made generally available on October 28, 2026, at GitHub Universe. Fusion does not answer every prompt with one model. It routes each coding task across several models and decides how they work together. GitHub built it by merging its Project HydraFusion research preview with Copilot’s automatic model selection. For developers choosing a model in Copilot’s picker, Fusion changes what that choice actually means.
What Is GitHub Copilot Fusion
Copilot Fusion is not a single model. It is a runtime orchestration engine that picks and coordinates models for each request. GitHub Chief Product Officer Mario Rodriguez described it this way: “It’s not a model. It’s an orchestration engine at runtime.”
Developers select one of three effort levels instead of a specific model. Standard covers everyday coding with versatile models. High handles harder problems that need deeper reasoning. Max brings in the most capable models for complex, multi-step work. Artificial Analysis identified the model pool behind Fusion. It includes Claude Opus 5.5, Claude Sonnet 5.5, GPT-6 Astra, and GPT-6 Sol. Which models actually run depends on the task and on organizational policy.
Fusion reflects a broader shift toward generative AI reshaping software development. That shift moves tools from single-model assistants to systems that manage multiple models on a developer’s behalf.
How GitHub Copilot Fusion Works
Each request runs through one of three execution patterns. In Single mode, one model solves the task directly, with no handoff. Cascade starts with a cheaper, efficient model, then a quality check decides whether to escalate to a stronger one. In Critique, one model drafts an answer first. A second model reviews it, then the original model revises based on that feedback.
GitHub designed these patterns around a simple goal: automatically match task difficulty to model cost. A trivial autocomplete does not need the same model as a multi-file refactor. Fusion decides that case by case instead of leaving the choice entirely to the developer.
Enterprise and organization admins keep control over the process. Admins can see which models are eligible and disable specific ones for Fusion only. They can also set a default effort level for their users. Developers who ran the auto, HydraFusion, or HydraFusion Max preview move automatically to the matching Fusion effort level. Nobody has to reconfigure anything after the GA switch.
GitHub’s own research preview post for Project HydraFusion describes the same core patterns. It also covers safeguards like fail-safe application. That feature blocks a patch from applying if validation fails or a task gets canceled partway through.
GitHub Copilot Fusion Pricing and Availability
Fusion is available now on every Copilot plan. That includes Visual Studio Code, the GitHub Copilot app, GitHub Copilot CLI, and JetBrains IDEs. GitHub says more editor and client support is coming. Billing follows each underlying model’s standard rate, charged per model actually called during a task.
Paid Copilot subscribers get a limited-time 30% discount on model costs specifically when using Fusion. That discount will not last forever. Teams evaluating cost at scale should also model usage against the standard per-model rate.
GitHub also loosened enterprise licensing the same day. Eligible GitHub Enterprise Cloud customers can now use Copilot features without buying a separate per-seat subscription. Instead, they draw on an enterprise AI usage budget. Code completion and next-edit suggestions remain available without a budget; Copilot Chat, code review, and cloud agent sessions require one. That change sits alongside other recent shifts DevX has tracked in enterprise development tooling and governance. Usage-based billing keeps replacing flat per-seat pricing there.
GitHub Copilot Fusion Benchmark Performance
Artificial Analysis measured Fusion against rival configurations using its Coding Agent Index. Fusion Max scored 60, about two points behind Claude Code running Opus 5.5 Max at roughly 62. In cost terms, however, Fusion Max averaged $5.59 per task in API costs. The Opus 5.5 Max configuration cost $11.42, roughly 51% more, for a small quality gain.
Token usage told a similar story. Fusion used about 7.2 million tokens per task. That is close to half of what the Opus 5.5 Claude Code setup consumed. On Terminal-Bench 4.0, Fusion scored 71, the highest result among the systems Artificial Analysis compared. FrontierCode put Fusion at 51, trailing Claude Code’s 56 and Devin Fusion’s 54.
GitHub also cited its own internal numbers, which have not been independently verified. The company reported Fusion completing tasks about 40% faster than the Opus 5.5 Claude Code configuration. On GitHub’s DeepSWE tests, Fusion’s High and Max levels scored up to 8.7 completion points higher than comparable setups. GitHub also estimated a cost cut of up to 77% for those same results. Microsoft CEO Satya Nadella cited that 77% figure publicly. It comes from GitHub’s own evaluation, not from Artificial Analysis’s benchmark average.
Common Mistakes and Tradeoffs to Watch
Teams often assume Fusion always picks the cheapest viable model. In practice, Cascade and Critique can call more than one model per task. A single request can cost more than a plain Single-mode call to one model. Watching total tokens per task, not just the headline discount, gives a clearer cost picture.
A second mistake is ignoring governance settings after rollout. Admins can restrict which models Fusion uses, but that control only helps if someone actually reviews it. Skipping that review leaves a team exposed to whichever models a vendor enables by default.
Finally, don’t treat GitHub’s self-reported numbers as equivalent to Artificial Analysis’s independent benchmarks. The 77% cost reduction Nadella cited came from GitHub’s own DeepSWE testing, not a third-party measurement. Independent numbers and vendor claims deserve separate scrutiny, especially before committing a team’s workflow to one routing system.
Key Takeaways
- GitHub made Copilot Fusion generally available on October 28, 2026, at GitHub Universe.
- Fusion routes tasks across models like Claude Opus 5.5, Claude Sonnet 5.5, GPT-6 Astra, and GPT-6 Sol. It uses Single, Cascade, or Critique patterns to split the work.
- Paid Copilot users get a limited-time 30% discount on model costs when using Fusion.
- Artificial Analysis measured Fusion Max near Claude Code’s Opus 5.5 Max quality at roughly half the per-task cost.
- Admins control which models Fusion can use through enterprise and organization policies.
Frequently Asked Questions About GitHub Copilot Fusion
What Is GitHub Copilot Fusion?
It is GitHub’s multi-model orchestration system for Copilot. Instead of picking one model, Fusion automatically routes each coding task across several models and execution patterns.
Which Models Does Copilot Fusion Use?
Artificial Analysis identified Claude Opus 5.5, Claude Sonnet 5.5, GPT-6 Astra, and GPT-6 Sol in Fusion’s pool. The exact models used vary by task and organizational policy.
How Much Does GitHub Copilot Fusion Cost?
Fusion bills per underlying model at that model’s standard rate. Paid Copilot subscribers currently get a limited-time 30% discount on those model costs.
Is Copilot Fusion Available in My Editor?
Fusion works today in Visual Studio Code, the GitHub Copilot app, GitHub Copilot CLI, and JetBrains IDEs. GitHub plans to add support for more clients.
Does Copilot Fusion Replace Project HydraFusion?
Yes. Fusion combines HydraFusion’s multi-model orchestration research with Copilot’s existing automatic model selection. Preview users move to matching Fusion effort levels automatically.
Is Copilot Fusion Actually Better Than Claude Code?
It depends on the measure. Artificial Analysis scored it slightly behind Claude Code’s Opus 5.5 Max configuration on quality. Fusion ran at roughly half the per-task cost, though.
Final Thoughts
Copilot Fusion will not settle the debate over which model writes the best code. It does change the question teams should ask. Developers no longer need to pick one model and live with its tradeoffs. Instead, they pick an effort level and let routing handle the rest. Check your organization’s model policies before adopting it broadly. Compare GitHub’s own benchmarks against Artificial Analysis’s independent numbers side by side.
Photo by Rubaitul Azad: Unsplash
