Copilot Fusion as the default: set fusionTier first
GitHub made Copilot Fusion GA on Oct. 28. Admins can now make it the default model and set its tier, which can change how many models a task uses and what it costs.
Sean McLellan
Lead Architect & Founder

GitHub made Copilot Fusion generally available on October 28, 2026. Fusion is a router: instead of picking a model, a developer picks an effort level (Standard, High or Max) and Copilot chooses the models and the workflow for each prompt. Enterprise admins can now make Fusion the default model and set its default tier with the model and fusionTier keys in managed settings, so the first decision is which tier new sessions start on.
The tier affects cost. GitHub bills each model Fusion calls at that model's standard rate, and its docs say Fusion High and Fusion Max "can use more than one model for a task," so a task may use more AI credits than it would on Fusion Standard. GitHub also says users on paid Copilot plans get a 30% discount on model costs when using Fusion through November 30, 2026, so a cost baseline taken before then will not reflect full rates. BaristaLabs recommendation: default to Standard, let teams opt up, and recompute any baseline at full rates.
What is GitHub Copilot Fusion?
Copilot Fusion is a model router and orchestrator. GitHub's Fusion changelog says it combines the multi-model orchestration from Project HydraFusion with Copilot auto model selection. It is available on all Copilot plans in VS Code, the GitHub Copilot app, Copilot CLI and JetBrains IDEs, though a managed Fusion default does not reach JetBrains (see below).
Research-preview users carry over automatically. GitHub says earlier auto, HydraFusion and HydraFusion Max selections move to the matching Fusion effort levels, so a team that tested HydraFusion (covered in how HydraFusion changed the unit of cost from model to task) should not need to switch by hand.
How Copilot Fusion chooses models for each prompt
For each prompt, Fusion picks one of three execution patterns, according to the Copilot Fusion documentation:
Scroll sideways to see all 3 columns.
| Pattern | What runs | Added model calls |
|---|---|---|
| Single | One model completes the task | None |
| Cascade | An efficient model drafts; a judge accepts the draft or escalates to a stronger model | A judge call, plus a stronger model if the draft is escalated |
| Critique | One model drafts, several models critique it in parallel, and the first model revises | Parallel critique calls, then a revision |
The pattern can change from one prompt to the next in the same session. GitHub says Fusion "only adds model calls when a task warrants them," and that cascade and critique take longer because they include review calls. After a response, hovering over the effort level name lists the models that were used.
Two details in GitHub's docs matter for anyone setting policy. Fusion has no context window of its own; the value shown is a conservative one based on the smallest limits among the models it uses. And if Fusion discards a draft, file edits that draft already made in the workspace are not undone automatically, so changes still need review before commit.

