Copilot Fusion Makes Model Choice the Platform's Problem

On 2026-10-28 GitHub made Copilot Fusion generally available, and the interesting part is not the feature. It is who now makes a decision that used to belong to you. Fusion looks at a prompt, picks which models handle it, runs them in a single, cascade or critique workflow, and bills every model it touches. The developer typed a request. The platform chose the engine, ran a second engine to check the first, and collected on both.

That is a small product announcement sitting on top of a large shift. For three years, model vendors have competed for developer loyalty with brand, benchmark charts and a favourite option in a dropdown. A router makes the dropdown disappear. If the IDE picks the model, the model's name stops being a reason to choose it, and the party that sets the price the user sees is the party that owns the screen.

What GitHub actually shipped

Start with the facts, because the commentary around launches drifts quickly. According to the GitHub changelog entry from 2026-10-28, Copilot Fusion routes and orchestrates models. It does not add one more model to the picker. It sits in front of the models and decides which of them see your prompt and in what order.

Coverage from Silicon Report lists the shape of it. There are three workflows: single, cascade and critique. There are three effort levels: Standard, High and Max. It is available on all Copilot plans. That last detail matters more than it looks. A routing feature gated to an enterprise tier is a premium add on. A routing feature on every plan, including the free one, is a default, and defaults are where platforms win.

GitHub also says paid plans get a 30% discount on model costs, for a limited time. Combine that with the billing model, where every model Fusion touches is charged, and you get the commercial logic in one sentence: the platform is pricing the bundle, not the parts.

Single, cascade, critique: what the three workflows mean

The sources we have name the workflows and do not publish their internals, so treat what follows as our reading of the standard patterns behind those names, not as GitHub's specification. If you build on Fusion, test the behaviour rather than trusting our description.

Single is the plain case. One model gets the prompt and answers. The only decision the router makes is which model, and for a short question that is the whole job. It is also the workflow where routing is least visible to the user, which makes it the one that quietly changes loyalty. Nobody notices that a different vendor answered their autocomplete.

Cascade starts cheap and escalates. A smaller model tries the task first. If a check says the attempt is good enough, the answer ships. If not, a stronger model takes over. The economics rest on a skewed distribution of work: most requests in a coding session are routine, and a few are hard, and you only want to pay frontier prices for the few. We wrote about the mechanics, and the three ways cascades quietly degrade quality, in the inference cost playbook on routing to the smallest model that clears the bar.

Critique separates the writer from the reviewer. One model produces an answer, another model attacks it, and the result is revised or accepted. It costs more tokens than a single pass and buys a second opinion from something with different blind spots. The reason it works is the same reason code review works: an author grading their own work is biased toward approval. That argument, and the guardrails around it, are the subject of our piece on the maker checker pattern.

Effort levels sit on top of this. Standard, High and Max read as a dial for how much work the router is allowed to spend: more models, more rounds, more tokens. That dial is where the money gets decided, and it is the part of the product to watch on your invoice.

The numbers, and who is reporting them

GitHub's changelog says Copilot Fusion Max scored 60, within two points of Claude Code with Opus 5.5 Max. It adds that Fusion Max did this for about half the cost and tokens and in 40% less time. All of that is vendor reported. GitHub ran the comparison, chose the benchmark, and published the result in a post whose purpose is to launch the product.

None of that makes the claim false. Vendors usually report numbers that are true for the setup they chose. It does mean the claim answers a narrower question than the headline suggests. The question it answers is whether a router can land close to the best single agent on one evaluation at lower cost. It does not tell you whether it lands close on your repository, your languages or your review standards.

For an independent anchor, there is Artificial Analysis and its Coding Agent Index. In that write up, Claude Code with Opus 5.5 (max) scores 62 and Carbon with Antigravity CLI scores 59. We cannot tell from our sources whether GitHub's 60 and the index's 62 come from the same test, so we do not stack them on one chart. What the independent figure does give you is scale. The top coding agents on that index sit within a few points of each other, so a gap of two points is the size of the difference between neighbours, not between tiers.

We have argued before that public coding scores are a weak guide to your own results, and the contamination problem in coding benchmarks is why. A router makes that worse in one specific way. It adds a moving part whose behaviour depends on the prompts it sees, so the aggregate score hides a spread. Fusion might be excellent on the half of your work that is routine and mediocre on the half that is not, and a single number averages the two into something that sounds fine.

Why a router loosens a model vendor's grip

Model vendors have three sources of stickiness. Habit: you use the model you know. Integration: your prompts, tools and evaluations are tuned to one model's quirks. Brand: you believe, sometimes correctly, that one lab is ahead. A router attacks all three at once.

Habit goes first. When the person at the keyboard never chooses, there is nothing to become a habit. Integration goes next, at least for the surface that the platform controls. If Fusion accepts a prompt and decides internally who handles it, then the prompt has to work across whatever sits behind the router, which pushes everyone toward the common denominator of what every model does well. Brand erodes last, because it survives as reputation, but it loses its power to settle a purchase. You cannot choose the model you trust if the product does not offer the choice.

