Copilot Fusion’s bill: One prompt can mean one model or several

🛠️ Deep dive · Oct 30, 2026 · ~8 min read

What shipped

On Oct 28, 2026, GitHub made Copilot Fusion generally available on all Copilot plans in Visual Studio Code, the GitHub Copilot app, Copilot CLI and JetBrains IDEs (GitHub Changelog: Route and orchestrate models with GitHub Copilot Fusion). It merges Project HydraFusion’s multi-model orchestration with Copilot auto model selection.

You pick Fusion and an effort level (Standard, High or Max), and Copilot decides which models run each prompt.

The docs describe it as a runtime router and orchestrator that returns a single response (GitHub Docs: About GitHub Copilot Fusion). For each prompt it picks one of three execution patterns:

• Single: one model completes the task.
• Cascade: an efficient model drafts, and a judge either accepts the draft or escalates to a stronger model.
• Critique: one model drafts while several models critique it in parallel, and the first model revises using their combined feedback.

The pattern can change from prompt to prompt in the same session. Our Oct 28 Daily covered the basics; this piece is about what that does to your bill and your policies.

Who pays for which step

There is no separate charge for Fusion. You are billed for each model it uses, at that model’s standard rate (GitHub Docs: About GitHub Copilot Fusion). That one rule explains most of the cost behavior:

• Single costs about what one request to that model costs. The docs say it behaves like a request to one model.
• Cascade adds a judge call, and a second, stronger model if the draft gets escalated.
• Critique adds several reviewer calls plus a revision pass.

GitHub says Fusion only adds model calls when a task warrants them, so a simple task doesn’t pay for a review it doesn’t need. Choosing the pattern is a light step that adds minimal latency, but Cascade and Critique take longer because of the extra calls.

Effort level sets how often you pay for extras. Standard balances cost, quality and latency and selects one model per task. High is for substantial, well-scoped work, such as a complex bug or a change across several files, when extra calls may be worth the time and AI credits.

Max aims for frontier capability while still watching token use. The docs say plainly that High and Max can use more than one model per task, so a task may consume more AI credits than it would on Standard.

Paid plans get a 30% discount on model costs with Fusion through Nov 30, 2026 (GitHub Docs: Optimizing your AI usage). The changelog itself gives no end date, so plan for standard rates after Nov 30.

Fusion has no price of its own. The price is whichever models it decided your prompt needed.

Why Fusion tries to stay on one model

Caching is where long agent sessions save or lose money. GitHub’s usage guide says cached tokens are typically billed at 10% of the normal input price, and that switching models mid-session invalidates the cache, so the next request rebuilds it from scratch (GitHub Docs: Optimizing your AI usage).

Fusion is built around that. It keeps your main conversation on the same model whenever possible, and helper models such as a reviewer get only the context they need.

Routing happens at natural cache boundaries and at large jumps in conversation complexity, to avoid cache costs that buy no quality (GitHub Docs: About GitHub Copilot Fusion).

Two more rules shape long sessions. Fusion has no context window of its own: each step runs inside the limits of the model running it, and the window shown for Fusion is a conservative value based on the smallest model it uses.

Blast radius for teams

That last row is easy to miss. The docs warn that if Fusion discards a draft, changes the draft already made in your workspace, such as file edits, aren’t rolled back automatically. Fusion also works separately from subagents and doesn’t start them.

What admins can now lock

Enterprise owners get a dedicated list: under AI controls, then Copilot, Configure Copilot Fusion models sets which models Fusion may use.

A model enabled there still reaches a user only if your other model policies allow that user to use it (GitHub Docs: Managing availability of models in your enterprise). The changelog adds that you can disable a model for Fusion without disabling it for everyone.

If none of Fusion’s models are available to a user, Fusion simply disappears from their picker.

Enterprise managed settings go further (GitHub Docs: Enterprise managed settings):

• Set model to "fusion" to make Fusion the default for new conversations. Users can still choose a different model per conversation.
• Set fusionTier to "standard", "high" or "max" to lock the effort level against user and repository overrides. "unmanaged" leaves it open.
• Wrap it as { "overridable": "standard" } to give a default that enterprise teams can override in their own settings file.

fusionTier needs minimum client versions: VS Code 1.144.0 or later, plus recent Copilot CLI and Copilot app builds, with exact minimums listed on the managed-settings page.

Migration notes

1. Decide the default first. If you want Fusion everywhere, set model to "fusion"; if not, leave it unset and let people opt in from the picker.
2. Review the Fusion model list separately from your general model policy, especially if you disabled costly models for everyone.
3. Pick a starting effort level. Standard is the documented everyday tier; lock it with fusionTier if you need predictable spend, or make it overridable for teams that need High.
4. Tell research-preview users their auto, HydraFusion or HydraFusion Max picks have moved to the matching Fusion levels.
5. Update clients to the versions above before relying on fusionTier.

Controls and escape hatches

• Pick a model yourself. Fusion is a picker option, not a mandate. In the Copilot app, toggle the Copilot Fusion switch off and choose a model (GitHub Docs: Choosing a model in the Copilot app).
• Script it. In Copilot CLI, copilot --model fusion --fusion-tier standard -p "YOUR PROMPT" sets Fusion and the effort level per run (GitHub Docs: Choosing a model in GitHub Copilot CLI).
• Route to a local model. In an experimental preview, Fusion Standard can choose MAI Code 1.1 Flash on supported Windows devices, or in Copilot CLI a locally served Qwen3.8 Flash Next on Windows, macOS or Linux, so some tasks finish without GitHub AI credits (GitHub Changelog: Copilot Fusion now supports selection of local models). It must be switched on as an experimental feature. Routing decisions still happen in the cloud, so the session is not offline, and local models may have different safety protections.

The number everyone quoted

GitHub says Copilot Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, within two points of Claude Code with Opus 5.5 Max, at about half the average API cost per task, with about half the tokens and about 40% less time per task.

That is GitHub’s claim about its own product on one index. We have not measured Fusion’s cost or quality, and your mix of tasks will differ.

The one named customer in the changelog is AT&T. Hari Pokhrel, Principal Software Engineer, says: “Previously, developers would often choose a more powerful model for a complex task and forget to switch back for everyday activities.” He adds that Fusion Standard “has improved token efficiency across AT&T”.

That is the cleanest case for Fusion: people who leave an expensive model on for routine work.

Chef’s pick: start teams on Fusion Standard, watch a week of usage, and move to High only for the bug-hunting and multi-file work it was built for. Admins should check the Fusion model list before making it the default, because that list is what decides the bill.