Tools Analysis

Copilot Fusion picks the model for you. Measure what it costs per accepted change

GitHub's router is generally available with a 30% discount until 30 November. Here's what the claims cover and a 20-line script that tests them on your own tasks.

Fine glowing peach and off-white lines streaming into a bright central junction and rejoining

GitHub made Copilot Fusion generally available on 28 October, and the pitch is simple: stop choosing a model per task, pick Fusion and an effort level, and let Copilot route. The changelog puts a number on it. At the Max level, Fusion scored 60 on the Artificial Analysis Coding Agent Index, within two points of Claude Code running Opus 5.5 at max effort, for about half the average API cost per task.

That’s a vendor claim about a benchmark, and the benchmark isn’t your repository. The useful question is whether the router saves you money on the changes you actually ship, and that one you can answer in an afternoon.

What Fusion does

Fusion sits in the model picker next to the individual models. You choose an effort level, and for each prompt it picks the models and an execution pattern. The docs name three patterns:

  • Single: one model does the task, as if you had picked it yourself.
  • Cascade: a cheaper model drafts, a judge inspects the draft and either accepts it or escalates to a stronger model.
  • Critique: one model drafts, several others critique in parallel, and the drafter revises.

The pattern is chosen per prompt, so one session can mix all three. Cascade and critique take longer because they add review calls, and the docs say those are added only when the task warrants them.

The effort levels are Standard (balanced cost, quality and latency, typically one model per task), High (moderate token savings through orchestration, aimed at well-scoped tasks) and Max (frontier capability, for the deepest reasoning). Fusion is available in VS Code, the GitHub Copilot app, Copilot CLI and JetBrains IDEs. Which levels you see depends on your plan: the VS Code 1.144 notes say High and Max are offered on Pro+, Max, Business and Enterprise.

What the benchmark figures say

Artificial Analysis publishes the comparison behind the claim. On its Coding Agent Index v2.0 page , Fusion at max and Claude Code with Opus 5.5 at max read like this:

MeasureCopilot Fusion (max)Claude Code, Opus 5.5 (max)
Index score6062
Cost per task$5.59$11.42
Time per task36.1 minutes1.0 hour
Tokens per task7.34M14.5M
FrontierCode v1.151%56%
Terminal-Bench 4.071%63%
SWE-Atlas-QnA-AA57%66%

The aggregate hides a split. Fusion leads on Terminal-Bench, the shell-heavy tasks, and trails on the other two, most clearly on the code question-answering benchmark. If your day is mostly reading unfamiliar code and answering questions about it, the single score isn’t the number to look at.

Two cautions. The cost column is API cost for each benchmark task, and Copilot bills in AI credits against a plan, so $5.59 isn’t what a Copilot seat will charge you for the same work. And the benchmark tasks are someone else’s tasks: a router that saves half the cost on a benchmark mix may save much less, or nothing, on a codebase where nearly every change is a hard one.

Where it can cost more

Billing is per model used, at that model’s standard rate, with no separate Fusion charge. Until 30 November, paid plans get 30% off model costs when using Fusion. The docs also warn that High and Max can call several models, so one task may burn more AI credits than it would at Standard.

That cuts both ways. A cascade that accepts the cheap draft is a saving. A critique round on a task a single model would have nailed is a surcharge. You can see which models ran by hovering over the effort level beneath a response in VS Code, which is worth doing for your first dozen tasks before you trust the setting.

There’s one more behaviour to know about. According to the docs, if a discarded draft has already changed files, those changes aren’t undone automatically, so review the diff before committing. Fusion also works separately from subagents and doesn’t start them.

Then there’s the discount’s end date. Any comparison you run in November is run at a price that stops applying on 1 December, so compare credits used, not the discounted bill.

Measure it on your own tasks

The test is small: take ten or so real tasks from your backlog, run each once with the model you use today and once with Fusion, and record the credits, the minutes and whether you accepted the change. Accepted means it passed your tests and review without a rewrite. A cheap run you throw away is not cheap.

In Copilot CLI you can pin the level per run, so the comparison is scriptable. These are the commands from the CLI docs :

# one-off run at a fixed effort level (valid tiers: standard, high, max)
copilot --model fusion --fusion-tier standard -p "Rename the OrderDto.Total property to GrandTotal and fix every caller"

# interactive: /model, pick Copilot Fusion, set the level with the left and right arrows
# to make it the default: /config model

Log each run to a CSV with the columns task,mode,credits,minutes,accepted, reading credits from your usage page. Then this script, plain Python with no dependencies, gives you the number that matters, cost and time per accepted change:

import csv, sys
from collections import defaultdict

# usage: python cost_per_accepted.py runs.csv
totals = defaultdict(lambda: {"runs": 0, "accepted": 0, "credits": 0.0, "minutes": 0.0})
with open(sys.argv[1], newline="") as f:
    for row in csv.DictReader(f):
        t = totals[row["mode"]]
        t["runs"] += 1
        t["accepted"] += int(row["accepted"])
        t["credits"] += float(row["credits"])
        t["minutes"] += float(row["minutes"])

print(f"{'mode':<16}{'runs':>5}{'accepted':>9}{'credits/accepted':>18}{'minutes/accepted':>18}")
for mode, t in sorted(totals.items()):
    if t["accepted"] == 0:
        print(f"{mode:<16}{t['runs']:>5}{0:>9}{'n/a':>18}{'n/a':>18}")
        continue
    print(f"{mode:<16}{t['runs']:>5}{t['accepted']:>9}"
          f"{t['credits'] / t['accepted']:>18.2f}{t['minutes'] / t['accepted']:>18.1f}")

Run against a made-up six-row sample, to show the shape of the output (these figures are invented for illustration and say nothing about Fusion):

mode             runs accepted  credits/accepted  minutes/accepted
fusion-standard     3        2              5.25              15.0
pinned-model        3        2              6.00              17.0

Total credits are divided by accepted runs, not by all runs, so a failed attempt raises the cost of the mode that produced it. That’s the point: in the sample both modes accepted two of three runs, so the per-run gap carries straight through to the per-accepted figures.

How to read the result

Ten tasks is a smoke test, not a study. A gap of one accepted change either way is noise. What ten tasks can show is a gross difference: Fusion roughly matching your pinned model at clearly lower credits, or Fusion burning credits on critique rounds for work that never needed them.

Split the tasks by kind before you decide. The case for a router is a mixed workload, where most prompts are easy and a few are hard (that’s reasoning, not something the benchmark shows). If your sample is all hard tasks, expect the escalation path to fire every time and the savings to shrink. If it’s mostly renames, test additions and boilerplate, Standard is the level to try first, and High or Max earn their place only where the Standard run fails.

For teams, admins can restrict the pool: Fusion only uses models allowed by plan and organisation policy, and managed defaults such as "model": "fusion" and "fusionTier": "max" can be set centrally, per the VS Code notes. A policy that quietly removes a model changes what Fusion can route to, so re-run the comparison after any change to the allowed list.

Try it this week, before the discount ends on 30 November: ten tasks, two modes, one CSV, and decide from credits per accepted change.