GitHub Copilot Fusion makes model routing a developer-tool feature GitHub Copilot Fusion makes model routing a developer-tool feature

Effort replaces a fixed model choice

GitHub's launch combines its earlier automatic model selection with the multi-model work from Project HydraFusion. Users choose Standard, High or Max effort while Copilot chooses the models involved. The announcement positions Standard for everyday coding and reserves the higher levels for more demanding work. Fusion is available across Visual Studio Code, Copilot CLI, the Copilot app and JetBrains IDEs. That puts orchestration inside several existing coding environments, with the effort setting describing the requested service level instead of identifying a particular model.

The workflow can change between prompts

GitHub documents three execution patterns. One model can answer directly; a judge can accept or escalate a draft; or critics can provide feedback for revision. Fusion selects the pattern for each prompt, so a follow-up can use a different arrangement from the first request. The documentation says model selection also considers service health and availability. This means one conversation can contain several execution paths. The visible response is the result of that process, while the underlying work may involve drafting, review and a revised answer.

An advisor keeps one choice explicit

Claude Code's advisor tool separates configuration from consultation timing. The user selects the advisor, and the main model decides when to request guidance. Anthropic documents a server-side consultation that receives the conversation, including tool activity, before returning advice. The main model then continues the task. Compared with Fusion, this keeps the identity of the second model under direct user control. It also gives the second model a defined advisory role, instead of asking a router to choose both the participants and their arrangement.

Administration defines the available pool

GitHub's enterprise documentation provides separate controls for models used by Fusion. Enabling a model there only makes it available when the user's other model policies also permit access. The broader enterprise settings can enable, disable or delegate model access to organizations or enterprise teams. Fusion therefore operates inside an existing permission boundary, with an additional filter for automatic selection. An enterprise can keep a model available for direct use while excluding it from Fusion. That distinction makes the routing configuration a separate administrative decision from general model access.

Billing follows the models involved

GitHub's launch says Fusion charges for the models used, with no separate orchestration fee. More participating models can therefore change a task's bill even when the user receives one final response. Claude Code also adds advisor usage to the main model's consumption. Its documentation says each consultation processes the full conversation anew, without reusing the advisor's previous read. The main model's prompt cache remains intact when the advisor is enabled or disabled. These designs attach costs to different forms of extra work: selected execution steps in Fusion and discrete consultations in Claude Code.

The products expose different review records

Fusion shows progress and the models involved, then presents the final response after intermediate drafts have been revised or discarded. Claude Code marks consultations in its transcript and distinguishes returned guidance, a declined request and an unavailable advisor. The records consequently describe different units of work: orchestration steps in one product and advisory events in the other.