GitHub Makes Copilot Fusion GA With Three Routing Patterns, Three Effort Levels and Per-Model Billing

GitHub announced on October 28 that Copilot Fusion is generally available. This November 1 weekend technical issue keeps the original October 28 date explicit. Selecting Fusion chooses a model-routing and orchestration system rather than one fixed model. GitHub says the feature combines Project HydraFusion's multi-model orchestration with its automatic model selection. The system decides which enabled models to use for a task and how they work together. Availability must still be read with the stated client list and enterprise model policies, not as a promise that every Copilot surface now offers the same selector.

The user chooses Copilot Fusion in the model picker and then selects an effort level. Standard favors versatile models for everyday coding; High favors more capable models for difficult tasks; Max aims at the most demanding reasoning and development work. These are product effort levels, not immutable lists of model names. Administrators retain control over the candidate models: Fusion uses only models enabled by enterprise and organization policies. An administrator can set a model's effective policy state for Fusion or disable it inside Fusion without disabling it for all other Copilot uses. That policy boundary affects both capability and the cost of a real task.

GitHub outlines three possible execution patterns. In Single, one model handles the work directly. In Cascade, an efficient model drafts and a quality check decides whether to accept that answer or escalate to a stronger model for a fresh attempt. In Critique, one model drafts, another read-only critic assesses it, and the original model revises when required. These are alternatives the orchestrator may choose, not three mandatory steps for every prompt. A developer cannot infer the exact internal path or total model usage from the marketing names alone, and billing should be checked against the actual task record.

The vendor's headline performance comparison has a narrow denominator. GitHub reports that Copilot Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, within two points of Claude Code with Opus 5.5 Max. In that benchmark, it reports about half the average API cost per task, about half as many tokens, and about 40% less time per task relative to that comparison. This publication did not rerun the benchmark. The figures refer to the Max configuration and the index's tasks; they are not a universal speed or accuracy claim for every repository, policy configuration, or effort setting. “Average API cost per task” is different from a fixed price per request or the price of a Copilot subscription.

Actual Fusion billing is described separately. GitHub says each model used by a task is billed at that model's standard rate. For a limited time, paid Copilot plans receive a 30% discount on model costs when using Fusion. The announcement does not promise that discount forever. Nor does a benchmark showing roughly half the cost establish a contractual price ceiling for live use. An organization assessing economics should choose the task mix and effort level it cares about, allow only approved models, and inspect its own bill and quality outcomes under that configuration.

GitHub lists availability on all Copilot plans in Visual Studio Code, the GitHub Copilot app, GitHub Copilot CLI, and JetBrains IDEs. Additional clients are planned later. It tells users to update their client, open the model picker, select Fusion, and choose an effort level. Research-preview selections of auto, HydraFusion or HydraFusion Max are to move to the corresponding Fusion levels. Existing users should check the migrated setting rather than assume that an old label preserves a particular model or expenditure pattern.

For a controlled trial, an engineering team could compare its own repeatable coding tasks under a selected effort level, record outcomes and charged model usage, and review administrator policies before enabling a default. Those are recommended evaluation steps, not tests that this article has performed. The grounded product change is that GitHub made the named routing feature GA with three execution patterns, three effort choices and enterprise policy controls. The published benchmark is useful context only when its vendor attribution, comparator, task denominator and Max setting travel with the numbers.