GitHub’s new model router is the most transparent one a major vendor has shipped, and that is exactly why its bill deserves a closer read than its benchmark. Copilot Fusion, announced at GitHub Universe on October 28, sits in the Copilot model picker like any other model. Pick it, and it decides which model (or several) handles each request. GitHub’s Universe post says it “evaluates what a task needs across reasoning, code generation, debugging, and tool use,” then “chooses how to execute across one or more models.”
The headline claim is GitHub’s own: on the Artificial Analysis Coding Agent Index, “Fusion Max scored within two points of Opus 5.5 Max,” at “half the cost and 40% less time per task.” Satya Nadella’s version on LinkedIn, per The Next Web, stretches that to up to 77% lower cost. Treat both as vendor numbers on a vendor-chosen configuration until you have run your own tasks through it.
What Fusion does on each request
The Fusion documentation is more specific than the launch post. Fusion runs one of three execution patterns:
- Single: one model does the task.
- Cascade: a cheaper model drafts, a judge accepts the draft or escalates to a stronger model.
- Critique: one model drafts, several models critique in parallel, and the first model revises.
It comes in levels. Fusion Standard picks one model per task and is included on every plan, Free included. Fusion High and Fusion Max are limited to Pro+, Max, Business and Enterprise; Max aims at the hardest reasoning and can pull in several models per request. It is generally available in VS Code, Copilot CLI, the GitHub Copilot app and JetBrains IDEs.
This differs from the opaque routers this site covered when Sakana’s Fugu declined to name the models it routes to. Fusion shows each step’s progress and the model in use while it runs, and you can hover over the effort level under a response to see which models were used. That is the right design. It also means the questions below are answerable, which is more than most routers allow.
Five things to check before your team switches
1. Your bill is the sum of every model Fusion called
There is no Fusion surcharge. The docs say you are billed for each model used at that model’s standard rate. On Standard that is roughly one model per task. On Max, a Critique pass is a draft, several parallel reviews and a revision, each priced separately. The docs say plainly that High and Max “may use more” credits than Standard. “Half the cost of Opus 5.5 Max” is an average on GitHub’s benchmark mix, not a ceiling on any given request.
2. The November bill is discounted; December’s is not
Through November 30, 2026, paid plans get a 30% discount on model costs used through Fusion, per the same documentation. A team that pilots Fusion this month and extrapolates the invoice will undercount steady-state spend by that margin. Run the pilot, then divide the November model cost by 0.7 before anyone writes a budget line.
3. Enterprise just moved to pure consumption
From October 28, GitHub Enterprise customers can use every Copilot feature without a separate Copilot subscription and “pay for the AI credits you use,” through GitHub Sales for now with self-serve “coming soon” (GitHub). Existing Business and Enterprise customers can stay on their plans. GitHub’s billing documentation sets one AI credit at $0.01, gives Business seats 1,900 pooled credits a month and Enterprise seats 3,900, and bills usage beyond the pool at published per-credit rates. Inline completions and next edit suggestions stay unmetered. The control that matters is the budget setting “Stop usage when budget limit is reached.” Without it, a Max-heavy team overruns the pool silently. Decide whether to move to consumption after you have a month of real Fusion usage data, not before.
4. A discarded draft can still leave edits in your files
This is the line in the docs most teams will miss: if Fusion discards a draft, file edits that draft already made are not automatically undone. Cascade and Critique both produce drafts that may be thrown away. Review the working tree, not just the final response, before you commit. Agent sessions should run on a branch with diff review as a gate, which is the same discipline the site recommended for tracing what an agent actually did rather than trusting its summary.
5. Your model policies now govern the router
Fusion will not use models that are outside your plan, excluded by an administrator, excluded by data-residency or FedRAMP policies, or restricted as Evaluation models. Enterprise admins can set which models Fusion may draw on. That is useful, and it also means the router is only as good as the pool you leave it. Lock the pool down too far and Fusion Max is a slower, pricier way to call one model. Audit model policies before rollout, and note that the docs say both the execution patterns and the model pool may change over time. Fusion also does not start subagents; it works separately from them.
Why GitHub is pushing review at the same time
The router is half the story. GitHub’s Octoverse 2026 report says that by September, “more than 40% of pull requests on GitHub started with an agent’s first draft, up from 17% in March,” about 110 million in September alone. GitHub calls its count “a floor, since not all agent use may be detected.” Agent pull requests merged within two weeks at 90%, against about 86% for the comparison group.
What the report does not include is any agent-specific data on reverts, defects or security outcomes. Merge rate measures whether a change got accepted, not whether it was right. GitHub launched Copilot code review Max the same day, claiming the highest F1 score on ReviewBench for high-severity issues. The pairing tells you where the bottleneck has moved: drafting code is cheap and routed, and review is the scarce step.
Two practical consequences. First, the same report says 61% of Copilot users who choose their own model already use more than one, so Fusion is automating a habit, not inventing one. Second, if Fusion makes drafting cheaper, your review queue gets longer. Measure review time per merged pull request alongside the credit bill. A router that halves model cost but doubles reviewer hours has not saved anything.
The way to evaluate Fusion is the way to evaluate any model claim: score it on your own tasks, not the vendor’s index. Pick 30 to 50 real tickets, run them on Fusion Standard, Fusion Max and the single model you use today (for many teams that is Sonnet 5.5 at a sensible effort setting), and record credits used, wall-clock time, edits left behind by discarded drafts, and reviewer minutes per accepted change. That spreadsheet, not the 77% figure, is what goes in front of whoever signs the consumption contract.