GitHub Copilot Fusion: Model Routing and Review Max Costs

On October 28, 2026 GitHub made Copilot Fusion generally available and put a Max effort level for Copilot code review into public preview. Fusion is an entry in the model picker that, in GitHub's words, lets Copilot "route and orchestrate which models it uses for you". Max review runs several independent review agents from different providers on one pull request and reconciles their findings. Both are billed on the underlying models or credits rather than at a flat rate, so both are decisions about spend as much as about quality.

This post stays with what GitHub's two changelog entries say. Where GitHub quotes a figure, we quote it and label it GitHub's. Where GitHub gives no figure, such as how many credits a Max review costs, we say so rather than estimate. The practical aim is a sequence an organisation can follow: set the model policies and the review-effort cap first, then let people turn the features on. The credit model these features draw on is the one we set out in our Copilot AI credits cost playbook.

It helps to keep the two announcements apart, because coverage tends to merge them. The first changelog entry is about Copilot Fusion, a routing and orchestration layer for interactive coding in the editor, the Copilot app and the CLI. The second is about Copilot code review, the agent that reviews pull requests on GitHub, and adds a third effort level called Max plus a generally-available approvals feature. The Fusion entry does not mention code review, and the review entry does not mention Fusion. They share a date and a billing model, not a product.

The reason to cover them together is the one an engineering manager will feel first. Each one can raise an organisation's Copilot spend without a single person changing a plan: Fusion because it may route to more expensive models than a developer would have picked by hand, and Max review because GitHub says it does more work on each review than Lite or Balanced. GitHub provides a control for each, and this post is mostly about where those controls are.

GitHub's description is that Fusion combines the multi-model orchestration it had been developing under the name Project HydraFusion with automatic model selection. When a developer chooses Fusion in the model picker, Copilot decides for each prompt which models to use and how they work together, so the developer no longer switches models mid-task or decides which model fits each step. The changelog invites users to watch as Fusion analyses each task and selects a model to complete it, which is the closest it comes to describing what a user sees.

The three workflows GitHub names are the useful part for anyone trying to predict cost. In Single, one model handles the whole task. In Cascade, an efficient model drafts and a quality check either accepts the draft or escalates to a more capable model. In Critique, one model drafts, another reviews, and the original revises. Cascade is the one that saves money when it works and spends more when it does not, because an escalated task has paid for the cheap draft and the expensive redo. Critique always involves at least two model calls. Which workflow Fusion picks for a given prompt is not something the changelog says a user can choose.

The failure case follows directly. A developer who used to run everything on one mid-priced model switches to Fusion for convenience, and a run of hard prompts routes to the most capable and most expensive models in Critique mode. Nothing has gone wrong, and the bill is higher. The admin controls in section 05 exist for exactly this.

Fusion exposes three effort levels, and the changelog defines each by the class of model it prefers rather than by a price. Standard uses versatile models for everyday coding. High uses capable models for challenging tasks. Max, in the changelog's wording, "prioritizes the most capable models for the most demanding tasks and complex reasoning". An admin can set Fusion at any of the three as an organisation's default model, which is the lever that turns a per-developer habit into a policy.

One benchmark claim appears in the Fusion changelog and it should be read as GitHub's own. GitHub says Fusion at Max effort scored 60 on the Artificial Analysis Coding Agent Index, which it describes as within two points of Claude Code with Opus 5.5 Max, at about half the average API cost per task, with roughly half the tokens and about 40% less time per task. The comparison is GitHub's choice of baseline, the cost figure is an average over that benchmark's tasks, and GitHub does not say it has been reproduced independently. It is a reason to try Max on a hard task, not a budget line.

Fusion has no price of its own. GitHub's statement is that users are billed for each model used, at that model's standard rate. Because a single prompt under Cascade or Critique can involve two or more models, a Fusion request can cost more than the same request sent to one model directly, and it can also cost less if Cascade's cheap draft is accepted. The changelog does not publish the acceptance rate, so the direction of the net effect is something an organisation measures on its own usage.

The discount is stated in one sentence: "For a limited time, users on paid Copilot plans will receive a 30% discount on model costs when using Copilot Fusion." Three things are worth noting. It applies to model costs, so the base subscription is untouched. It applies to paid plans, so a free-plan user routing through Fusion pays full rate. And it has no stated end date, which means a budget built on the discounted rate has an unknown expiry. Price the full rate; treat the discount as a variance in your favour until GitHub names a date.

