GitHub made Copilot Fusion generally available on October 28. The short version: when you pick Fusion in the model picker, you are no longer picking a model. You are picking an effort level, and a runtime router decides which model or models serve each step of your task. GitHub told VentureBeat plainly: "It's not a model. It's an orchestration engine at runtime."
That is a bigger interface change than it sounds, and it landed with a benchmark claim worth reading carefully, an admin policy surface worth configuring on day one, and a local-model preview with a cloud footnote nobody should miss.
What actually shipped on October 28
Fusion merges two earlier GitHub systems: Project HydraFusion, the multi-model orchestration research preview, and Copilot's automatic model selection. Open the model picker in VS Code, the Copilot app, Copilot CLI, or JetBrains IDEs, select Copilot Fusion, and choose one of three effort levels:
- Fusion Standard for everyday coding, prioritizing versatile models
- Fusion High for challenging tasks and deeper reasoning
- Fusion Max for the most demanding work, prioritizing the most capable models
From there the router takes over. For each prompt it decides which models to use and how they work together, across reasoning, code generation, debugging, and tool use. If you were in the research preview with auto, HydraFusion, or HydraFusion Max enabled, GitHub says those selections transition automatically to the corresponding Fusion effort levels.
The three workflows the router picks from
The changelog names three orchestration patterns, and they are worth knowing because they are the same patterns people hand-roll in multi-agent setups:
Single: prompt -> one model -> answer
Cascade: prompt -> efficient model drafts -> quality check
pass -> answer
fail -> escalate to a stronger model -> answer
Critique: prompt -> model A drafts -> model B reviews
-> model A revises -> answer
Single is the cheap path. Cascade is draft-then-check, spending a stronger model only when the cheap draft fails its own quality gate. Critique is a built-in reviewer loop. If you have ever wired a subagent to draft and a second pass to review, Fusion productizes exactly that, with the escalation decisions made for you per prompt.
Reading the benchmark claim before you quote it
GitHub's headline number: in the Artificial Analysis Coding Agent Index, Fusion Max scored 60, within two points of Claude Code running Opus 5.5 Max, at about half the average API cost per task, using about half as many tokens, and taking about 40 percent less time per task.
That is a strong result, but note what it measures: per-task API cost on a benchmark index, Fusion Max versus a specific competitor configuration. It is not a promise about your invoice. Billing works per model at each model's standard rate, so a Cascade escalation to an expensive model costs what that model always costs. There is a 30 percent discount on model costs for paid plans "for a limited time," which is exactly the kind of phrase you should read as temporary pricing during a land-grab phase.
Your model picker is becoming an effort dial
The interface shift is the real story. This morning Claude Code 2.1.316 shipped CLAUDE_CODE_SUBAGENT_EFFORT, a variable that sets the effort level subagents run at instead of inheriting the session's. GitHub's Fusion does the same move from the other direction: the human-facing control is how hard the system should try, and the model choice underneath becomes an implementation detail.
GitHub's own numbers explain why. Per the Universe recap reporting Octoverse data, paid Copilot users touched 47 different models in September, no single model handled more than a quarter of requests, and 63 percent tried automatic model selection at least once. Model choice stopped being a decision humans are good at, so the vendors moved the dial to something humans are good at judging: how much this task is worth.
The three settings administrators actually own
If you run Copilot for a team, Fusion is mostly a policy problem, and the changelog gives you three concrete levers:
- Model policies gate the router. Fusion only uses models enabled in your enterprise and organization model policies. A model your org blocks cannot be routed to, period.
- You can disable a model for Fusion only. Administrators can turn a model off for Fusion without disabling it for developers who select it directly, which lets you cap what the router may escalate to.
- You can set Fusion as the default. Enterprise managed settings can make Fusion, at any effort level, the default for all Copilot users in the org.
Deciding the default effort level is now a budget decision with a cost curve behind it, the same class of decision as choosing what runs your subagents elsewhere in the stack. Set Max as the org default and every casual question escalates through the most expensive path the router is allowed.
Local models, with a cloud footnote
The same day, GitHub shipped intelligent routing for local models into experimental preview in Copilot CLI, the Copilot app, and VS Code. Fusion can now choose between on-device models and cloud models per request. On Windows you can pull MAI Code 1.1 Flash through the Windows ML provider; on any platform you can configure MAI Code 1.1 Flash or Qwen3.8 Flash Next through a local OpenAI-compatible server:
# VS Code: enable local model support
"chat.copilot.localModel.enabled": true
# Copilot CLI: enable experimental mode, then
/model # follow the local-model setup prompts
# Copilot app: Settings > Model providers (Windows ML)
# Settings > Experiments > Local model auto routing
Read the footnote before you assume this is an offline mode. GitHub's own words: "Local inference doesn't make your session offline. Copilot Fusion still makes routing decisions in the cloud, and local models may have different safety protections from Copilot-provided cloud models." If your threat model is "nothing leaves the machine," this preview is not that, and bring-your-own-key models discovered through BYOK configuration are not automatically eligible for routing either.
What still decides quality when the model is a commodity
The Octoverse recap reports agents started more than 40 percent of pull requests in September, up from 17 percent in March, and 90 percent of agent-started PRs merged within two weeks. When a router picks the engine per step, and agents open a large share of the PRs, the parts you actually author shrink to the instructions, the review gates, and the policies. The model picker was never where the real gains lived anyway. If Fusion removes the ritual of swapping models mid-task, that is a fair trade, as long as you put the reclaimed attention into the files that still respond to you, like the instructions Copilot actually reads and the permission boundaries around what agents may run.
Fusion is available on all Copilot plans. Update the client, open the model picker, and before you default the whole org to Max, read the billing line twice.
Top comments (0)