The problem
On 28 October 2026, at GitHub Universe, GitHub made Copilot Fusion generally available on every Copilot plan in VS Code, the GitHub Copilot app, Copilot CLI and JetBrains IDEs. Fusion is not a model. GitHub’s chief product officer, Mario Rodriguez, put it plainly: “It’s not a model. It’s an orchestration engine at runtime.” You pick Fusion in the model picker and choose an effort level: Standard, High or Max. Fusion then decides, prompt by prompt, which models to call and how to combine them. It can use one model on its own (“single”). It can let a cheaper model draft while a judge decides whether to escalate to a stronger one (“cascade”). Or it can have other models critique a draft and send it back for revision (“critique”). Administrators decide which models are in the pool and can make Fusion, at any effort level, the default for their users. GitHub’s own cost-optimisation guide now has a section titled “Use Copilot Fusion as your default”.
The headline evidence comes from an independent tester. Artificial Analysis ran Fusion Max in Copilot CLI on its Coding Agent Index v2.0. It scored 60 at $5.59 per task, against 62 at $11.42 for Claude Code with Opus 5.5 (max), and used 7.2M tokens per task, about half of what Claude Code used.
The billing is the part worth arguing about. “When you use Copilot Fusion, you’re billed for each model it uses, at that model’s standard rate. There’s no separate charge for Copilot Fusion.” Because High and Max can use more than one model for a task, a task “may consume more AI credits” than it would on Standard. GitHub’s docs say paid plans get 30% off model costs when they use Fusion through 30 November 2026; the changelog itself only says ‘for a limited time’.
So the launch is really two decisions. GitHub moved the choice of model from the developer to GitHub. It left the cost of that choice with the developer.
What I concluded
The first decision is right. The second is half finished.
Routing by default is right because the manual model picker has stopped being a feature and become a chore. GitHub’s own Octoverse data for September 2026 shows how far this has gone. 61% of Copilot users who picked a model themselves used more than one, up from 50% four months earlier. Developers on paid plans used 29 distinct models in May and 47 in September, and no single model carried more than 25% of requests. 63% of paying Copilot developers used auto model selection at least once that month. A 47-entry picker hands a pricing problem to the person least able to price it. The AT&T engineer quoted in GitHub’s changelog describes exactly how it goes wrong: developers “would often choose a more powerful model for a complex task and forget to switch back for everyday activities.”
Pass-through billing is a defensible way to launch. It is honest, there is no routing margin hidden in the price, and every saving the router finds goes to the user. But it means GitHub now makes the decision that sets the cost while the user carries all of the variance. On a per-seat plan with a credit allowance, that is tolerable. On the Enterprise arrangement GitHub announced the same day, it is harder to accept: all Copilot features with no separate subscription, paying only for the AI credits used. GitHub’s changelog for this option says it includes no monthly AI credits per seat and that usage is metered from the first request. When a router’s choices hit a metered budget from the first request, it needs to come with a commitment about what those choices will cost. Today Fusion comes with a benchmark and a discount that expires in a month.
Whoever makes the decision should own a number. For Fusion, that means three things: an expected cost range for each effort level, a receipt for every routed request, and a report of what an organisation would have paid without routing. Without them, “use Copilot Fusion as your default” is advice an administrator cannot check.
Constraints
Model sprawl and cache economics. GitHub’s cost guide says that switching models mid-session invalidates the cache, and cached tokens are typically billed at 10% of the normal input price. A developer who switches models to save money can end up paying more. Fusion says it routes “along natural cache boundaries” and keeps the main conversation on one model where possible. A human picker cannot match that structural advantage, and it is the strongest argument for making routing the default.
One setting, one composite score. Artificial Analysis tested only Max, and only in the CLI. Its index weights three benchmarks equally, and the composite hides how uneven the results were. Fusion led Terminal-Bench 4.0 with 71. But it scored 51 on FrontierCode, behind Claude Code with Opus 5.5 (max) at 56 and Devin Fusion at 54, and 57 on SWE-Atlas-QnA-AA. VentureBeat describes FrontierCode as the benchmark focused on repository changes, which is the work most teams buy a coding agent for. The claim of 40% less time is GitHub’s own; Artificial Analysis does not publish the timing data. Satya Nadella’s “up to 77% lower cost” comes from a separate DeepSWE evaluation that GitHub reported itself, and it is a maximum, not an average.
The meter. Fusion has no fee of its own: you pay each underlying model’s standard rate. The $5.59 figure from Artificial Analysis is the API cost per task on its benchmark, which is a different meter from Copilot AI credits. The 30% promotion and the benchmark’s cost gap should not be multiplied together.
Governance. Fusion draws only on models that enterprise and organisation policies allow, and it leaves out models excluded by data-residency, FedRAMP or evaluation-model policies. Admins can see the pool and switch a model off for Fusion without switching it off for everyone. That is the right design. It also means a tightly governed enterprise may leave the router with very few models to choose from.
Failure semantics. Two lines in GitHub’s limitations section matter more than their placement suggests. First: “If Copilot Fusion discards a draft, changes that the draft already made in your workspace, such as file edits, aren’t undone automatically.” Second, Fusion has no context window of its own. The window it shows is “a conservative value based on the smallest limits among the models it uses.” If the router quietly discards a draft but keeps its edits, it hands back to the developer a verification job they never chose to take on.
The options, and what I traded away
| Option | What it buys | What it costs | Why I did / did not pick it |
|---|---|---|---|
| Keep the manual picker as the default | Full control, a predictable cost per request, and nothing new to trust | 47 models to choose from, a cache rebuilt on every switch, and developers forgetting to switch back | Not picked. Octoverse shows developers already juggling models. The picker is a cost they pay in attention. |
| Router by default, billed at pass-through rates (what GitHub shipped) | No routing margin, every saving goes to the user, and it is easy to explain | The buyer carries all the variance, there is no published cost per effort level, and the discount has an end date instead of a commitment | Partly picked. It is the right way to launch, but the wrong end state for metered enterprise budgets. |
| Router with a flat price per effort level | Predictable bills, and GitHub gains a reason to route cheaply | GitHub carries the margin risk, may be tempted to route cheaply and quietly lower quality, and needs a lot of usage data to set the price | Not yet. Until quality is published per effort level, a flat price would add the very opacity it is meant to remove. |
| Router with a published cost range, a receipt per request and a savings report | Buyers can check a decision they handed over, and admins can choose defaults on evidence | Engineering work on billing and audit screens, and GitHub has to show how often the expensive patterns run | Picked. It turns “trust the router” into a claim the buyer can verify. |
| Default to a single frontier configuration | The top composite score (62) | Roughly twice the cost per task on the Artificial Analysis benchmark | Not picked as a default. Keep it as an explicit override for hard repository-change work, where FrontierCode suggests it still leads. |
Evidence
GitHub Changelog, 28 October 2026. Generally available on all plans. Three effort levels and three execution patterns. Admins control the model pool and the default. Usage is billed per underlying model at that model’s standard rate, with a limited-time 30% discount on paid plans. GitHub says Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, within two points of Claude Code with Opus 5.5 Max. It says Fusion did so at about half the average API cost per task, with about half the tokens and about 40% less time.
GitHub Docs. Choosing an execution pattern is described as “a lightweight step that adds minimal latency.” Once a response is ready, you can see which models were used by hovering over it. The model pool “changes as new models become available and as GitHub evaluates which models perform best.” In public preview, Standard can also use local models (MAI Code 1.1 Flash and Qwen3.8 Flash Next). The cost guide says to use Fusion as your default, explains why switching models mid-session invalidates the cache, and documents per-session AI credit limits in Copilot CLI and the SDK.
Artificial Analysis, 28 October 2026. Fusion Max scored 60 against 62, at $5.59 against $11.42 per task. Devin Fusion scored 62 at $8.00. Fusion scored 71 on Terminal-Bench 4.0, 51 on FrontierCode (against 56 and 54) and 57 on SWE-Atlas-QnA-AA, and used 7.2M tokens per task. My arithmetic: $5.59 ÷ $11.42 ≈ 0.49, so the cost per task is about 51% lower, for about 97% of the composite score (60 ÷ 62).
Octoverse 2026. Covers the multi-model share (61%, up from 50%), the number of distinct models (29 to 47), no single model above 25% of requests, and auto selection used by 63% of paying developers. The preview, Project HydraFusion, routed almost 60,000 sessions in the CLI and the Copilot app. GitHub notes that its model-choice figures “describe observed use, not model quality.”
VentureBeat, 28 October 2026. Includes the Rodriguez interview. It explains that the 77% figure comes from a separate DeepSWE evaluation whose configurations were not available, and that the timing claim does not rest on Artificial Analysis data. On the Enterprise purchase option, it reports that there is no per-seat allowance and that metering starts with the first request. Code completions keep working when the budget runs out, but Chat, code review and cloud Copilot need budget. Rodriguez credited the savings to routing rather than subsidy, which, as VentureBeat notes, says nothing about GitHub’s margin. This matches GitHub’s changelog.
Counter-arguments worth taking seriously. @ibuildthecloud called Fusion a “naive short term play”, arguing that “slightly cheaper only slightly matters” and that open-weight models will collapse costs anyway. The post continues: “In 1-2 months Copilot Fusion will be irrelevant.” The answer is that a router is how cheaper models get in without every developer having to evaluate them. Fusion Standard can already pick local models in preview. If open weights do collapse the cost, the router is where that will show up. @awakecoding replied that Fusion “increases cost efficiency, not necessarily total cost.” I agree, and that is the billing problem in one sentence: being cheaper per task does not cap what you spend in a month.
Where this stops being true
The argument is weakest for individual developers on plans with a generous monthly credit allowance. There the allowance absorbs the variance, and Fusion Standard is simply a convenience. For teams whose work is mostly repository changes, my objection is about quality rather than price. On the one public breakdown, Fusion’s near-parity on the composite does not hold for FrontierCode. A router default could lose the most quality exactly where it matters most. In tightly governed enterprises with a small allowed pool, the router collapses back into a picker. And if GitHub gives admins per-request routing logs and a savings report, most of this argument is answered. VentureBeat says Rodriguez answered yes when asked whether organisations could see which models were used, but how detailed the per-request audit will be was not established.
What I am not claiming: that Fusion is worse than choosing models by hand, that GitHub is hiding a margin, or that the benchmark is wrong.
What I would do differently
- Publish an expected credit range for each effort level across a few task types, and ship High and Max with a default session credit limit. Copilot CLI and the SDK already support session limits.
- Give admins a routing receipt for every request, showing the models, the execution pattern and the credits used. Export it to the same place as the rest of the audit log, not only to a hover tooltip.
- Run cascade and critique drafts in an isolated worktree, so that a discarded draft cannot leave edits behind.
- Replace the date-bound 30% discount with a monthly counterfactual: what the organisation’s Fusion usage cost, compared with the models its developers picked before. If routing is as efficient as the benchmark says, that report sells itself.
- Publish an Artificial Analysis-style breakdown for Standard and High, not just Max, with repository-change tasks shown separately.
- For admins today: make Fusion Standard the default, not Max. Keep a named frontier model as an explicit override until your own receipts show where Max pays for itself.
The model picker was a way of making developers responsible for cost. Fusion takes that responsibility away from them, which is the right call. But the responsibility has to land somewhere, and the obvious place is GitHub, as a number it is willing to publish.
