GitHub has made Copilot Fusion generally available, moving multi-model routing from an infrastructure concern into the everyday coding workflow. Instead of requiring a developer to select one fixed model, Fusion can choose and orchestrate one or more models for a request.
The release matters beyond GitHub Copilot. It demonstrates how a user can submit one task while the service makes several underlying model decisions, potentially generating several separately billed calls. That changes what developers, administrators and billing systems need to know about a request: the model shown in the interface is no longer necessarily a complete description of how the work was performed.
Fusion can select, cascade or critique
GitHub documents three execution patterns for Fusion. A request may go to a single selected model, move through a cascade of models, or use one model to critique another model’s output. Users can also choose Standard, High or Max effort levels, giving them some control over how much orchestration is applied.
This is a significant product shift because routing is becoming part of the end-user experience rather than an invisible optimization behind a provider API. A multi-model API gateway for teams may perform similar selection at the application layer, but Fusion puts the decision inside a major development environment and exposes an effort control directly to the developer.
The approach could reduce the need for users to understand the strengths of every available model. It also creates a new diagnostic problem. When an answer is slow, expensive or incorrect, teams need to know whether the result came from one model, a cascade, or a critique pass involving several models.
One request can produce several charges
GitHub says each model used by Fusion is billed at that model’s standard rate. It has also announced a temporary 30% discount on Fusion model costs for paid plans, although the reviewed announcement does not specify when that discount will end.
That billing design makes the execution trace commercially important. A single developer action may consume more resources than a direct call to one model, even when orchestration produces a better result. Teams evaluating Fusion will therefore need to compare cost per completed coding task, not only the listed token price of the first model involved.
The same issue applies to unified AI API billing. Usage records should identify every underlying model call while preserving the connection to the original user request. Without that relationship, administrators may see model charges but struggle to explain which task generated them or whether an effort setting increased the cost.
Enterprise policies still shape the route
Enterprise and organization administrators can restrict which models Fusion may use through GitHub’s existing model policies. That gives companies a way to exclude models that do not meet internal requirements, but it also means the same Fusion request may be routed differently across organizations.
For engineering leaders, model policy and budget policy now need to be considered together. Permitting an expensive model in the catalog may allow Fusion to invoke it as part of a multi-model sequence, not only when a developer chooses it explicitly. Practical AI API spend controls for teams should therefore account for orchestration depth, effort level and the total cost of all calls associated with a task.
Gateway operators face a related reporting requirement. Logs should distinguish the model or mode requested by the user from every model that actually served the request. That distinction supports cost attribution, incident investigation and reproducible evaluations when routing behavior changes over time.
Local routing does not eliminate cloud questions
GitHub has also introduced an experimental preview that can route between eligible local and cloud models. Local inference may provide another option for cost, latency or data handling, but the word “local” does not by itself describe the complete processing path. Teams still need clarity about which routing decisions, prompts, metadata or follow-up model calls remain in GitHub’s cloud services.
Several details remain unsettled. GitHub has not specified the duration of the 30% discount, and its published cost and performance comparisons with Claude Code depend on a particular benchmark configuration. Those results should not be treated as universal estimates for every repository or workload.
The durable change is architectural: model orchestration is becoming a standard feature of developer tools. As that happens, transparent routing records, policy-aware model selection and task-level cost reporting become necessary parts of the product rather than optional observability features.