GitHub Copilot Fusion is now generally available on every Copilot plan. Instead of picking one model, developers pick an effort level and Copilot routes each prompt across one or more models. Before an enterprise makes it the default, check which models your policies allow, how per-model billing adds up, and which teams need a fixed model.
What GitHub released
Copilot Fusion was announced by GitHub on 28 October 2026 in the GitHub changelog. It is a new entry in the Copilot model picker. It combines the multi-model orchestration from the Project HydraFusion research preview with the model selection behind Copilot auto mode.
It works in Visual Studio Code, the GitHub Copilot app, GitHub Copilot CLI and JetBrains IDEs, with other clients listed as coming later. To use it, a developer updates the client, opens the model picker, selects Copilot Fusion and chooses an effort level.
How Fusion routes a prompt
Fusion has three effort levels. Standard uses versatile models for everyday coding, High uses stronger models for harder tasks, and Max uses the top tier of models for demanding work. For each prompt, Fusion decides which models take part and how they work together, using one of three patterns:
- Single: one model completes the task.
- Cascade: an efficient model drafts a response, and a quality check either accepts it or passes the task to a stronger model.
- Critique: one model drafts, a second model reviews, and the first model revises.
The developer no longer switches models in the middle of a task. GitHub reports that Fusion Max came close to Claude Code with Opus 5.5 Max on the Artificial Analysis Coding Agent Index at a lower average cost per task. That is GitHub's own measurement, so treat it as a reason to run your own trial rather than as a result for your codebase.
Developers who had turned on auto, HydraFusion or HydraFusion Max during the research preview are moved to the matching Fusion effort level automatically.
How billing works
There is no single Fusion price. You are billed for every model Fusion uses, at that model's standard rate. A Critique run that calls two models costs what both calls cost, so the bill depends on which pattern Fusion chose, and that choice is made per prompt. Paid plans get a time-limited discount on model costs used through Fusion, with no end date given.
The announcement does not say how Fusion usage counts against premium requests. Until GitHub documents that, compare a pilot group's usage report with a group on a fixed model before you roll it out widely.
The admin controls that matter
Fusion only routes to models that your enterprise and organisation model policies already allow. That is the main governance lever:
- Enterprise admins can see which models Fusion is able to choose from.
- Each model's effective policy can be set separately, and a model can be turned off for Fusion alone without removing it from the picker for everyone.
- Admins can set Fusion, at any effort level, as the default model for Copilot users through Enterprise managed settings.
GitHub also released an opt-in experimental preview of local model routing in Fusion. With Standard selected, Copilot can choose between supported on-device models and cloud models. Routing decisions are still made in the cloud, a session using a local model is not offline, and GitHub notes that local models may have different safety protections from cloud models. Treat this as a trial, not a data-residency control.
What this means for your engineering teams
Start with your model policy, not the picker. Fusion inherits your allowed list. If a model is allowed today only because nobody had picked it, Fusion may now pick it. Review the list, and use the Fusion-only switch for any model you want available by name but not chosen automatically.
Pick the default effort level by cost tolerance. Standard as an enterprise default keeps spend close to everyday models while still escalating when a draft fails the quality check. Leave High and Max as choices a developer makes for a hard task, not the default for every prompt.
Keep a fixed model where results must be repeatable. Fusion can answer the same prompt with a different model or pattern from one day to the next. Teams that compare outputs over time, such as those running prompt regression checks, scripted Copilot CLI jobs or evaluations of agent behaviour, should pin a model so a change in results can be traced to their own change.
Measure before you switch everyone. Run a short pilot: one team on Fusion Standard, one on your current default, same kind of work. Compare usage reports, accepted suggestions and review comments. If you already track AI agent running costs, add Fusion as its own line so per-model billing does not hide inside a single total.
When not to switch yet: if your finance team needs a predictable per-seat cost and premium request accounting for Fusion is still unclear to you, or if your developers mainly use a client outside the four supported today. A fixed default stays a valid choice.
For earlier Copilot model changes, see our notes on Copilot default models in JetBrains and local model discovery in Copilot CLI.
Frequently asked questions
What is GitHub Copilot Fusion?
Copilot Fusion is a model picker option, generally available since 28 October 2026, that routes each prompt across one or more models instead of a single fixed one. Developers choose an effort level, Standard, High or Max, and Fusion decides whether one model answers, a cheaper draft is escalated to a stronger model, or one model drafts while another reviews it before the final answer.
How is Copilot Fusion billed?
GitHub bills each model Fusion uses at that model's standard rate, so one prompt can cost more than one model call when Fusion drafts and reviews with two models. Paid plans get a time-limited discount on model costs used through Fusion. The announcement does not explain how Fusion counts against premium requests, so compare a pilot group's usage report before rolling it out across the organisation.
Can administrators control which models Fusion uses?
Yes. Fusion only uses models allowed by your enterprise and organisation model policies. Enterprise admins can see the models Fusion can choose from, set each model's policy separately, and disable a model for Fusion alone while keeping it in the picker for direct use. Admins can also make Fusion, at a chosen effort level, the default model through Enterprise managed settings.
Should every developer use Copilot Fusion by default?
Not always. Fusion Standard is a sensible default for everyday coding once you have reviewed your allowed models and checked a pilot's costs. Keep a fixed model for scripted jobs, prompt regression checks and agent evaluations, where results need to be repeatable. Leave High and Max as choices developers make for harder tasks rather than the default for every prompt.
Does Copilot Fusion support local models?
Partly. Local model routing in Fusion is an opt-in experimental preview in Copilot CLI, the Copilot app and Visual Studio Code. With Standard selected, Copilot can choose between supported on-device models and cloud models. Routing decisions are still made in the cloud, so the session is not offline, and GitHub notes that local models may have different safety protections from cloud models.
