GitHub Copilot Fusion Goes Live: Pick an Effort Level, Let It Pick the Models

GitHub Copilot Fusion is generally available

GitHub made Copilot Fusion generally available on October 28, 2026, announced at GitHub Universe 2026 in San Francisco. GitHub Copilot Fusion is not a new model, and understanding that is the key to understanding the release. It is a routing and orchestration system in the model picker: it decides which models to use, and how to combine them, for each request. Instead of a developer picking a model and hoping it is the right one for the task, Fusion picks the combination, and the developer picks how much effort to spend.

Fusion merges two earlier pieces: the multi-model orchestration of Project HydraFusion, which was in research preview from September 4, 2026, and Copilot's auto model selection. Existing Auto, HydraFusion, and HydraFusion Max selections move to corresponding Fusion effort levels. If you were using any of those, you are already on the path to Fusion, and the transition should feel like a rename with better behavior rather than a new tool to learn.

Three effort levels, not a model list

There are three effort levels. Standard is for everyday work with versatile models. High is for harder tasks and deeper reasoning. Max is for the most demanding tasks with the strongest models. That framing is a genuine usability improvement. Most developers do not want to maintain a mental ranking of a dozen models and their strengths. They want to say how hard the task is and how much they care about the result, and let the system handle the rest.

Fusion is available on all Copilot plans in Visual Studio Code, the GitHub Copilot app, Copilot CLI, and JetBrains IDEs, with more clients to follow. Admins control which models Fusion can draw on under enterprise and organization policies, and they can set it as the default. That admin control matters more than it sounds: in a company, model choice is not just a developer preference, it is a cost, compliance, and data question, and Fusion gives organizations a way to set boundaries without taking the tool away.

Billing: no separate fee, but watch the meter

Billing is straightforward and worth reading carefully. There is no separate Fusion fee. Each model used is billed at its standard rate, and paid plans get a 30 percent discount on Fusion model costs through November 30, 2026. That discount is a sensible nudge: GitHub wants teams to try Fusion now, while the habit is forming, and a discount through the end of November is long enough to run a real evaluation.

The billing model also reveals the trade-off. Fusion can use multiple models for one request, which means one request can cost more than a single-model call, even if each model is billed at its standard rate. The efficiency argument is that Fusion avoids staying on an expensive model after a hard task is done, or using a heavy model for a trivial task. Early user evidence supplied by GitHub points that way: Hari Pokhrel, principal software engineer at AT&T, says Fusion Standard improved token efficiency at the company by avoiding staying on a more powerful model after a hard task. That is a vendor-supplied quote, so treat it as a claim, but the mechanism it describes is plausible and testable on your own usage data.

The benchmark claim, with a flag on it

GitHub's own benchmark claim is that Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, two points behind Claude Code running Opus 5.5 Max, at roughly half the average API cost per task (about 5.59 dollars versus 11.42 dollars), about half the tokens, and about 40 percent less time per task. Those are GitHub's figures, not independent test results, so the article should flag that, and so should your evaluation. Vendor benchmarks are useful as a starting hypothesis, not as a conclusion.

Still, the shape of the claim is interesting. Fusion is not claiming to beat the best single model. It is claiming to get close to it at half the cost and in less time. That is a different kind of win, and for most teams it is the more relevant one. A coding assistant that is slightly less capable but dramatically cheaper and faster will get used more, and used more is what turns an assistant into a habit.

What this means for how developers work

The bigger shift here is about who makes the model decision. For years, the developer experience of AI coding tools has been: pick a model, write a prompt, hope for the best. Fusion moves the decision into the system, and that is part of a wider trend. The OpenCode 2.0 release rebuilt an open coding agent around a background service, and the JetBrains Java and Kotlin tooling for VS Code hit 1.0 with a subscription to price first. Every layer of the developer stack is getting more agentic and more managed at the same time.

That trend has a cost worth naming. When the system picks the model, the developer loses visibility into why a particular answer came out the way it did. Debugging a bad suggestion gets harder when you do not know which model produced it, or what it was combined with. Good tooling should surface that information when asked, even if it hides it by default. Fusion's effort levels are a good abstraction, but abstractions leak, and the leak usually happens on the hardest task, which is exactly when you most want to know what is going on.

For most developers, the practical move is simple: try Fusion Standard for a week of normal work, check your token usage and costs against the previous week, and only reach for High or Max when a task genuinely resists the standard level. If the cost and quality numbers hold up on your own code, Fusion is a keeper. If they do not, the effort levels make it easy to see exactly where the system is spending your money, and that visibility is itself an improvement over picking a model blind.