GitHub says that in the Artificial Analysis Coding Agent Index, Copilot Fusion Max "scored 60, within two points of Claude Code with Opus 5.5 Max" (GitHub changelog). The New Stack's headline turned that into a system that "beats Claude Code for half the API cost" (The New Stack). Those are different sentences, and the gap between them is where a team should do its thinking.
Fusion is generally available in GitHub Copilot as a new entry in the model picker. You don't pick a model. You pick an effort level, and Copilot decides which models run, in what order, for each prompt. It's a good idea with a thin evidence base, and we'd treat it as a cost-control feature first and a quality claim second.
Sixty is not sixty-two
Read GitHub's own wording again. Fusion Max came within two points of Claude Code on Opus 5.5 Max, at about half the average API cost per task, about half the tokens and about 40% less time (changelog). That's a respectable result and a fair pitch. It isn't a win, and the New Stack's own body text says "comparable" under a headline that says "beats". GitHub repeated the claim in its Universe recap, where "half the cost" is the version that travels.
Artificial Analysis publishes the index GitHub cites. It combines three benchmarks, FrontierCode, Terminal-Bench 4.0 and SWE-Atlas-QnA-AA, with equal weight (Artificial Analysis). The default view of that page shows Claude Code on Opus 5.5 Max at 62 and no Fusion entry. Switch on its "Router models" toggle and GitHub Copilot - Copilot Fusion (Max) appears at 60, so the number is real and sits where GitHub said. The same toggle shows Cognition's Devin Fusion CLI, pairing Opus 5.5 Max with GPT-6 Luna, tied with Claude Code at 62, which says routers as a class are catching up, not that GitHub's is the one to beat. We didn't compare the page's cost columns against GitHub's "half the cost" figure, so that part is still GitHub's word.
Three paths behind one menu entry
The docs call Fusion "an intelligent runtime model router and orchestrator" (GitHub Docs). For each prompt it picks one of three execution patterns, and different prompts in one session can take different paths.

Single is one model answering directly. Cascade lets an efficient model draft, then a judge decides whether to accept the draft or escalate to a stronger model. Critique has one model draft while other models review it, and the drafter revises. The effort levels set how aggressive the routing gets: Standard for everyday work, High for substantial tasks, Max for the hardest reasoning.
One detail changed between preview and launch. GitHub's earlier research-preview post described "an independent read-only critic from a different model family" (GitHub blog). The launch changelog says "another model reviews it," while the docs say multiple models critique in parallel and their feedback is aggregated. Our reading is that the critique step grew from one reviewer to several, but GitHub doesn't say so, and the changelog doesn't flag the difference.
Every plan gets it, and you pay per model
The changelog says Fusion is available on all Copilot plans in VS Code, the Copilot app, Copilot CLI and JetBrains IDEs, with more clients coming. You're billed for every model it uses at that model's standard rate, with no separate Fusion charge. Paid plans get a 30% discount on model costs for a limited time, and the docs put the end of that discount later this year (docs).
Two loose ends. The Fusion docs say it is "available with all GitHub Copilot plans." The plans page says that on Free and Student, access to models is through auto model selection only. GitHub doesn't reconcile the two. The docs' per-plan table of effort levels marks availability with icons that came through as empty cells when we read it, so we can't tell you which levels Free and Student seats get. Check your own picker. And because High and Max can call several models, the docs themselves warn that a task may use more AI credits than it would on Standard. Half the cost per task is a claim about Max against Claude Code, not a promise about your credit balance.
The benchmark is GitHub grading GitHub
The earlier HydraFusion post is more candid than the launch. Its tests ran at the same medium reasoning level for every model, used estimated costs under shared pricing assumptions, and compared against Opus 5 and GPT-5.6 Sol. GitHub also says it tuned the routing policy by beam search across the same three benchmarks it reported (GitHub blog).
Look at the shape. One benchmark shows a gain of 4.9 points. The other two show small losses, with costs 36% to 67% lower. That's a cost story with quality held roughly level, which is what the launch copy ended up saying too.
Developers on Hacker News went at the baseline. One commenter wrote that "Opus 5 (in practice) is not a good baseline to compare against" (HN). Another doubted the result, saying "It doesn't take much to beat the frontier in single benchmarks if one puts extra software between the model and the harness" (HN). A Copilot CLI user in the same thread said auto mode "only changes models at the start of a session or after compaction" (HN), and another called auto selection "basically unusable" for them (HN). These are single commenters, not studies. They do show where the skepticism sits.
There is also a billing mismatch to keep in mind. The index and GitHub's comparison use pay-per-token API cost. A developer on a flat Claude Code subscription never sees that number, so "half the cost" lands differently for a solo user than for a team metering API spend. Artificial Analysis itself notes that many users reach these tools through subscriptions rather than pay-per-token. The conclusion is our inference, not a GitHub claim, but it changes who the headline is aimed at.
The one customer voice GitHub supplies is AT&T's Hari Pokhrel, quoted in GitHub's own changelog: "Previously, developers would often choose a more powerful model for a complex task and forget to switch back for everyday activities." That's the honest case for Fusion: it stops people leaving an expensive model on for routine work.
Your policy decides who reads your diff
This is the part we'd read before the benchmark. Fusion only uses models enabled in your enterprise and organization policies. Admins can disable individual models for Fusion without disabling them everywhere, and models excluded by data-residency or FedRAMP policies are left out (docs).
Review by a second model is the design bet, and the preview post says that reviewer comes from a different model family. If that means another vendor, it sees your diff, which is a data-handling decision someone on your team should make on purpose. After a response, you can hover over the effort label to see which models ran.
The limitations section matters too. If Fusion discards a draft, file edits that draft already made aren't undone automatically, so review the diff before committing. Fusion also has no context window of its own: the figure shown is the smallest among its models.
Where we'd put it in a team trial
We'd run Fusion Standard as the default for a Copilot team, and we'd skip Max as a default. Its 60 on the independent index is respectable, but Max is the level that calls the most models and spends the most credits. Standard is where the AT&T story lives and where the routing saves the most. For teams already on Claude Code or Codex, the lock-in question runs the other way: those tools are tied to one vendor's models, while Fusion is a router GitHub controls and can reshuffle. Neither is free of dependency.
Our existing comparisons cover the tools themselves: terminal coding agents, Cursor against Copilot and Windsurf, matching model tiers to tasks and the wider list of coding tools. Fusion changes the cost column in those, not the tool you'd pick. Cursor users have no equivalent verdict yet, and the ToolRank coding assistants board is the place to see how the field currently sorts.
The test that settles it is cheap. Take ten real tickets, run them through Fusion Standard and your current setup, and count accepted changes and credits spent. GitHub's discount runs out later this year, so measure before it does. Then check the Router models view on Artificial Analysis again, since the router entries there are the ones likely to move.







