Copilot Fusion Local Routing: Why On-Device Is Not Offline

On October 28, 2026, GitHub announced two related changes: Copilot Fusion became generally available, and local-model selection inside Fusion entered experimental preview. The headlines make a compelling promise: let a router choose when a coding task should run on a device rather than on a cloud model. The interesting engineering question is not whether local inference works. It is which component still makes the decision, what information crosses the boundary, and whether the apparent savings survive a complete task-level measurement.

The distinction matters because an on-device model and an offline agent are not equivalent. GitHub’s local routing announcement explicitly states that Fusion continues making routing decisions in the cloud. The Fusion product documentation describes a separate orchestration layer that can select models and execution patterns per request. These are documented properties, not a packet-capture result from an independent test.

The actual architecture: routing and inference are different operations

A conventional local coding assistant can keep inference on the same machine as its repository, provided its tools, telemetry, updates and dependencies also stay local. Fusion introduces a control-plane decision: the system evaluates a task and decides which eligible model or models should handle it. Sometimes the selected execution engine is local; sometimes it is remote.

A useful conceptual diagram is:

Editor / Copilot CLI / Copilot app
           |
           v
  Fusion routing decision
     (cloud control plane)
           |
        selection
        /       \
       v         v
local model   cloud model
       \         /
        v       v
   response / tool activity

This is an explanatory abstraction, not a claim about the exact transport protocol, request fields, or internal services. GitHub has not established in the cited release notes that routing transmits full source files, only metadata, or a fixed subset of the prompt. An auditor should not invent those details. The observable fact is narrower: GitHub says the routing decision remains cloud-based even when inference executes locally.

That creates at least three distinct boundaries to review: code and prompt context gathered by the client; the information used to choose a model; and the payload sent to the selected inference endpoint. A fourth boundary appears when the model asks a tool to read files, execute commands or call a network API. The location of matrix multiplication alone does not define the security posture of the complete agent.

Three modes that must not be conflated

The third row describes the documented local-model eligibility as of October 28, not a permanent restriction on future versions. The Fusion documentation says local selection is currently limited to Standard. It describes three execution patterns overall: Single (one model), Cascade (a draft reviewed for acceptance or escalation), and Critique (a draft reviewed by other models and revised). Standard is described as selecting one model for a task; High and Max can use extra model calls. Treat the patterns as orchestration behaviors, not guarantees that a local endpoint participates in each one.

This difference changes how to interpret performance claims. A faster answer may come from a smaller model, a cached prefix, a skipped review, fewer tool calls or a local endpoint with low network latency. Without per-step routing and usage records, the explanation is not identifiable.

What can actually enter the local routing pool?

GitHub’s October 28 release supports a narrow set of eligible local models, rather than arbitrary models discovered in a local server.

For the managed Windows path, GitHub documents MAI Code 1.1 Flash through Windows ML. In Copilot CLI, the user enables experimental features and opens /model. In the Copilot app, the Windows ML provider and the Local model auto routing experiment must be enabled. In VS Code, GitHub documents the chat.copilot.localModel.enabled setting. Once configured, select Fusion Standard to permit local/cloud selection. These steps come from the October 28 changelog.

For the manually configured path, Copilot CLI can use an OpenAI-compatible local server on Windows, macOS or Linux. GitHub specifically identifies MAI Code 1.1 Flash and Qwen3.8 Flash Next as supported local routing candidates. Its Fusion documentation further specifies that Qwen3.8 Flash Next must be recognized under the expected local identity, qwen3.8-flash-next-local. Merely adding a model through bring-your-own-key configuration or discovering it in Ollama does not make it Fusion-eligible.

The Copilot app’s BYOK support is a separate feature: a compatible local model may be selected directly, but intelligent local routing in the app is currently tied to managed Windows ML models. This is why a screenshot of a local model in the picker is not evidence that Fusion routed a request to it.

Hardware and context are hard gates, not marketing footnotes

GitHub’s Copilot CLI setup documentation lists substantial minimum available combined RAM for its managed Windows local models: 96 GB for MAI Code 1.1 Flash and 48 GB for Flint NVFP4, with corresponding minimum free storage of 60 GB and 23 GB. It specifies an NVIDIA GPU for that managed installation path, along with a sufficiently recent llama.cpp build. Those numbers are vendor prerequisites, not independent minimum-VRAM measurements. They must not be generalized to every quantization, runtime, or operating system.

A manually hosted model has a different hardware envelope. Quantization can reduce weight memory, but context length, KV cache, temporary tensors, batch size and offload policy still matter. A model may load successfully and yet stall or fail on a repository-scale prompt. The same CLI documentation warns that a model configuration’s token limits must match the actual model; setting a large maxPromptTokens value does not create a larger context window.

GitHub also warns against loading the managed model simultaneously in different Copilot surfaces, because separate instances may exhaust system memory. For a controlled test, keep one surface and one model server instance active, and record resident memory and GPU allocation before and after each run.

Local inference is not a privacy certification

There are at least four privacy claims a reader might hear:

1. Weights are stored locally. This only establishes where model artifacts reside.
2. Tokens are processed locally. This describes the inference execution location for a particular request.
3. Prompt and repository context never leave the machine. This requires evidence about routing, telemetry, tool calls and fallback behavior.
4. The complete agent works without an external network. This requires all control-plane, authentication, update, inference and tool dependencies to be local or disabled.

GitHub documents the second claim for eligible locally selected inference, but explicitly cautions that Fusion is not offline. The public documentation does not supply enough information to infer the third claim for all Fusion requests. The correct security conclusion is therefore a request for evidence, not an accusation of data leakage.

