GitHub Copilot Fusion: You Stop Picking Models, and That Changes More Than Your Bill

SAMI

November 7, 2026 16 mins to read

Short version for busy readers. On October 28, 2026, at GitHub Universe, GitHub made Copilot Fusion generally available. You no longer pick Claude, GPT or Gemini in the model picker. You pick “Copilot Fusion” plus an effort level (Standard, High or Max), and Copilot decides, prompt by prompt, which models run and how they cooperate: one model alone, a cheap model with a judge that can escalate, or a draft reviewed by other models. In the Artificial Analysis Coding Agent Index, Fusion Max scores 60 against 62 for Claude Code with Opus 5.5 Max, for about half the cost per task and roughly 40% less time. I think it is the most important Copilot change of the year. I also think most teams will read the headline number wrong, and that regulated shops like mine have homework to do before turning it on by default.

Why GitHub built it

Look at the model picker in Copilot today. GitHub lists 28 generally available models, 11 of them from Anthropic alone. Each has its own price, its own strengths and its own failure modes. Asking every developer to choose the right one for every prompt was always a fiction.

What actually happens is simpler and more expensive. A developer hits a hard bug, switches to the biggest model, fixes the bug, and keeps using the biggest model for the next three days of renaming variables and writing docstrings. AT&T described exactly this pattern in GitHub’s launch post: people pick a powerful model for a complex task and forget to switch back. Fusion Standard, they say, cut that waste across the company.

GitHub had data pointing the same way. According to its 2026 Octoverse findings, 63% of paying Copilot developers used automatic model selection at least once in September. People were already willing to delegate the choice. Fusion takes that habit and adds orchestration on top.

There is a second reason, less visible from the IDE. Model quality is no longer the only thing that separates coding agents. The harness around the model (tools, context management, review loops, routing) now moves benchmark scores as much as the model does. Devin and OpenRouter have both shipped their own forms of multi-model fusion this year. GitHub owns the harness, the editor integrations and the billing relationship, so a router is the natural next layer for it to own.

What Copilot Fusion is

From HydraFusion to Fusion

Fusion did not appear out of nowhere. The lineage is short and public:

Date	Step
Early 2026	Auto model selection: Copilot picks one model per task
September 4, 2026	Project HydraFusion research preview in Copilot CLI (behind `/experimental`)
September 30, 2026	HydraFusion reaches VS Code and the Copilot app
October 28, 2026	Copilot Fusion GA, merging auto selection and HydraFusion

If you enabled auto, HydraFusion or HydraFusion Max during the preview, GitHub moves you automatically to the matching Fusion effort level.

The mental model: a policy in the model picker

When you choose Fusion, the picker no longer holds a model. It holds a routing policy. For each request, Fusion reads capability signals (reasoning, code generation, debugging, tool use) and selects an execution pattern, a reasoning effort and the models that will run it. GitHub says this decision is a lightweight step with minimal added latency.

Two details from the docs matter more than they look:

Fusion routes “along natural cache boundaries” and when conversation complexity changes sharply. It tries to keep your main conversation on the same model so you keep benefiting from cached tokens. Helper models, such as a reviewer, only receive the context they need.
Fusion also looks at real-time system health and availability. If a provider is struggling, routing takes that into account.

Three effort levels you can choose (and one you cannot)

Effort level	What GitHub says it prioritizes	When I would use it
Fusion Standard	Balance of cost, quality and latency. One model per task.	Default for everyday work: explanations, small edits, tests, docs
Fusion High	Orchestration with moderate token savings	Well-scoped but substantial work: a nasty bug, a change across several files
Fusion Max	Frontier capability, still watching token efficiency	Hard reasoning, design-level refactoring, the task you would give your best senior
Fusion Fast	Only for scenarios that need fast models	Not selectable. Used in VS Code inline chat

All three selectable levels are on the Copilot plans’ feature list, but the docs publish a per-plan matrix and some independent coverage reports that High and Max require higher tiers (Pro+ and above). Check the matrix for your plan before writing internal guidance.

Three execution patterns

This is the heart of the feature.

Single. One model solves the task. It behaves like a normal request.

Cascade. An efficient model drafts a solution. A judge inspects the draft and either accepts it or escalates to a stronger model. You pay for the cheap draft, the judge and, if needed, the strong model.

Critique. One model drafts, reviewers critique, and the drafting model revises. In the HydraFusion preview this was a single read-only critic from a different model family, revising once. The current docs describe several critics working in parallel, with their feedback aggregated before the revision. The GA changelog still describes one reviewer. My reading: the pattern is evolving, and the docs say so explicitly (“execution patterns and model pool may change over time”).

The pattern is chosen per prompt. Your first prompt may run Single, your follow-up may run Critique. Simple tasks never pay for a review they do not need. Cascade and Critique take longer because they add model calls.

What you see while it works

You can follow the progress of each step and the model in use. Intermediate drafts stay hidden, because they may be revised or thrown away; you only get the final answer. After the response, hovering over the effort level shows the list of models used.

Fusion has no context window of its own. Each step runs inside the limits of the model running it, and the window displayed for Fusion is a conservative value based on the smallest model in the pool. If you routinely paste huge files, keep that in mind.

