What happened
On October 28, 2026, GitHub said it was shipping intelligent routing for local models in experimental preview. Copilot Fusion can now choose between supported on-device models and cloud models in GitHub Copilot CLI, the Copilot app, and Visual Studio Code. The preview is opt-in. Its intended interaction is not a separate local-only chat: users select Standard in Copilot Fusion and let Copilot choose between eligible local and cloud models for requests.
GitHub offers a managed setup path on supported Windows devices. Users can download and configure MAI Code 1.1 Flash through the Windows ML provider. In Copilot CLI, the documented path is to enable experimental mode, open /model, and follow the setup prompts. In the Copilot app, users configure Windows ML under Settings > Model providers, enable Local model auto routing under Settings > Experiments, and begin a new session. Windows ML local models are enabled by default on Windows. In VS Code, the feature is enabled with chat.copilot.localModel.enabled; once the model is ready, selecting Standard in Copilot Fusion permits routing, while selecting the local model directly keeps it as the session choice.
The managed download experience is limited to Windows, but Copilot CLI’s local Fusion routing can also use manually configured local models on Windows, macOS, and Linux. GitHub names MAI Code 1.1 Flash and Qwen3.8 Flash Next as supported choices when served through a local OpenAI-compatible server. In that path, the user manages both the model download and the inference runtime, and must have hardware resources sufficient to run the model. They then configure it as a supported local-model provider, enable experimental local routing, and select Standard.
There are material boundaries. Adding or discovering a model through bring-your-own-key configuration does not by itself make it eligible for Copilot Fusion routing. The Copilot app can connect to and directly select compatible local models through BYOK, but its intelligent routing currently supports managed Windows ML models only. Most importantly, local inference does not make a Copilot session offline: Fusion’s routing decisions still happen in the cloud. GitHub also says local models may have different safety protections from Copilot-provided cloud models.
What the archive adds
This is a new capability on a known Copilot local-model thread. Four days earlier, Discover local models in GitHub Copilot CLI covered CLI discovery of supported models from a running local Ollama instance. The new fact is per-request routing between eligible local and cloud models rather than discovery alone. The same day, GitHub Copilot CLI 1.0.105 lets users pick Copilot Fusion High or Max from long-context sessions; Copilot SDK 1.0.28 follows documented additional Fusion model choices.
Trend signal
This supports Harness architecture outlives model choice. Copilot Fusion is making routing policy and the surrounding client integration the decision layer above any one model: Standard can span local and cloud candidates, while a direct model selection remains available. The preview does not prove that this routing is reliable or economical, but it makes the harness, not merely a model picker, more central to the product boundary.
Why now
GitHub describes the release as building on recent local-model discovery improvements in Copilot CLI. The sequencing matters: a client first needs a way to find or configure supported local providers before it can make them candidates for automatic selection. GitHub has now added a managed Windows path and a manual OpenAI-compatible-server path, but kept the feature experimental and opt-in.
Connections to other events
The release sits beside GitHub’s October 8 general availability of local Copilot sandboxing, covered in Local sandboxing for GitHub Copilot is now generally available. Sandboxing concerns the execution context for agent-initiated commands; local routing concerns which model handles a request. Together they show GitHub exposing more control over both the model path and the runtime around an agent, though this announcement does not state that the two features are integrated.
Why it matters
Teams interested in local models often face an awkward choice: commit a session to local inference, or repeatedly decide when to return to a cloud model. Fusion’s Standard mode is an attempt to move that choice into the coding assistant’s routing layer. The practical benefit is potentially lower friction when testing a local-capable setup alongside a cloud workflow.
It is not a blanket privacy or cost claim. The routing decision remains cloud-based, local hardware and runtime operations remain the user’s responsibility in the manual path, and GitHub explicitly warns that safety protections can differ for local models. Teams should therefore treat this as a controlled experiment: identify which requests may use local inference, document the data boundary, and check outputs and policies before relying on the route in sensitive repositories.
What happens next
- GitHub broadens the managed local setup beyond the current Windows path (6 months, 55%). Watch for: a managed macOS or Linux provider announcement.
- More Copilot-supported local models become eligible for Fusion routing (3 months, 60%). Watch for: updated supported-provider documentation.
- Organizations ask for routing controls and auditability (6 months, 65%). Watch for: policy, logging, or enterprise administration settings for local routing.
Limits and uncertainty
GitHub’s changelog establishes that the feature is in opt-in experimental preview, not that it improves quality, latency, privacy, or cost for a particular workload. It does not explain the criteria Fusion uses for individual routing decisions, how often it selects each path, or whether users can inspect the decision after the fact. It also does not provide hardware requirements, benchmark results, geographic availability, or enterprise policy controls. The supported manual models named in the announcement should not be read as a general promise that every OpenAI-compatible local server is eligible.
Skill to build now
Set up a small, non-sensitive repository as a routing test. If your environment qualifies, enable the preview and run a short, repeatable set of tasks in Standard mode: code explanation, a bounded edit, a test-generation request, and a repository question. Record whether the environment selected a local or cloud model when that information is available, plus latency, output usefulness, and review effort. Separately confirm what source code or prompts leave the machine, because the routing service remains cloud-connected.
Reader takeaway
Copilot Fusion now treats supported local models as routing candidates rather than only models a developer must select manually. That is a meaningful workflow shift, but it is still an experimental, cloud-routed feature with a Windows-first managed setup and explicit safety and operational limits.