GitHub Copilot makes Fusion generally available with automatic model routing on all plans
GitHub has made Copilot Fusion generally available, turning the experimental multi-model orchestration it had been testing under the name HydraFusion into a standard option in the Copilot model picker. Announced on October 28, 2026 in the GitHub changelog and in the company's GitHub Universe 2026 keynote post, Fusion changes the basic question developers answer before every Copilot request. Instead of choosing a specific model, the user chooses Copilot Fusion and an effort level, and Copilot decides which model or combination of models handles the task, how they are chained together and how much reasoning each step receives.
According to GitHub, Fusion is available on all Copilot plans and works in Visual Studio Code, the GitHub Copilot app, GitHub Copilot CLI and JetBrains IDEs, with support for other clients described as coming soon. It combines two strands of earlier work: the multi-model orchestration developed in the Project HydraFusion research preview and the fine-tuned model selection that powered Copilot's auto model selection. In JetBrains IDEs, GitHub says Fusion replaces the existing Auto model option and is rolling out gradually to all users.
The headline performance claim is that Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, which GitHub describes as within two points of Claude Code running Opus 5.5 Max. In the same comparison, GitHub says Fusion Max used about half the average API cost per task, about half as many tokens and roughly 40% less time per task. These are figures published by GitHub about its own product; the company has not released a per-task breakdown that would allow the comparison to be reproduced independently.
··········
HOW COPILOT FUSION ROUTES AND ORCHESTRATES MODELS.
GitHub's documentation describes Fusion as a runtime model router and orchestrator rather than a model. For each request it evaluates what the task needs across reasoning, code generation, debugging and tool use, and then selects three things: the models to use, the execution pattern that links them, and the reasoning effort applied. The router also takes real-time system health and model availability into account, so the same prompt can be served differently depending on conditions at the moment it is sent.
The execution patterns are the most significant technical change compared with auto model selection, which picked a single model per request. Fusion can still do that, but it can also run a draft-and-escalate flow or a draft-and-critique flow inside a single turn.
........
Pattern | How it works | Typical trade-off |
Single | One model completes the task directly | Lowest latency and cost |
Cascade | An efficient model drafts; a judge accepts the draft or escalates to a stronger model | Saves cost when the cheap draft is good enough |
Critique | One model drafts, several models critique it in parallel, the drafter revises | Extra calls for harder tasks |
........
In the Critique pattern, the documentation says several models review the draft in parallel and the drafting model revises it using their combined feedback. The earlier HydraFusion research preview used a single read-only critic from a different model family and one revision pass, so the generally available version widens the review stage. GitHub notes that Cascade and Critique take longer than Single because they make additional model calls, and that only the final response is shown to the user; intermediate drafts are not displayed.
Fusion also tries to keep the main conversation on one model where it can. The reason is cost: GitHub's guidance on optimizing AI usage says cached tokens are typically billed at 10% of the normal input price, and that a different model cannot reuse another model's cache. A router that switched models freely on every turn would keep rebuilding the cache from scratch, which would erode the savings that routing is supposed to deliver.
··········
FUSION STANDARD, HIGH AND MAX EFFORT LEVELS.
Users choose an effort level when they select Fusion in the model picker. The level does not name a model; it tells the router how much capability, and therefore how much cost and latency, the task is worth.
........
Effort level | Intended use, per GitHub | Selectable by users |
Fusion Standard | Everyday coding; usually one model per task | Yes |
Fusion High | Substantial, well-scoped tasks such as complex bugs or multi-file changes | Yes |
Fusion Max | Tasks that need the deepest reasoning and most thorough analysis | Yes |
Fusion Fast | Visual Studio Code inline chat only | No |
........
The documentation states that High and Max can use more models per task and may therefore consume more AI credits than Standard. The practical guidance that follows from GitHub's own usage advice is to start at Standard and move up only when a task justifies it, in the same way the company recommends using the regular reasoning level by default and raising it for harder problems.
Developers who had joined the research preview do not need to reconfigure anything. GitHub says participants who had enabled auto, HydraFusion or HydraFusion Max are moved automatically to the corresponding Fusion effort levels.
··········
WHAT CHANGES FOR COPILOT USERS AND WHAT IT COSTS.
There is no separate charge for using Fusion. GitHub bills each model that Fusion calls at that model's standard rate, which means the cost of a request depends on what the router decides to do with it. A Single-pattern answer at Standard effort costs roughly what the chosen model would cost on its own, while a Critique run at Max effort can involve several models and several calls for one prompt.
For a limited time, users on paid Copilot plans receive a 30% discount on model costs when they use Fusion. GitHub's JetBrains release notes describe the same promotion as a 30% discount for the first 30 days, and the Fusion documentation refers to a discount on paid plans running through November 30, 2026. For comparison, GitHub's documentation describes a 10% discount on model costs for paid plans using auto model selection, the option Fusion is replacing in JetBrains IDEs. Users who want to see where their credits go can check the Copilot usage dashboard, which GitHub says breaks down consumption by feature and model.
Getting started requires updating the client and then selecting Copilot Fusion in the model picker with the desired effort level. Availability as of the announcement is summarized below.
........
Client | Fusion status | Notes |
Visual Studio Code | Generally available | Fusion Fast is used for inline chat |
GitHub Copilot app | Generally available | Local model routing is experimental |
GitHub Copilot CLI | Generally available | Local routing on Windows, macOS and Linux |
JetBrains IDEs | Rolling out to all users | Replaces the Auto option |
Other clients | Not yet | Described as coming soon |
........
There are two limitations developers should keep in mind. Fusion runs separately from subagents and does not start them, so workflows built around subagents are not orchestrated by the router. And if a draft that Fusion later discards has already modified files in the workspace, those changes are not undone automatically. GitHub's advice is to review changes before committing, which matters most with the Cascade and Critique patterns, where more than one model may touch the code during a single turn. GitHub also warns that the execution patterns and the model pool may change over time, so the behavior of a given effort level is not fixed.
··········
ADMIN POLICIES AND MODEL CONTROLS FOR BUSINESS AND ENTERPRISE.
For organizations, the most important detail is that Fusion only routes to models that the user is already allowed to use. The documentation lists the exclusions: models not included in the user's plan, models excluded by administrator policy, models restricted by data-residency or FedRAMP policies, and models restricted by evaluation-model policies. If none of Fusion's candidate models is available to a user, Fusion does not appear in the model picker at all.
Enterprise administrators get specific controls on top of that. They can see which models Fusion picks from, set each model's effective policy state, and disable a model for Fusion without disabling it for everyone else in the enterprise. Administrators can also make Fusion, at any effort level, the default model for Copilot users through Enterprise managed settings. That combination allows a company to keep an expensive frontier model available for developers who choose it explicitly while keeping it out of automatic routing, or the reverse.
Fusion arrives alongside a broader change to how large companies buy Copilot. In a separate October 28 changelog entry, GitHub said enterprises working with a GitHub or Microsoft account team can now get Copilot included with GitHub Enterprise for every licensed user, with AI usage metered from the first request against an enterprise budget rather than drawn from monthly per-seat AI credits. Users without a GitHub Enterprise license can get the same access through Copilot Standalone at $10 per user per month. Code completion and next edit suggestions keep working when the budget is exhausted, while Copilot Chat, Copilot code review and Copilot in the cloud require available budget. This model is not yet open to self-serve customers, and existing Copilot Business and Copilot Enterprise plans remain on sale. Under usage-based billing of this kind, the choice of effort level in Fusion translates directly into enterprise spend, which makes the per-model policy controls more than an administrative detail.
··········
LOCAL MODELS IN COPILOT FUSION.
GitHub also announced an experimental, opt-in preview that lets Fusion route some work to models running on the developer's own machine. Two local models are named: MAI Code 1.1 Flash, which can be downloaded and set up through the Windows ML provider on supported Windows devices, and Qwen3.8 Flash Next, which users bring themselves through a local OpenAI-compatible server. Local routing is available only at the Standard effort level, where Copilot chooses between eligible local and cloud models.
Support differs by client. Copilot CLI supports local routing for managed and bring-your-own models on Windows, macOS and Linux after experimental mode is enabled with the `--experimental` flag or the `/experimental on` command. The Copilot app supports bring-your-own local model selection, but intelligent routing there works only with managed Windows ML models and requires the "Local model auto routing" setting. In Visual Studio Code, the feature is turned on with the `chat.copilot.localModel.enabled` setting. Adding a model through bring-your-own-key does not by itself make it eligible for Fusion.
GitHub is explicit about what local inference does not do. The session does not become offline, because Fusion still makes its routing decisions in the cloud, and local models may have different safety protections from the cloud models Copilot normally uses. For teams considering local routing for privacy reasons, that distinction is the one to check before enabling it.
··········
FUSION IN THE CONTEXT OF GITHUB UNIVERSE 2026.
Fusion was one of several Copilot announcements at GitHub Universe 2026, and the others show the same direction toward agents that run longer and use more than one model. Copilot code review gained a Max effort level in public preview that runs several independent review agents across models from different providers and then reconciles their findings into one review through an aggregation agent. GitHub positions it for higher-risk changes such as authentication logic or shared libraries and says it takes longer and uses more AI credits than the Lite and Balanced levels. In the keynote post, GitHub said code review Max posted the highest F1 score on ReviewBench for high-severity issues, without publishing the score itself. Copilot approvals, which let Copilot approve a pull request in a way that counts toward required approvals, are now generally available but switched off by default.
Other Universe releases included Copilot projects in public preview in the GitHub Copilot app for agent work spanning multiple repositories, session continuity across the app, Visual Studio Code, the CLI and the web, and Copilot automations that can propose improvements to themselves for human approval. Earlier this month, GitHub also made assisted permissions generally available in Copilot, part of the same effort to give agents more autonomy under explicit controls. Copilot's model catalog continues to expand in parallel, most recently with OpenAI's GPT-6.1 Terra, which widens the pool of models a router like Fusion can draw from where policies allow.
··········
WHAT IS ESTABLISHED AND WHAT REMAINS UNCLEAR.
The verified facts are clear enough to act on. Copilot Fusion is generally available on all Copilot plans in Visual Studio Code, the Copilot app, Copilot CLI and JetBrains IDEs; it offers Standard, High and Max effort levels; it chooses among Single, Cascade and Critique execution patterns; it bills each model it uses at the standard rate with no separate Fusion fee; and paid plans get a temporary 30% discount on model costs. Administrators keep control over which models it can reach, and local model routing exists only as an experimental preview at the Standard level.
Several points remain open. GitHub has not published which models make up Fusion's pool, so developers cannot know in advance which provider will handle a given request beyond what their policies allow. The benchmark claim that Fusion Max came within two points of Claude Code with Opus 5.5 Max at about half the cost comes from GitHub, and no independent reproduction is available yet. The per-plan availability of each effort level is not fully documented, and the exact terms of the discount are described slightly differently across GitHub's own release notes. The cost of a Fusion request is also inherently variable, since the router, not the user, decides how many model calls a task receives. Teams moving to usage-based enterprise billing will want to watch the usage dashboard during the first weeks before setting Fusion High or Max as a default.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
