Skip to content

Analysis / Development and agents

Copilot Fusion selects and combines AI coding models

Manually selecting an AI model for every coding task takes time and can lead to unnecessary spending on powerful models. GitHub Copilot Fusion handles model selection, although developers still need to choose an appropriate effort level.

Contrast 3DPublished 5 min read

3D still life of interconnected white ceramic modules on a black background, with a violet glass prism representing the selection and coordination of artificial intelligence models.
Conceptual illustration generated with AI. Not a screenshot or a photograph.

Copilot Fusion is worth considering for everyday development work where choosing a specific model is unnecessary. It selects and coordinates models automatically, while developers decide how much effort each task deserves. For a small team, Standard is a sensible starting point, High suits more demanding problems, and Max should be reserved for work that genuinely needs deeper reasoning.

GitHub made Fusion generally available on 28 October 2026 at GitHub Universe. According to the official GitHub changelog, it is available across all Copilot plans, with support for Visual Studio Code, the GitHub Copilot app, Copilot CLI and JetBrains IDEs.

Fusion removes the need to select a model for every task

A common approach to AI-assisted programming is to choose a model before starting work and switch to a more capable option when the problem becomes difficult.

Fusion takes a different approach. Developers select Copilot Fusion from the model picker, and GitHub decides which model should handle the request and whether additional models should contribute.

The developer still controls the effort level. What changes is the need to manage individual model choices throughout the task.

This can be useful when switching regularly between small code changes, debugging and feature development. It also reduces the temptation to leave an expensive model selected after finishing demanding work.

Single, Cascade and Critique use different execution patterns

GitHub has described three execution patterns that Fusion can select according to the task.

  • Single: one model handles the request directly, without introducing additional model reviews.
  • Cascade: an efficient model prepares an initial solution. A quality check determines whether to accept that output or escalate the work to a stronger model.
  • Critique: a model produces an initial solution, which other models review. The original model can then revise its work using their feedback.

These patterns are documented in the GitHub Fusion announcement.

Cascade offers an interesting way to balance capability and cost. A straightforward request may be resolved without involving a more expensive model, although an escalated request can consume resources across several models.

Critique provides another opportunity to identify weaknesses before returning the final result. However, having models review each other does not guarantee correct code.

Developers choose the effort level, while Fusion chooses the execution pattern.

Choose Standard, High or Max according to the work

Fusion offers three effort levels. They influence the models and capabilities the system prioritises, but none represents a fixed price per request.

CriterionWhat to check
StandardA sensible default for everyday coding and clearly defined tasks.
HighWorth testing for challenging debugging and related changes across files.
MaxBest reserved for particularly demanding tasks where deeper analysis could justify additional consumption.
Quality requirementsValidate outputs through testing and review regardless of effort level.
SpendingInspect the models used and the actual cost of representative tasks.
Fixed modelPrefer explicit selection when evaluating consistent model behaviour or controlling which model handles the work.

For a small development team, making Standard the normal starting point keeps the decision straightforward. Developers can increase effort when a task requires more demanding reasoning.

Using Max for everything would undermine much of the potential cost benefit of automatic model selection.

Fusion has no separate fee but costs can vary

There is no dedicated subscription charge for Fusion itself. Each model involved is billed at its normal rate, so a request involving several models may cost more than a straightforward single-model execution.

GitHub is offering a temporary 30% discount on model costs when paid Copilot subscribers use Fusion, according to its release announcement.

That promotion should not be treated as a permanent assumption when estimating future spending.

GitHub also reports that Fusion Max finished within 2 points of Claude Code with Opus 5.5 Max on the Artificial Analysis Coding Agent Index, at roughly half the API cost per task and with 40% less time required.

Those figures come from GitHub's own Universe presentation. They describe the company's benchmark comparison, not a guarantee of lower costs or better results in every development environment.

Teams should compare representative tasks from their own projects rather than build budgets around promotional benchmarks.

Our article on published AI agent pricing and operating costs explores the wider budgeting problem.

Keep a fixed model when consistency or data requirements matter

Automatic selection makes sense when different models could reasonably deliver an acceptable result.

A fixed model may be preferable when comparing development tools, investigating repeatable behaviour or working under specific quality and data-handling requirements.

For example, changing the model during an evaluation introduces another variable. It becomes harder to establish whether a difference comes from the model or the surrounding tool.

This is closely related to why the same model behaves differently across agent systems.

GitHub also allows administrators to control which models Fusion can use through organisational model policies. They can restrict the available models and configure Fusion as the default, as described in the official announcement.

A practical team policy should first establish which models are permitted, then decide when automatic selection is appropriate. Letting Fusion choose does not mean abandoning control over the models available to it.

Copilot projects coordinates agents across repositories

GitHub also announced Copilot projects, a separate feature designed to coordinate agents working in parallel across multiple repositories through the Copilot app.

According to the GitHub Universe announcement, agents can continue working in the cloud even after the developer closes their laptop.

This allows related tasks to be organised and monitored from a common workspace. It also creates a need to review the results and ensure that changes across repositories remain compatible.

Before delegating larger projects, teams should consider the capability and reliability of coding agents alongside the cost of running them.

This week, test Fusion Standard on everyday coding tasks, compare its consumption with a fixed model and define when High or Max is justified. If you are introducing agents into a development workflow or need to manage their costs, tell Contrast 3D which process you want to automate.

Sources

Checked on November 1, 2026

All articles