# GitHub Copilot Fusion Picks Your Model. What It Means for AI Tool Builders

> GitHub Copilot Fusion routes each request to a model it chooses. What the effort levels, cascade and critique workflows mean for your AI product.

- Canonical: https://zeroraised.com/blog/github-copilot-fusion-model-router
- Published: 2026-11-02T09:26:40Z
- Author: ZeroRaised Team (https://zeroraised.com/blog/authors/zeroraised)
- Publisher: ZeroRaised (https://zeroraised.com/)
- Section: Growth
- Tags: artificial-intelligence, developer-tools, saas, comparison

GitHub Copilot Fusion is now generally available, and its main idea is simple: the developer stops choosing a model and Copilot chooses for them. GitHub says Fusion routes and orchestrates which models it uses, combining Project HydraFusion's multi-model orchestration with Copilot auto model selection ([GitHub changelog](https://github.blog/changelog/2026-10-28-route-and-orchestrate-models-with-github-copilot-fusion/)).

**TL;DR**

- Copilot Fusion is generally available and routes each request across models chosen by GitHub.
- It sells three effort levels, Standard, High and Max, instead of a flat model list.
- Single, Cascade and Critique are reusable orchestration patterns, not just Copilot settings.
- GitHub says Fusion Max reached 60 on the Artificial Analysis Coding Agent Index, within two points of Claude Code with Opus 5.5 Max, at about half the average API cost per task.
- Billing runs per model at standard rates, with a temporary 30% discount for paid plans.

**Disclosure:** ZeroRaised publishes this analysis and is a launch site for bootstrapped products. Facts come from the linked sources as checked on 2 Nov 2026; ZeroRaised has no commercial relationship with the companies named.

**Model routing** is the practice of choosing which model handles a request or a step, based on the task, the cost budget or the result of an earlier attempt. **Copilot Fusion** is GitHub's implementation: a mode where Copilot makes that choice and orchestrates the work across models.

## What is GitHub Copilot Fusion?

Fusion became generally available on 28 October 2026. Choosing Copilot Fusion means Copilot routes and orchestrates which models it uses, rather than waiting for the developer to select one ([GitHub changelog](https://github.blog/changelog/2026-10-28-route-and-orchestrate-models-with-github-copilot-fusion/)). It is available on all Copilot plans in VS Code, the GitHub Copilot app, Copilot CLI and JetBrains IDEs ([GitHub docs](https://docs.github.com/en/copilot/concepts/models/copilot-fusion)).

The practical change is who carries the decision. In a fixed-model product, the user reads a menu and guesses. In a routed product, the vendor owns the guess and the user owns the outcome. The [LLM routing guide](https://zeroraised.com/blog/what-is-llm-routing) covers the underlying pattern.

## What do the effort levels change?

GitHub frames the choice as effort, not as model names. Fusion Standard uses versatile models for everyday coding, Fusion High uses capable models for deeper reasoning, and Fusion Max uses the most capable models ([GitHub docs](https://docs.github.com/en/copilot/concepts/models/copilot-fusion)).

That is a useful interface decision. It also lets the vendor swap models without rewriting the marketing. The cost is transparency: an effort dial hides the price per step, so pair it with a visible usage page and a cap.

## What are Single, Cascade and Critique?

Fusion offers three workflows ([GitHub docs](https://docs.github.com/en/copilot/concepts/models/copilot-fusion)):

- **Single:** one model solves the request.
- **Cascade:** an efficient model drafts, then a quality check either accepts the draft or escalates it to a stronger model.
- **Critique:** one model drafts, another reviews, and the original model revises.

Cascade is a cost pattern: you pay the strong model only when the cheap draft fails a check you defined. Critique is an accuracy pattern: you pay for a second opinion because a second model may catch what the first one missed. Both can be built in application code on top of the primitives in the [function calling guide](https://zeroraised.com/blog/what-is-function-calling). The hard part is the check. A cascade with a vague pass condition escalates too often and costs more than a single strong model, which is why you test it on real cases with an [eval suite](https://zeroraised.com/blog/how-to-evaluate-llm-outputs).

## What does GitHub claim about quality and cost?

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, at about half the average API cost per task, about half as many tokens and about 40% less time per task ([GitHub changelog](https://github.blog/changelog/2026-10-28-route-and-orchestrate-models-with-github-copilot-fusion/)).

Treat that as a vendor's summary of a benchmark, not a guarantee for your workload. The claim is plausible because it is the economic argument for routing: a mix of cheap and strong models can land close to a strong model's quality at a lower blended cost. Whether it holds depends on how often the cheap path is good enough.

Hari Pokhrel, a Principal Software Engineer at AT&T, described the user problem: "Previously, developers would often choose a more powerful model for a complex task and forget to switch back for everyday activities. Copilot Fusion eliminates that friction, optimizing model selection without requiring developers to manage it themselves" ([GitHub changelog](https://github.blog/changelog/2026-10-28-route-and-orchestrate-models-with-github-copilot-fusion/)). That forgetting is likely in any product with a model picker, and someone pays for it.

## Why is routing becoming table stakes?

Our view: a model menu used to be a differentiator. Now it is a support burden. Every added model multiplies the ways a user can pick badly, and the vendor absorbs the cost of the good pick and the blame for the bad one. Fusion removes the decision from the user and makes it a system behaviour. Once a large vendor ships that as a default, a product that still asks the user to choose looks unfinished.

## How does Fusion bill, and what does that mean for pricing?

GitHub bills each model Fusion uses at that model's standard rate. For a limited time, paid Copilot plans get a 30% discount on model costs, and GitHub gives no end date ([GitHub changelog](https://github.blog/changelog/2026-10-28-route-and-orchestrate-models-with-github-copilot-fusion/)).

Two lessons follow. Routing makes your cost of goods variable per request, so margin depends on the router's choices; measure cost per successful task rather than cost per token. And a discount with no end date is a promotion, not a price, so do not set a permanent plan price against it. The [AI pricing guide](https://zeroraised.com/blog/how-to-price-an-ai-product) covers packaging, and the [HubSpot spend cap playbook](https://zeroraised.com/blog/hubspot-ai-spend-caps) shows how to put a visible ceiling on an unpredictable bill.

## What can admins control?

Admins can restrict Fusion to models enabled in enterprise or organisation policies, disable a model for Fusion only, and set Fusion as the default ([GitHub docs](https://docs.github.com/en/copilot/concepts/models/copilot-fusion)).

The "disable for Fusion only" detail is worth copying. It separates the policy for automatic choice from the policy for direct use, so an organisation can keep an expensive model for a deliberate workflow while keeping it out of the router's reach.

## What this means for bootstrapped founders

1. Add a router before you add another model to the picker.
2. Use cascade for cost and critique for accuracy, and test the check that decides escalation.
3. Show usage and a cap, even if the router is invisible.
4. Log which model handled each step so you can explain a bill.
5. Measure cost per successful task, not cost per token.
6. Treat launch discounts as temporary when you set prices.

The [LLM cost guide](https://zeroraised.com/blog/how-to-reduce-llm-costs) covers the wider levers, and the [launch guide for AI apps](https://zeroraised.com/blog/how-to-launch-an-ai-app) covers the packaging decisions around them. None of this requires a platform feature, only a decision rule and a quality check.

## Where ZeroRaised fits

ZeroRaised is a launch and discovery site for products built without institutional venture capital or accelerator equity. If you have an AI product people can try, [submit it here](https://zeroraised.com/submit) and describe how it chooses models and what it costs.

The [ZeroRaised newsletter](https://zeroraised.com/newsletter) carries new analysis like this. We make no promise of traffic or results.

## Sources

- [GitHub: route and orchestrate models with Copilot Fusion](https://github.blog/changelog/2026-10-28-route-and-orchestrate-models-with-github-copilot-fusion/)
- [GitHub docs: Copilot Fusion](https://docs.github.com/en/copilot/concepts/models/copilot-fusion)

## Frequently asked questions

### What is GitHub Copilot Fusion?

Copilot Fusion is a generally available Copilot mode that routes and orchestrates which models it uses for a request. It combines Project HydraFusion's multi-model orchestration with Copilot auto model selection, so the developer does not have to choose a model for every task.

### What are the Fusion effort levels?

There are three. Fusion Standard uses versatile models for everyday coding, Fusion High uses capable models for deeper reasoning and Fusion Max uses the most capable models. The level sets the quality and cost envelope rather than naming a single model.

### What is the difference between Cascade and Critique?

Cascade has an efficient model draft the work, then a quality check either accepts the draft or escalates it to a stronger model. Critique has one model draft, another model review it, and the original model revise the output. Cascade is mainly a cost pattern; critique is mainly an accuracy pattern.

### How is Copilot Fusion billed?

GitHub bills each model Fusion uses at that model's standard rate. For a limited time, paid Copilot plans get a 30% discount on model costs. GitHub did not give an end date for the discount, so treat it as temporary rather than as part of your long-term margin.

### Can an organisation control which models Fusion uses?

Yes. Admins can restrict Fusion to models enabled in enterprise or organisation policies, disable a model for Fusion only, and set Fusion as the default. That separation lets a team keep a model available for a specific workflow while keeping it out of automatic routing.