This is not a new pattern. Marketplaces and aggregators have done it to suppliers for decades: the storefront that owns the customer relationship gets to treat the suppliers as interchangeable, and the suppliers compete on price to be included. Hotels know it. Airlines know it. Model vendors are now finding out that inference is a commodity more quickly than their pricing assumed, which is a thread we followed in our look at the end of the single model era.

The counterpoint deserves airtime. Model vendors are not passive. They ship their own agents, as the Claude Code entry in the comparisons above shows, precisely so that the customer relationship stays with them. The independent index scores agents, meaning a model plus its harness, and that is a tell. The competition has moved up the stack from model against model to agent against agent, and Fusion is a platform entering that contest with a router as its entry.

Where the margin goes

Follow the money through one request. You send a prompt. Fusion routes it, perhaps to a cheaper model first and a stronger one after. Per the launch details, each model that touches the request is billed. The platform is positioned between your payment and the vendors' meters, and a position like that tends to be monetised in one of three ways: a markup on the underlying price, a subscription that bundles usage, or volume deals with vendors that lower the platform's cost below what an individual customer could get.

The limited time 30% discount on model costs for paid plans is the opening move. A discount at launch is rarely about generosity. It trains behaviour. Teams that route through Fusion for the discount build workflows around it, store their configuration there and teach their engineers to expect it, and by the time the discount ends the switching cost has replaced the price cut as the reason to stay. We cannot see GitHub's margin and will not pretend to. The structure is visible, though, and the structure favours whoever owns the router.

This ties into a budget problem many engineering leaders are already living with. Metered token billing broke seat based forecasting, a story told in why token pricing is breaking AI coding budgets. A router that spawns several model calls per prompt adds a multiplier to that. Standard, High and Max effort levels make the multiplier explicit, which is honest, and also mean a developer can raise their own cost with a dropdown. The way to judge that trade is cost per solved task, the metric in price per token is the wrong number, and the open weights option has its own catch, covered in the Mistral Large 4 license.

What to assume if you build products

If you ship software that calls models, here is the working assumption we would adopt this quarter: routing is becoming a platform feature. It will exist in the IDE, in the cloud provider's gateway and in the agent framework you use. That makes routing a poor place to build a moat, and a fine place to build a feature if you need one now, because you will probably swap it for the platform's version later.

Three consequences follow. First, do not hardcode a single model into your product's identity. Wrap model calls behind an interface you control so that the model behind them is a configuration value. Second, expect your customers to bring their own router. If a buyer's coding platform decides which model answers, your product's prompts will run on models you did not pick, and you need to know they still work. Third, price with the knowledge that your inference costs will keep falling relative to your list price, and that the cost advantage from clever routing will not stay private for long.

The more interesting question is what stays yours when routing is free. The answer is the part of the system that a router cannot see from the outside.

What a router cannot copy: evals, data, workflow

A platform router knows the prompt and the model responses. It does not know what a correct answer means in your business. That gap is where products survive, and it breaks into three assets.

Evals are the first. A router can only choose well if something tells it what good looks like. Your evaluation set, with labelled cases from your own domain and a scoring method you have calibrated against human judgement, is the measuring instrument that decides whether a cheaper model is acceptable. The discipline is covered in eval driven development and why evals are the new unit tests, and Fusion makes it more valuable, not less. Every time a platform swaps the model behind a feature, your evals are the only thing that tells you whether the feature still works.

Data is the second. A router cannot see your private corpus, your support history, your internal conventions or the corrections your reviewers made last quarter. Teams that capture those signals, in a form that can retrieve context or fine tune a small model, hold an advantage that grows with use. A general router is only as informed as the prompt it receives. A product with proprietary context sends a better prompt.

Workflow is the third. The router decides which model handles a step. It does not decide what the steps are, where a human approves, which tools an agent may call or what happens when a check fails. Those choices encode how your customers actually work. A team that has designed a good loop, with the right gates in the right places, gains the same from a better model and a worse one, which is the position you want when models are interchangeable.

Build the cascade pattern yourself

You do not need Fusion to use these ideas, and for features that carry your product's core logic you probably should not hand them over. The cascade has four parts: a cheap first attempt, a verifier, an escalation rule and a log. Here is a sketch in TypeScript. The point is the shape, not the library.

async function cascade(task: Task): Promise<Result> {
  const attempt = await run(CHEAP_MODEL, task);
  const verdict = await verify(attempt, task); // tests, schema, rubric

  if (verdict.passed && verdict.confidence >= THRESHOLD) {
    return record({ task, attempt, escalated: false });
  }

  const retry = await run(STRONG_MODEL, task, { hint: verdict.failures });
  return record({ task, attempt: retry, escalated: true });
}