Local models, in preview

GitHub also shipped an experimental preview where Fusion can route between on-device and cloud models, in Copilot CLI, the Copilot app and VS Code. On supported Windows machines you can download MAI Code 1.1 Flash through Windows ML. In Copilot CLI you can also bring Qwen3.8 Flash Next through a local OpenAI-compatible server (Ollama, for example) on Windows, macOS or Linux. Local models are only used at the Standard level.

Two caveats that GitHub states itself: routing decisions still happen in the cloud, so your session is not offline, and local models may not carry the same safety protections as Copilot’s cloud models. Models added through bring-your-own-key are not automatically eligible for Fusion routing.

Billing

There is no separate fee for Fusion. You pay for each model it uses, at that model’s standard rate, in AI credits. Because High and Max can call several models for one task, a task may cost more credits than it would on Standard. Through November 30, 2026, paid plans get a 30% discount on model costs when using Fusion.

Controls for administrators

Fusion only uses models enabled in your enterprise and organization model policies.
Enterprise admins can see the pool Fusion picks from and disable a model for Fusion without disabling it for everyone.
Admins can set Fusion, at any effort level, as the default model through enterprise managed settings.
Fusion automatically excludes models outside your plan, models blocked by policy, models excluded by data-residency or FedRAMP restrictions, and restricted evaluation models. If nothing is left, Fusion simply disappears from the picker.

Limitations GitHub documents

Fusion does not start subagents and works separately from them.
If Fusion discards a draft, file edits that draft already made in your workspace are not undone automatically.
The pool and the patterns will change over time.

Where it runs today: VS Code, Copilot CLI, the GitHub Copilot app and JetBrains IDEs, on all Copilot plans, with more clients announced.

Reading the benchmarks without fooling yourself

GitHub’s launch line is that Fusion Max scored 60 in the Artificial Analysis Coding Agent Index, within two points of Claude Code with Opus 5.5 Max, at about half the API cost per task, with about half the tokens and about 40% less time. Artificial Analysis published the detail, and the detail is more interesting than the headline.

Artificial Analysis Coding Agent Index v2.0	Claude Code, Opus 5.5 (Max)	Copilot Fusion (Max)
Overall index	62	60
FrontierCode v1.1	56%	51%
Terminal-Bench 4.0	63%	71%
SWE-Atlas QnA	66%	57%
Average API cost per task	$11.42	$5.59
Average wall time per task	1.0 h	36.1 min
Tokens per task	14.5M	7.3M

Three observations.

The average hides a shape. Fusion wins clearly on Terminal-Bench, the benchmark of multi-step agentic work in a terminal. It loses five points on FrontierCode and nine points on SWE-Atlas QnA, which is about understanding and answering questions over real codebases. A two-point gap on the composite is the sum of a big win and two real losses. If your developers mostly run agentic build-and-fix loops, Fusion looks excellent. If they mostly ask deep questions about a large legacy codebase (hello, banking), the gap is wider than “two points”.

Cost per task is a list-price number. The $5.59 versus $11.42 compares pay-per-token API cost on one benchmark. Your invoice depends on your plan, your mix of tasks, cache hit rates, how often Cascade escalates and whether the 30% launch discount is still running. Half the cost on a benchmark is a strong signal, and a poor budget forecast.

The early numbers were GitHub’s own. HydraFusion’s September results (TerminalBench 2.1: +4.9 points at 67% lower cost; DeepSWE: 1.5 points below at 36% lower cost; CheckpointBench: 0.1 points below at 65% lower cost, all versus Opus 5) came from controlled offline evaluations, with every model run at medium reasoning, and CheckpointBench is internal. GitHub was transparent about those limits. The Artificial Analysis run is the first independent number, and it is one run, on one index version.

One more line from that comparison deserves attention: Devin’s own fusion of Opus 5.5 and GPT-6 Luna scores 62 at $8.00 per task. Multi-model orchestration is becoming the industry pattern. Copilot’s edge is price and integration; others have the idea too.

What I like

It fixes a real behavioral problem. The AT&T quote is the most honest part of the launch. Model selection is a discipline nobody keeps. A default that adapts per prompt beats a policy document that asks developers to switch models by hand.

Selectivity is the right design. The interesting idea in HydraFusion was never “use more models”. It was “use the least complex workflow that meets the quality bar”. A simple prompt runs on one model and pays nothing extra. That is how a senior engineer delegates: you only ask for a second review when the change deserves one.

Cache awareness shows engineering maturity. Naive routers switch models mid-conversation and throw away the prompt cache, which can wipe out the savings they promise. Routing on cache boundaries is the kind of unglamorous detail that makes the cost claims plausible.

Governance is built in from day one. Model policies, per-Fusion exclusions, data-residency and FedRAMP filters, managed defaults. For an enterprise, this matters more than the benchmark.

What worries me

Your model choice becomes a vendor policy you do not control. With Fusion, the same prompt next month may run on different models, through a different pattern, because GitHub updated the pool or the routing policy. That is fine for productivity. It is less fine for anything that needs reproducibility: debugging a regression in agent behavior, comparing two sprints, or explaining to an auditor why the tool behaved differently in March. When you need stable behavior, pin a model.