What do the Fusion effort levels cost?
Fusion has no separate charge. Each model it calls is billed at its standard rate, as the Fusion billing section explains, and the effort level affects how many models a task can use:
- Fusion Standard balances cost, quality and latency, and selects one model for each task. GitHub lists it for everyday work.
- Fusion High is "balanced orchestration with moderate token savings," meant for substantial, well-scoped tasks such as a complex bug fix or a multi-file change "when additional model calls may be worth the extra time and AI credits."
- Fusion Max targets "frontier capability while still considering token efficiency," for tasks that need the deepest reasoning.
GitHub's headline claim is about Max: in the Artificial Analysis Coding Agent Index, Fusion Max scored 60, within two points of Claude Code with Opus 5.5 Max, at about half the average API cost per task and about 40% less time per task. That is a vendor-reported benchmark result that BaristaLabs has not reproduced. It compares Max against another agent, not Max against Standard on a team's own work.
How admins set Copilot Fusion as the default
Two controls decide what Fusion can do in an enterprise.
The model list. Fusion only routes to models enabled by enterprise and organization model policies. Under AI controls > Copilot > Configure Copilot Fusion models, enterprise administrators can also turn a model off for Fusion without turning it off for everyone, per GitHub's model availability guide. GitHub's docs say Fusion also skips models not in the plan, models excluded by data-resident or FedRAMP policies, and models blocked by evaluation-model policies. If none of the models Fusion uses are available to a user, Fusion does not appear in the model picker. BaristaLabs recommendation: if model access is already managed through enterprise teams (see whether to switch Copilot model access to enterprise teams), check that the team grants and the Fusion list agree.
The default. In enterprise managed settings, "model": "fusion" makes Fusion the default for new conversations, and fusionTier sets its effort level. The managed settings reference lists the accepted values as "standard", "high", "max" and "unmanaged". Any plain-string value other than "unmanaged" locks the tier against user and repository overrides. The overridable form sets a default that enterprise team files can change:
{
"model": "fusion",
"fusionTier": { "overridable": "standard" }
}
A team file can then set "fusionTier": "high". Users can still pick a different model for a single conversation. fusionTier requires Copilot CLI 1.0.104-3, VS Code 1.144.0 or GitHub Copilot app 1.1.33-4 or later. GitHub's client support table lists fusionTier for those three clients and marks it as not supported in JetBrains IDEs and Copilot in the cloud. It also marks model as not supported in JetBrains IDEs, so a managed Fusion default will not reach JetBrains users. For how to check a settings file before rollout, see why a valid JSON file is not a working Copilot policy.
Fusion or Copilot Auto as the default?
Both are routers, and both have a tier key. Auto uses "model": "auto" with autoTier values of "efficiency", "balance", "intelligence" and "unmanaged". Fusion adds the multi-model patterns on top of model selection. Teams that set Auto tiers earlier (see Copilot Auto's tiers) face a similar choice. BaristaLabs interpretation: Fusion Standard, which selects one model for each task, is the closest fit for a team moving from Auto, while High and Max are where the extra multi-model calls come in.
Local models are a separate question. Fusion can route to a locally installed MAI Code 1.1 Flash or Qwen3.8 Flash Next only from Fusion Standard, and only as an experimental preview. GitHub's local model changelog notes that routing decisions still happen in the cloud and that local models may have different safety protections.
Why it matters for engineering leads who own Copilot spend
BaristaLabs interpretation: Fusion moves the cost decision from "which model" to "which tier," and the tier is now an admin setting. A Max default would start every new session at the effort level GitHub aims at the hardest tasks, including routine edits that Fusion Standard would send to one model. Because the 30% discount ends November 30, model costs measured in November will read lower than the same usage at full rates in December.
Recommended first step: default to Standard, let teams opt up
BaristaLabs recommendation: set "model": "fusion" with "fusionTier": { "overridable": "standard" }, review the Fusion model list before turning it on, and grant "high" through an enterprise team file only for groups doing multi-file or hard debugging work. Before November 30, record credit usage per team for two weeks and recompute it at full rates, so the December number is not a surprise. Keep Max out of the default, and test whether users on the overridable default can still select it, because GitHub's reference describes team overrides, not user overrides.
Sources and scope
- GitHub Changelog, Route and orchestrate models with GitHub Copilot Fusion, October 28, 2026.
- GitHub Docs, About GitHub Copilot Fusion, accessed October 31, 2026.
- GitHub Docs, Managing availability of models in your enterprise, accessed October 31, 2026.
- GitHub Docs, Enterprise managed settings reference, accessed October 31, 2026.
- GitHub Changelog, GitHub Copilot Fusion now supports selection of local models, October 28, 2026.
The benchmark figures are GitHub-reported results from the Artificial Analysis Coding Agent Index and were not reproduced by BaristaLabs. The sources do not give per-tier credit averages, so the cost of High or Max on a given codebase has to be measured. For help planning a Copilot rollout, see AI consulting.
Copilot Fusion rollout
Set the Fusion default before the discount ends
Bring the current Copilot model policies and managed settings file. BaristaLabs can help you choose a default tier, decide which teams get High, and estimate credit use at full rates after November 30.
The current managed-settings.json and a list of Copilot teams is enough to start.
Turn this idea into a pilot
Which workflow should go first?
Use the readiness check to compare impact, effort, risk, owner, and next step before requesting a review.
- 3-5 minutes
- Deterministic score
- No sensitive data
Practical AI Workflow Notes
Want more practical AI operations ideas?
Get short notes on applying AI inside real small-business workflows — from document handling and customer follow-up to internal reporting, compliance, and automation guardrails.