Copilot Fusion goes generally available: choose effort instead of guessing models

What changed in the 28 October announcement

GitHub announced general availability of Copilot Fusion on 28 October 2026, combining automatic model routing with multi-model orchestration for a request. Copilot users can choose an effort level instead of predicting the best model for every task.

For software teams, the useful decision concerns depth, latency and cost. Start evaluation with Standard, retain code review and measure real tasks before defaulting to the highest effort. This 30 October report uses GitHub's announcement and the 28 October VS Code 1.144 release; the images are official demonstrations, not customer results.

Effort levels have different eligibility

GitHub describes Standard as usually using a single model for everyday work. High and Max can apply additional orchestration to harder requests. Effort expresses a preference, not a correctness guarantee or a fixed number of model calls.

Standard is available across the listed Copilot plans. High and Max require Pro+, Max, Business or Enterprise; Free, Student and Pro users should not assume all three are included. Organization policies can further restrict choices.

Fusion routes only within the models allowed by the plan and applicable policies, including data-residency requirements where relevant. A shared product name does not erase the terms governing underlying models. Administrators should inspect the permitted pool before testing internal code.

One response can involve several model stages

Fusion can select one model, draft and judge before escalating, or request independent critique and revision. These patterns allocate model effort within a request. GitHub explicitly distinguishes this from spawning subagents, so model orchestration should not be presented as several independent agent tasks.

Discarding a draft does not undo file changes already made. Review the diff, executed commands and tests regardless of the final response. Inspect the models used after a response and keep that information when comparing evaluation runs.

Measure cost per accepted task

GitHub says each participating model is billed at its normal rate, with no separate Fusion surcharge. Additional model stages can still raise usage and latency. VS Code advertises a temporary 30% Fusion discount for paid plans through 30 November 2026; verify current billing terms rather than treating that as permanent pricing.

Compare tasks with the same acceptance conditions. A short bug fix and a multi-file refactor are not equivalent units merely because both produce one response. Include human rework, waiting time and total consumption, rather than token volume alone.

A practical evaluation for a small team

A small team could select bugs with existing tests, establish a Standard baseline, then try High or Max on cases requiring deeper reasoning. This is Friday Works' proposed evaluation, not a completed productivity study.

Acceptance should require fixing the defect, preserving existing behavior and producing maintainable changes. Separate the model's completion statement from test evidence and grant only the repository and command access needed. Fusion changes how teams allocate models, but its value still depends on task mix, service plan and data policy. The launch itself proves no particular customer's savings.

Further implementation reading

Friday Works provides implementation information and evaluation steps for business systems.