Traceability is thinner than regulated teams need. Hovering to see which models were used is useful for a curious developer. A bank’s model-risk or compliance team will ask a harder question: for this commit, which models saw this code, under which policy, at what time? Before making Fusion a default, check what your audit logs, usage API and OpenTelemetry export record per request. I could not find a documented per-request routing record that answers that question on its own. If you can’t trace it, restrict the pool to models your risk team has already approved, so that “which model” stops being a compliance question.

Discarded drafts can leave edits behind. This line in the limitations section is easy to miss and I would put it in bold in any internal guide: if Fusion throws away a draft, edits that draft made to your workspace stay there. Agent mode plus Cascade or Critique means you must review the full diff before committing, every time. Pair this with hooks, protected branches and mandatory review, which you should have anyway.

Latency moves to where you notice it. Cascade and Critique add model calls. Fusion Max was faster than Claude Code on the benchmark, but that compares two heavy agents. Compared with a single fast model on a routine task, a High or Max run that decides to critique will feel slower. Keep Standard as the default and let people opt up.

Cost predictability gets harder, at least at first. Per-model billing for every leg is fair, and the docs warn that High and Max can consume more credits than Standard. But a finance team used to one line per seat will now see variable spend driven by a router’s decisions. Set budgets and credit limits before rollout, and measure again after November 30 when the discount ends.

The broker question. GitHub benchmarks Fusion against Claude Code while Anthropic supplies 11 of the 28 models in Copilot, including the Opus 5.5 used as the reference. Fusion turns GitHub into a broker between model vendors. That is convenient for you, and it shifts bargaining power toward GitHub. Over time, the router decides which vendor gets your tokens. Worth knowing when you negotiate your next enterprise agreement.

Developers may lose their feel for models. If the router always chooses, junior developers will never learn why one model is better at a given kind of task. I am not sure that matters for most people, in the same way most of us no longer know which CPU instructions our compiler emits. For the people who build your internal AI tooling, though, keep a habit of testing models directly.

How to adopt it

For developers: get started in five minutes

Update your client (VS Code, JetBrains, Copilot CLI or the Copilot app).
Open the model picker and select Copilot Fusion.
Choose the effort level. Start with Standard.
After a response, hover over the effort level to see which models ran.

In Copilot CLI, /model opens the picker. For the local-model preview:

# Copilot CLI: enable experimental features, then pick a model
/experimental on
/model

# VS Code: enable on-device models
"chat.copilot.localModel.enabled": true

# Copilot app: Settings > Experiments > Local model auto routing

A simple rule of thumb for effort levels:

Task	Effort
Explain code, write tests, small refactors, docs	Standard
Fix a bug that touches several files, implement a scoped feature	High
Design-level refactoring, tricky concurrency, migration planning	Max
Need identical behavior across runs, or a model your team validated	Pin a specific model instead

For tech leads: run a two-week pilot, not a mandate

Pick one repository and one team. Run Fusion Standard as the default and allow High and Max on request.
Track four numbers: AI credit consumption per developer, merged PRs or closed tasks, review rework (changes requested on AI-assisted PRs), and developer satisfaction.
Collect the “models used” list for a sample of tasks. You will learn quickly which patterns fire on your codebase.
Compare with the previous two weeks on fixed models. Decide with your own data, not with a benchmark run on someone else’s code.

For administrators and decision-makers: settle governance first

Review the model pool Fusion can use. Disable for Fusion any model your risk or legal team has not approved, without removing it for everyone.
Check data-residency settings. Fusion respects them, but only if they are configured.
Decide whether Fusion becomes the managed default, and at which level. My recommendation: Standard as default, never Max as default.
Set credit budgets and alerts per organization or cost center before rollout.
Confirm what your audit logs and telemetry record for Fusion requests.
Keep local-model routing off in regulated environments until it leaves preview, given the different safety profile and the fact that routing still runs in the cloud.

Checklist: is your team ready for Fusion?

[ ] Model policies reviewed and the Fusion pool restricted to approved models
[ ] Data-residency and compliance filters configured
[ ] Budgets and credit alerts in place
[ ] Effort-level guidance written (Standard default, High and Max on purpose)
[ ] Rule written down: review the full diff before committing agent work
[ ] Audit and telemetry checked for per-request model traceability
[ ] Pilot metrics defined and baseline captured
[ ] Date set to re-evaluate costs after the launch discount ends

My verdict

Copilot Fusion is the moment model selection becomes infrastructure. For most developers it will be an invisible improvement: the right model more often, less waste, and a second opinion when the task deserves it. The benchmark gap with the best single-agent setup is small on average and very uneven in detail, which is exactly why you should test it on your own code before believing anyone’s number, including GitHub’s.

For teams in regulated industries, the harder question is “can we explain what it did?”. Restrict the pool, keep Standard as the default, review every diff, and measure. Do that and Fusion is probably the best default Copilot has shipped.

I will be testing it on our internal tooling over the next weeks. If you run your own pilot, I would like to compare notes.

Sources