Model choice used to be a visible decision in the coding loop: pick a model, send a prompt, inspect the result, and switch when the task changed. GitHub Copilot Fusion makes that choice part of an orchestration layer instead. The developer selects an effort level, while the system routes the task across models.
GitHub says Fusion combines multi-model orchestration with automatic model selection. Its documented execution patterns include a single model, a cascade in which a judge can escalate a draft, and a critique loop in which one model reviews another's work before revision.
Routing is powerful only when the contract is visible
This can reduce the cognitive overhead of choosing a model for every step, but it also hides an important part of the system. Teams need to know which models are allowed, how costs accumulate, what happens when the judge is wrong, and how an administrator can disable a model without disabling the whole workflow.
The abstraction is not ‘one better model’. It is a managed team of model roles.
For a builder, the practical starting point is an evaluation set that represents the real task. Compare a routed workflow with a fixed model on completion rate, cost per accepted change, time, and review effort. Without that baseline, orchestration can look smarter while simply spending more.
GitHub describes Fusion's model routing, execution patterns, availability, billing, and reported benchmark result in the linked release note.
GitHub Changelog · Route and orchestrate models with GitHub Copilot Fusion ↗
