GitHub launches Copilot Fusion to route coding requests across models

GitHub made Copilot Fusion generally available on October 28, across supported Copilot clients. The feature can route a request to one model, escalate a draft or request critique, and GitHub adds no separate charge for it: the underlying models are billed at their standard rates, according to the current Copilot Fusion documentation.

Fusion arrives as Copilot is no longer a single-model assistant but a picker with many models behind it. This first article in the thread sets out what GitHub has documented, what it costs, who decides which models are in play, and what nobody has yet measured.

What GitHub launched with Copilot Fusion

Kingy AI, which reviewed GitHub’s announcement and documentation, describes Copilot Fusion as “model routing in supported clients”. In practice that means Copilot can do one of three things with a request: send it to a single model, escalate a draft, or ask for a critique. “Routing” here means deciding which model handles a given request rather than having the user pick one model for everything.

The launch status is general availability, not a preview or waitlist. It covers supported Copilot clients; the summary does not list which editors or surfaces count as supported, so teams should check GitHub’s current client documentation before planning a rollout.

Item	What the sources state
Status	Generally available
Date	October 28, 2026
Where	Supported Copilot clients
What it does	Routes a request to one model, escalates a draft or requests critique
Model and effort choices	Depend on plan and administrator policy
Fusion fee	None; underlying models billed at standard rates
Promotion	30% paid-plan model-cost discount through November 30, 2026
Credit use	Multi-model tasks can use more credits

Route, escalate or critique: how Fusion handles a request

The three modes GitHub describes map onto patterns many teams already assemble by hand when they call several models through APIs:

• Route to one model. A request goes to a single model, chosen for that request.
• Escalate a draft. A draft can be escalated, which in common usage means handing work onward for further processing.
• Request critique. Copilot can request a critique of work, a review step layered on top of generation.

The summary does not spell out how Fusion decides which model handles which step, whether users can override its choices in each client, or how escalation and critique results are shown in the editor. Those details matter for anyone who wants predictable behaviour, and they are not in the sources reviewed here.

“Effort settings” are also part of the picture: the available models and effort settings depend on plan and administrator policy. The sources do not define the effort levels or what each one changes.

Pricing: no Fusion fee, but multi-model work can cost more

Price is part of this launch, so it is reported here as GitHub documents it. There is no separate charge for Fusion itself; the underlying models are billed at their standard rates, according to the current Copilot Fusion documentation.

The catch is arithmetic. GitHub’s documentation notes that multi-model tasks can use more credits. A request that is escalated or critiqued involves more model work than a single call, so a team that turns on escalation or critique broadly should expect higher consumption than from single-model use, even though no Fusion line item appears.

GitHub also documents a 30% paid-plan model-cost discount running through November 30, 2026. That discount makes the first month of experimentation cheaper, but it also means early usage bills may understate what the same workload will cost once the promotion ends. Teams measuring the cost of Fusion during November should account for that when projecting forward.

Who decides which models Fusion can reach

Fusion does not open every model to every user. Available models and effort settings depend on plan and administrator policy. For organisations, that puts the routing pool under administrator control: what Fusion can escalate to is bounded by what the plan and the admin allow.

That design follows a pattern already visible in Copilot. In March 2026, a GitHub Community discussion reported that premium models, including GPT-5.4, Gemini 3.1 Pro and Claude Opus 4.6, vanished from the Copilot model picker after a VS Code update, particularly affecting GitHub Education accounts. One community member noted that as of March 2026, premium models were no longer manually selectable for Student Plan users, pointing to a policy change rather than a glitch.

The same discussion reported that GitHub controls model access through feature flags, so models can appear or disappear without any local system change. A non-student Copilot Pro subscriber reported similar disappearances. The devactivity.com write-up of that thread identified the common complaint as a lack of clear communication from GitHub about the changes.

That history is relevant to Fusion. A routing feature is only as stable as the pool it routes across. If the models available to a plan change server-side, a Fusion workflow that relied on escalating to a particular model could behave differently from one week to the next, with no change on the developer’s machine. The sources do not say whether Fusion surfaces which model handled a request, which would make such shifts easier to spot.

What it means for teams building with Copilot

For developers who already call several models through APIs, Fusion moves a familiar pattern, draft with one model and check with another, into the coding tool itself. GitHub has been heading this way for a while: its GitHub Models service, for example, already let developers try, compare and integrate models such as Phi-4, a 14-billion-parameter small language model, in a playground or through an API, including side-by-side comparisons.

Three practical points follow from the documentation:

1. Budget by task, not by feature. Because there is no Fusion fee but multi-model tasks can use more credits, cost depends on how often escalation and critique run.
2. Set policy before rollout. Administrators decide which models and effort settings are available, which shapes what Fusion can do for each team.
3. Keep human review. Kingy’s own guidance is to review generated changes before committing. A critique step from a second model does not replace that.

The launch also lands in a week of agent-driven code tooling. Replit opened its company-codebase Cloud Agent workflow to Pro and Enterprise customers on October 27, letting contributors request changes in plain language and receive proposed code as GitHub pull requests or GitLab merge requests for engineers to review. Tools of this kind push more machine-written changes into the same review queues where Copilot operates, which raises the stakes on review quality.

For broader context on how model vendors are packaging agent workflows, see recent coverage of Mistral’s Responses API preview for AI agents and OpenAI’s monthly API credits for ChatGPT Pro and Business plans.

What is not yet known about Copilot Fusion

The evidence for this launch is thin on performance. Kingy AI states plainly that it has not tested routing quality, latency or costs, and no independent tests appear in the sources reviewed for this article. GitHub’s own announcement is not among those sources either, so this article relies on Kingy’s summary of it and of the documentation.

Open questions the sources leave unanswered:

• Quality. Whether escalation or critique produces measurably better code than a single strong model is untested in the sources.
• Latency. Multi-step requests involve more model work; how much slower they are is not reported.
• Cost visibility. The documentation says multi-model tasks can use more credits, but the sources give no typical figures.
• Stability of the model pool. Given past reports of models disappearing from Copilot’s picker through feature flags, it is unclear how Fusion behaves when a model it routes to is withdrawn.
• Usage figures. The sources reviewed contain no statistics on how many models Copilot users run or how much code agents produce.

What to watch next

The nearest date is November 30, 2026, when GitHub’s documented 30% paid-plan model-cost discount ends. Usage bills after that date will give a clearer picture of what Fusion workflows cost at standard rates.

Beyond that, the useful signals are independent measurements of routing quality, latency and cost, which the sources say have not yet been run by Kingy AI; any change to which models and effort settings each plan can reach; and whether GitHub communicates model-availability changes more clearly than community members said it did in March. Unicorn API will follow this thread as GitHub publishes more detail and as testers report results.