Most of the quality lives in verify. A verifier that runs your test suite, validates a schema or checks citations against a source gives you a signal the cheap model cannot fake. A verifier that asks the same cheap model whether it did a good job gives you nothing, because it shares the blind spot that caused the error. If you cannot write a verifier for a task, that task is a poor candidate for a cascade, and sending it straight to the strong model is the cheaper mistake.

The log matters as much as the logic. Record whether each request escalated, what the verifier said and how it ended. After a few weeks you have an escalation rate, which is the number that tells you whether the cascade is saving money. If almost nothing escalates, check that the verifier is not too lenient. If almost everything escalates, the cheap model is doing no useful work and you are paying for two calls where one would do.

Set the confidence threshold with data, not intuition. Sample a few hundred past requests, label the outcomes by hand, and pick the threshold where wrong answers that slip through fall to a level you can live with. Then keep sampling. Thresholds drift as inputs change and as vendors update the models behind the same name.

Build the critique pattern yourself

Critique is where teams most often fool themselves, because it feels rigorous while it is cheap to get wrong. A reviewer that shares the maker's model, prompt and context is closer to a mirror than a second pair of eyes.

async function critique(task: Task): Promise<Result> {
  const draft = await run(MAKER_MODEL, task);
  const review = await run(CHECKER_MODEL, reviewPrompt(task, draft));

  if (review.approved) return record({ task, draft, rounds: 1 });

  const revised = await run(MAKER_MODEL, task, { feedback: review.issues });
  return record({ task, draft: revised, rounds: 2 });
}

Three choices decide whether this earns its cost. Use a checker from a different model family where you can, so the failure modes differ. Give the checker an adversarial brief: find the bug, name the missing case, say what you would reject. Do not ask it whether the draft is good. And cap the rounds. A critique loop with no ceiling is a way to spend tokens on politeness, and in our experience a second round delivers most of the available gain.

Reserve critique for work where a mistake is expensive and hard to see: security sensitive code, financial calculations, changes to shared infrastructure. For a rename across five files it is overhead. The same logic applies to Fusion's effort levels. Max is a spending decision, and it should be made per task type, not left as everyone's default.

Where the platform approach is the right call

None of this is an argument against using Fusion. For an engineering team's day to day editor work, handing routing to the platform is sensible. The tasks are varied, the feedback is immediate because a developer sees the diff, and the cost of a mediocre answer is a retry. Building your own router for that is a distraction from shipping.

The split we recommend is by who owns the consequence. If the output goes to a developer who reviews it, let the platform route. If the output goes to a customer, a regulator or a production system, own the routing, the verifier and the log, because you will be the one explaining what happened. That boundary also tells you which evals to write first.

Risks to watch in a routed world

Opacity is the first. When a router chooses, you need to know what it chose, and the documentation we reviewed does not say how much of that is exposed to the user. Ask for the model trace per request. If you cannot see it, you cannot debug a regression or explain a bill.

Silent change is the second. A router's behaviour can shift without any change on your side: a new model enters the pool, a threshold moves, an old model leaves. Quality regressions arrive with no commit to blame. Pin an eval run to a schedule so that the first sign of drift is a failing check, not a customer complaint.

Cost surprise is the third. Billing every model touched means a single prompt can fan out into several line items, and the effort level controls how many. The 30% discount softens the first invoice and hides the steady state. Model your spend at the undiscounted price before you commit a team to a workflow.

Concentration is the fourth. If your editor, your router and your repository host are the same company, a pricing change or an outage reaches all three at once. That is a legitimate reason to keep a thin abstraction of your own around any model call that matters, and to keep a second path tested.

What to do this week

Here is a short list a team can finish in five working days.

On Monday, inventory every place your product or your engineering workflow calls a model, and write down which model, at what cost per month, for what task. Most teams discover calls they forgot, and a few discover that a premium model is doing work a smaller one could handle.

On Tuesday, put an interface between your code and each model call. A function named after the task, not the vendor, with the model as configuration. This is an hour of work per integration and it is the single change that keeps you free to adopt, or refuse, a router.

On Wednesday, pick your most expensive routine task and write twenty evaluation cases for it from real examples. Include the awkward ones. Score a cheap model and a strong model against them. If the gap is small, you have found your first cascade candidate. If it is large, you have learned where not to economise.

On Thursday, try Fusion on a real piece of work at Standard effort, then again at High, and compare the diff quality and the billed cost line by line. You are not testing whether GitHub's vendor reported claim is true in general. You are testing whether it holds on your code.

On Friday, decide the boundary. Write down which categories of work go to the platform router and which stay under your control, using the rule about who owns the consequence. Put the decision in a document your team can find, and set a review date for when the 30% discount ends.

A router is a good servant and a dangerous landlord. Use the one GitHub built for the work where a human checks the result, and build the evals, the data capture and the workflow that make the rest of your product hard to route around.