For an organization with strict source-code handling requirements, a cloud router is an architectural dependency to review even when it sometimes selects a local endpoint. Ask what fields are transmitted for routing, whether routing requests are retained, what happens when the router is unavailable, whether fallback to cloud inference is possible, and whether the product provides a hard local-only policy. Do not assume a checkbox labelled local routing answers any of these questions.

There is a useful control experiment: the Copilot CLI documentation describes COPILOT_OFFLINE=true for preventing CLI contact with GitHub servers, while requiring a local or isolated model provider for full network isolation. That is a different operating mode from Fusion’s cloud-controlled selection. Test them separately; do not present one as evidence for the other.

The economics: per-model billing is not the same as local savings

GitHub’s Fusion general-availability announcement says Fusion Max scored 60 on the Artificial Analysis Coding Agent Index, two points below the comparison Claude Code configuration, at approximately half the API cost and tokens and around 40% less task time. Those are GitHub-reported benchmark comparisons, not measurements performed for this article, and they concern Fusion Max—not the experimental Standard local-routing path.

The product documentation says Fusion bills for each model it uses at the model’s normal rate; High and Max may invoke more than one model. It also documents a temporary 30% model-cost discount through November 30, 2026 for eligible paid plans. A discounted cloud bill should not be mistaken for a lower underlying inference cost. A local model can avoid some cloud inference charges while still consuming power, memory, setup time and maintenance effort. Actual savings depend on the fraction of tasks routed locally and on the quality and retry rate of their outcomes.

For an illustrative calculation, let p be the fraction of requests that Fusion routes locally, C_cloud the cloud model cost per accepted task, C_local the fully loaded local compute cost, and C_retry the cost of failed or escalated attempts. Then a simplified expected cost is:

E[cost] = p*C_local + (1-p)*C_cloud + C_retry

This is a model for evaluating a deployment, not a measurement or GitHub billing formula. In practice, multi-step orchestration, prompt length, quality differences, cache reuse and failure recovery make each term task-dependent. A model that costs less per token but produces twice as many invalid edits may cost more per accepted patch.

A falsifiable evaluation, without pretending to have run it

A defensible test needs matched tasks and observable model selection, not a demonstration in which the router chooses an easy prompt for the local model and a hard prompt for the cloud model.

Prepare a public benchmark repository with at least three workload classes: isolated code explanations, small bug fixes with tests, and multi-file refactors requiring tool use. Use public tasks or synthetically generated fixtures; do not expose confidential repositories to a new preview feature. Pin the repository revision, client build, model artifact and quantization, local server configuration, network state, temperature where controllable, and maximum token budgets.

Run each task in four modes:

Record the model actually selected, whether a review or escalation occurred, time to first output, total task time, tokens or billable units when exposed, process and GPU memory, tool-call count, tests passed, and the number of manual corrections. If the client does not expose a necessary field, mark it not observable rather than inferring it from speed. Repeat tasks enough times to characterize variability, and report the denominator for every success rate.

The key comparison is not simply B < C in latency. It is whether B improves cost per accepted, tested change while preserving task quality, and how often it selects the local endpoint. A second question is whether the same prompt can be routed differently as cache state, context length or service availability changes. GitHub’s documentation says routing considers system health and natural cache boundaries; that is a plausible confounder to control, not evidence of a particular algorithm.

For the privacy arm, use a throwaway repository containing synthetic canary strings that are not real secrets. With consent and a permitted test environment, capture destination domains, connection timing and bytes transferred for direct-local, Fusion Standard and explicit offline mode. Network metadata alone does not establish the contents of an encrypted request. Do not claim proof that source code was or was not transmitted without a supported method for inspecting payloads and clear scope of observation.

Failure modes worth testing before adoption

Silent cloud fallback. Disconnect the local model endpoint during a Fusion session. Does the client fail, ask permission, or choose a cloud model? A local-only security requirement needs an enforced answer, not a preference.

Context overflow. Provide a task whose prompt fits the cloud model but exceeds the local model’s actual context window. Measure whether it is rejected, truncated, rerouted or degraded. The model picker is not a context validator.

Tool-call incompatibility. The CLI requirements specify streaming and tool-calling support. A server that accepts chat-completion requests but mishandles tool schemas may appear compatible until an agent tries to edit files.

State after critique. GitHub notes that discarded drafts can leave workspace edits behind; the orchestration decision does not automatically roll back filesystem changes. Check the working tree and test suite after every run, especially when comparing multi-model patterns.

Policy drift. Model eligibility, available models and execution patterns can change. Re-run the matrix after client updates and document the actual model selected rather than relying on a prior routing percentage.

Decision: useful hybrid capability, not an offline replacement

The October 28 launch is meaningful because it brings local inference into a mainstream coding assistant’s automatic selection path, not merely into a manually selected model menu. For teams with capable local hardware and permissive cloud-routing policies, that could improve the economics of straightforward coding tasks. For teams requiring strict offline operation, it does not remove the need for a fully local client, control plane and tool chain.

The next independent result worth publishing is a matched-task study that reports the local selection rate, accepted-patch cost, failure rate, memory pressure and observed network boundary. Until those measurements exist, the honest conclusion is narrower: GitHub has documented an experimental hybrid routing mechanism with explicit limitations, while its advertised benchmark efficiency figures apply to a different Fusion mode.

Primary sources and verification boundary

The October 28 local-model routing changelog and Fusion general-availability changelog establish launch timing and stated capabilities. The Fusion concepts page, CLI model setup guide, Copilot app model guide and auto-selection documentation establish current eligibility, limits and distinctions between routing modes. No independent Copilot session, packet trace, model benchmark or billing measurement was conducted for this article.