GitHub's changelog is explicit that Fusion only uses models that are enabled in enterprise and organisation model policies. That single sentence is the main cost control. If a model is disabled by policy, Fusion cannot route to it, whatever effort level a developer selects. Enterprise admins can also see which models Fusion chooses from and disable specific models for Fusion without disabling them for everyone, which allows the unusual case of a model being available by hand but not to the router. And admins can set Fusion at a chosen effort level as the default model through Enterprise managed settings.

The order matters. Set the model policy first, so the pool Fusion draws from is the pool you have already priced. Then decide the default effort level, which for most organisations is Standard. Only then publicise Fusion to developers. Reversing that order is the likely failure: Fusion is announced, developers switch, the router reaches the most expensive enabled model, and the policy conversation happens after the first invoice. The same discipline applied to the October 22 default-on changes, which we worked through in our Copilot default-on admin checklist.

The second changelog adds Max as a third effort level for Copilot code review, beside Lite and Balanced, intended for higher-risk changes. GitHub's description of the mechanism is specific: Max "runs several independent review agents across models from different providers", and an aggregation agent then reconciles their findings, resolves disagreements and double-checks accuracy before combining everything into one review. It is in public preview on Copilot Pro, Pro+, Max, Business and Enterprise.

On cost, the changelog gives a direction and no magnitude: "Because Max does more work on each review, it takes longer and uses more AI credits than Lite or Balanced." No multiplier, no per-review figure, no example. That is the single most important thing to know before enabling it, because it means the only way to learn the cost is to run it on a sample of real pull requests and read the credit consumption afterwards. Our credits cost playbook describes how to read that consumption at the organisation level.

Enabling is layered. Max can be selected for a single pull request from the Reviewers bar, or set as the default for a repository, an organisation or an enterprise, with a more specific setting overriding the one above it. The matching control is a maximum review effort level that admins can set, above which levels are unavailable in that enterprise, organisation or repository. Set the cap at Balanced across the organisation and raise it on the handful of repositories where a missed defect is expensive, and the credit exposure is bounded by design rather than by hoping nobody clicks Max on a documentation change.

Approvals reached general availability in the same entry and deserve a separate read, because they change what a review means rather than what it costs. With approvals off, which is the default, every Copilot review includes an approval assessment in the pull request overview comment, stating whether Copilot considers the change ready to merge, and GitHub does not describe it as counting toward required approvals. With approvals on, Copilot can approve the pull request, and GitHub says that approval counts toward the repository's required approvals.

Two scoping rules keep that from becoming a rubber stamp. Repository admins can choose which file paths Copilot is allowed to approve, so a team can let Copilot clear test fixtures and documentation while keeping payment code on human approval only. And the changelog states: "If new commits are pushed after Copilot approves, the approval is dismissed." A fresh review has to be requested for a fresh approval. The failure case is a repository that requires one approval and has approvals on with no path restriction, which means Copilot alone can satisfy the rule. Decide whether that is acceptable per repository, not by default. Where review is being delegated to agents more broadly, the principles in our note on Copilot code review's general availability still apply.

Putting the two changelogs together produces a short sequence. It is the same shape whether the organisation is five developers on Business or five thousand on Enterprise; only the people who hold the settings change. The point of the sequence is that every step that spends is preceded by the step that caps it.

First, audit the model policy and remove anything unpriced. Second, set Fusion's default effort level and, if useful, remove high-cost models from Fusion's pool while leaving them selectable by hand. Third, set the maximum review effort level at the organisation, defaulting to Balanced. Fourth, pick two or three repositories as a pilot: raise their review cap to Max, enable approvals with a path restriction, and run for two weeks. Fifth, read the credit consumption and the Cascade behaviour on the pilot group, then decide the organisation-wide defaults with numbers. The sequence costs a fortnight and prevents the version of events where the first datum is an invoice. Where Copilot is one of several agents an organisation orchestrates, the governance pattern in our Copilot governance and ROI post extends the same idea to tool access.

If you want help running that pilot and turning its numbers into policy, it is part of what our AI transformation engagements cover.