GitHub Copilot Fusion is a model router and orchestrator, not a foundation model. You choose a level of effort and let the system decide how to handle the task. That makes the useful question different from a normal model comparison: what work did it run, under which policies, and what did that work cost?
Fusion reached general availability on October 28, 2026. The launch announcement lists VS Code, Copilot CLI, the Copilot app and JetBrains IDEs. Other clients are not automatically included by that announcement. This guide is based on documentation, not our own speed or quality benchmark.
What you are selecting
Think of Fusion as an execution choice above the underlying model. A fixed-model session makes that choice visible upfront. A routed session delegates some of the choice to the runtime. You still own the task definition, allowed tools, accepted result and spending policy.
That distinction matters when comparing runs. Two prompts with the same effort label need not use the same underlying model. A model pool can also evolve. Save task traces and selected model information rather than recording only “Fusion Max” in an evaluation spreadsheet. Our Copilot app guide covers the broader client rather than this specific routing decision.
Standard, High and Max
GitHub’s Fusion reference describes the available effort choices and runtime patterns. Effort is a preference, not a promise of a specific model, output length or maximum bill.
| Choice | Practical evaluation starting point | What not to infer |
|---|---|---|
| Standard | Small, bounded coding work | Every allowed model has the same cost |
| High | A substantial change with clear acceptance tests | Additional checking guarantees correctness |
| Max | Difficult work where another reasoning pass may help | The strongest option is always worth its cost |
The documented execution patterns are Single, Cascade and Critique. They respectively use one solver, a draft with a quality decision, or drafting plus critique and revision. These are routing mechanisms, not a replacement for your project’s own tests. A model judging another answer can miss the same mistaken assumption.
An additional Fusion Fast mode is documented for VS Code inline-chat scenarios, not as another normal user-selectable effort setting. Keep that separate from the Standard/High/Max selection a user makes in the main picker.
Selecting Fusion and inspecting the result
In the Copilot app’s model-selection instructions, open the current model choice, enable Fusion and select the effort level. Turning Fusion off returns selection to a specific available model. Check your client’s current interface rather than assuming identical controls across every supported editor.
Before changing a team’s default, run a few representative tasks on a branch. Save the initial state and inspect the resulting diff, not just the final message. Verify that expected tests ran and that files outside scope were not changed. A discarded draft is not necessarily an automatic rollback of edits already made in the working tree.
For a reproducible comparison, keep the same repository revision and tool permissions, but do not pretend that repeated runs are deterministic. Sample more than one run when failures would be costly. Record both accepted outcomes and interventions. See testing generated code for a production-oriented acceptance workflow.
Billing: no flat price per Fusion task
GitHub bills the models used, rather than selling one fixed-price Fusion answer. The paid-plan launch offer discounts model costs by 30%; the current documentation ends that offer on November 30, 2026. Treat the date as an offer boundary, not a permanent pricing rule.
There is no basis for quoting a universal dollar price for Standard, High or Max. Multi-model work can generate multiple billable steps. Caching, input size and output size also affect the result. Consult Copilot usage-based billing before comparing a subscription price with task consumption.
Build a task-cost worksheet with four fields: total model spend, runner or tool spend, human review time, and accepted outputs. A low token total is not enough if the patch needs substantial repair. Conversely, a more expensive run can be worthwhile if it consistently removes a costly manual step. Those are evaluation criteria, not measured claims about Fusion.
Enterprise policy and model access
Fusion does not grant access to every model just because the router is available. Subscription eligibility and administrator policies still bound the pool. Data-residency restrictions can narrow it further. Review the active policy in the target organization, not a screenshot from a personal account.
For a controlled rollout, start with a small team and a documented allowed-model set. Separate a change to the default effort from a change to allowed providers. Otherwise a cost or behavior shift has two possible causes, making the result harder to interpret. Our AI security foundation covers the broader access boundary.
Keep permission approval separate from routing. Choosing Fusion does not authorize an agent to modify production, export a secret or approve its own pull request. The selected model and the execution sandbox solve different problems. Connect Fusion evaluations to agent security and require a human gate for sensitive actions.
Local-model routing is an experimental branch
The local-routing announcement is distinct from Fusion’s GA label. It describes opt-in experimental behavior with supported local models, while routing decisions still involve the cloud. It is not a promise of offline Copilot or local-only processing.
The documented paths also differ. MAI Code 1.1 Flash has a managed Windows installation path. Copilot CLI can recognize a locally served Qwen3.8 Flash Next model across supported desktop operating systems. Do not turn that into a claim that any arbitrary Ollama model works automatically in every Copilot client.
If local execution is a requirement, document which request stages leave the machine, what context they send and what happens when the network fails. A local inference process is only one component of that chain. Our Ollama, LM Studio and vLLM comparison helps distinguish hosting from orchestration.
Fusion versus subagents and Actions
Fusion’s internal execution patterns are not the same as asking separate coding agents to work in parallel. They also do not replace the automation lifecycle of GitHub Agentic Workflows. One chooses model execution within a task; the other defines repository automation that runs through Actions.
Keep deterministic unit tests and deployment checks outside the router’s discretion. A passing final explanation is not a build receipt. Use LLM regression tests to detect quality shifts when routing or model availability changes.
My take
Fusion is worth evaluating when manual model switching has become an operational burden. Start with Standard and explicit acceptance criteria, then test whether High or Max earns its extra work on difficult tasks. Do not make a temporary discount or a vendor benchmark the reason to grant broader permissions.
FAQ
Does Fusion have its own context window?
No independent model context is created by the router. The underlying models’ limits still matter; use the client’s conservative displayed limit.
Does Fusion always use several models?
No. Single-model execution is one of its documented patterns. Additional calls depend on the task and effort choice.
Is local routing generally available?
Fusion is GA, but its local-model routing feature remains experimental preview and requires opt-in.
Does the 30% discount make Fusion cheaper on every task?
No. It changes qualifying model rates temporarily, not the amount of work or the correctness of the result.
Can I still select a specific model?
Yes, subject to your client, plan and policies. Disable Fusion in the model selector when a fixed model is the intended evaluation condition.