At its Universe conference on October 28, 2026, GitHub made GitHub Copilot Fusion generally available. Instead of picking a model for every task, developers select “Copilot Fusion” in the model picker plus an effort level. A router does the rest, deciding per request which model works on it and whether a second model should review the result. At the same time, GitHub launched an experimental preview in which Fusion can also route to local models on your own machine.
That sounds like convenience, but it has real consequences for cost, transparency and enterprise policy. Here is how Copilot Fusion works, what GitHub promises and what teams should watch out for.
Key Takeaways
- GitHub Copilot Fusion is a model router and orchestrator, not a model of its own. It has been generally available since October 28.
- Three selectable levels: Fusion Standard, Fusion High and Fusion Max. Depending on the task, one model works alone or several models check each other.
- GitHub says Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, two points behind Claude Code with Opus 5.5 Max, at about half the cost per task.
- Each model used is billed at its standard rate. Through November 30, 2026, paid plans get a 30% discount on model costs.
- Local models (MAI Code 1.1 Flash, Qwen3.8 Flash Next) can be added in an experimental preview. Routing decisions still happen in the cloud.
How GitHub Copilot Fusion works
According to GitHub’s documentation on Copilot Fusion, the system evaluates each request using capability signals for reasoning, code generation, debugging and tool use. Based on that, it picks one of three execution patterns:
- Single: one model completes the task, which behaves like a regular request to a single model.
- Cascade: an efficient model drafts a solution, and a judge inspects it and decides whether to accept it or escalate to a stronger model.
- Critique: one model drafts a response, several other models critique it in parallel, and the original model revises based on the combined feedback.
The pattern is chosen per prompt, so a simple single-model answer can be followed by a heavier critique round in the same session. Fusion also factors in real-time system health and model availability. You can follow each step and the model being used, but only the final response is shown at the end.
The idea is not entirely new. GitHub says Copilot Fusion combines the multi-model orchestration from Project HydraFusion with Copilot’s existing auto model selection. We covered HydraFusion as a research preview in mid-October. Anyone who used HydraFusion or auto will be moved to the matching Fusion level automatically.
The effort levels at a glance
Instead of a model, you choose an effort level. The documentation describes them like this:
- Fusion Standard: balances cost, quality and latency. For everyday work, Fusion picks one model per task.
- Fusion High: more orchestration, for substantial, well-scoped tasks such as a complex bug fix or changes across several files.
- Fusion Max: prioritizes the most capable models for tasks that need the deepest reasoning.
A fourth level, Fusion Fast, cannot be selected and is only used for inline chat in Visual Studio Code. Copilot Fusion is available in Visual Studio Code, the GitHub Copilot app, Copilot CLI and JetBrains IDEs.
What GitHub Copilot Fusion costs
There is no separate fee for Fusion. You pay for each model Fusion uses, at that model’s standard rate. This is the part teams need to understand: with Fusion High and Fusion Max, a task can involve several models and therefore use more AI credits than it would with Fusion Standard. Through November 30, 2026, GitHub gives users on paid plans a 30% discount on model costs when using Fusion.
GitHub argues the opposite on efficiency. According to the launch changelog, Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, two points behind Claude Code with Opus 5.5 Max. GitHub says it got there at about half the average API cost per task, with about half as many tokens and roughly 40% less time per task. Fusion also tries to keep the main conversation on the same model so cached tokens keep paying off.
These are vendor figures based on a single benchmark. Whether the savings show up in your own work depends heavily on your task mix. A sensible test: run a week of typical tasks with Fusion Standard and with your current go-to model, then compare credit usage.
Local models: experimental, and not offline
GitHub also started an experimental preview for local models. Fusion Standard can then choose between supported on-device models and cloud models. On Windows, MAI Code 1.1 Flash can be downloaded directly through the Windows ML provider. In Copilot CLI, routing also works on macOS and Linux with manually configured models, specifically MAI Code 1.1 Flash or Qwen3.8 Flash Next through a local OpenAI-compatible server.
GitHub itself names two caveats. First, local inference does not make your session offline: Fusion still makes routing decisions in the cloud. Second, local models may have different safety protections than Copilot’s cloud models. If you want local models for privacy reasons, keep that in mind.
Controls for administrators
For companies, this matters: Fusion only uses models enabled in enterprise and organization model policies. Administrators can see which models Fusion picks from, disable individual models for Fusion only, and set Fusion at any level as the default model. Models excluded by data residency or FedRAMP policies are not used either. If no eligible models are available, Fusion does not appear in the model picker at all.
One limitation from the docs is worth knowing: if Fusion discards a draft, changes that draft already made in your workspace are not undone automatically. Review changes before you commit. Fusion also does not start subagents.
Context: model choice becomes a platform feature
Copilot Fusion fits the numbers GitHub published in its Octoverse report the same week. In September, 61% of Copilot users who picked a model themselves used more than one. Paid plans saw 47 distinct models in use in September, and no single model carried more than 25% of requests. GitHub also says more than 40% of pull requests now start with an agent’s first draft, up from 17% in March.
As the number of models keeps growing, manual selection becomes a burden. A router takes that decision off your hands but also makes it less visible. If you want to understand why a result turned out the way it did, you need to check which models were involved. Fusion lets you do that, but it takes attention. For a broader look at how agent tools differ, see our AI agent tools comparison.
Bottom line
GitHub Copilot Fusion is a pragmatic answer to a real problem: too many models, too many decisions. For everyday tasks, Fusion Standard will likely save many developers some effort. The efficiency claims rest on one benchmark and GitHub’s own figures, though, and the higher levels can cost more credits than expected. Teams should monitor usage in the first weeks, set policies deliberately and review changes before committing. The local option is interesting but explicitly experimental.
