Copilot Fusion's Local Model Preview: Only One of Three Stages Runs on Your Machine

GitHub shipped an experimental preview on October 28, 2026 that lets Copilot Fusion add eligible local models to its smart routing, splitting tasks between local and cloud models. I went through the announcement expecting the other half of the story to be an offline coding agent. It is not. GitHub says plainly that routing decisions are still made in the cloud.

Copilot Fusion is the model routing and task coordination layer inside GitHub Copilot. It looks at a request and the models available, picks one, and feeds that model's output back into the coding workflow. It answers which model handles a task. It does not move the workflow onto your hardware.

A model running on your machine and a coding task that survives a pulled network cable are two different claims. The first one is confirmed. The second depends on your specific setup. Three questions separate them. Who chooses the model. Which model runs the inference. What the tools touch when they execute. Once those three are untangled, it becomes possible to say which steps keep working offline, what code data may leave the machine, and whether adding a local model actually lowers development cost.

The Local Model Support Is Real, the Offline Agent Is Not

A reachable endpoint is not a routing decision

The update lands in Copilot CLI first. On Windows, macOS and Linux, Copilot CLI supports configuring local models. You prepare the model files and the inference runtime yourself, then connect through a local OpenAI-compatible endpoint. After that, experimental local routing has to be turned on in settings and Standard mode selected in Copilot Fusion. Only then do eligible local models get considered for automatic assignment.

Three things get conflated at this point. A local service that answers means the network endpoint works. A model Copilot can discover means it shows up in the config file or the model list. Whether it ends up in Fusion's automatic routing depends on the product surface, the model allowlist (GitHub names MAI Code 1.1 Flash and Qwen3.8 Flash Next), and feature access on your account. Exposing an OpenAI-compatible endpoint does not mean Fusion will call that model automatically.

The desktop app follows a different set of rules

The Copilot app connects to and manually selects compatible local models through bring-your-own-key (BYOK). Smart routing there currently only supports models hosted by Windows ML. Being able to pick a local model by hand in the desktop app does not mean Fusion will choose it during automatic routing.

Both clients sit on an experimental preview. Before depending on this for real work, check client version, subscription tier, operating system, region, and the current support list in the official docs.

A Coding Task Has Three Stages and Only One Is Local

Take a normal request. Change the date-formatting function in the project, add unit tests, run the test command. The UI shows one input box, but behind it the request loops through routing, inference and tool execution several times.

Routing picks the model

Copilot Fusion weighs eligible local models against cloud models using its own evaluation logic. This update adds local models to the candidate pool. It does not move the router onto your computer. GitHub has confirmed that routing decisions are still made on its cloud servers.

Inference generates the code and the answer

If cloud routing sends the request to a local model, code generation runs on your hardware. If it goes to a cloud model, the compute happens in the cloud. Local inference tells you where the model computes. It does not tell you the whole interaction stays on your machine.

Tool execution changes the project

Reading local files, writing code changes, launching a terminal to run tests. All of that depends on specific tools. The model suggesting "run the tests" in text and the system actually launching the test command are two separate actions. When tools run, they may only read and write local files. They may also connect to a remote repository, pull third-party packages, or call external network APIs.

The real path of an AI coding task is cloud routing picks a model, a local or cloud model does the inference, and tools carry out the changes. This is where most evaluations of local AI coding tools go wrong. Where the model runs only tells you where inference happens. Who picks the model and what the tools reach have to be checked separately.

Where the Network Dependency Actually Sits

Whether a task keeps going offline depends on how you use the local model. Three paths behave differently.

Direct endpoint, manual pick, automatic routing

If you skip the client and send requests straight to the local inference service, you can check whether that service handles input without internet access. That only proves the underlying model service runs offline. If you manually choose a local model in the Copilot client, watch whether account authentication, session state and other supporting services need the network. If you rely on Copilot Fusion's automatic routing, cloud routing is a gate you cannot route around. GitHub has confirmed that even when a local model handles inference, the Fusion session does not become fully offline.

Four behaviours worth testing before concluding anything

• Whether requests already in flight when the connection drops can finish.
• Whether the terminal returns a clear error code or triggers a fallback when the cloud routing request fails.
• Whether the local toolchain can continue unfinished steps while the local inference service is still alive.
• Whether an interrupted task resumes where it stopped once the network is back, or has to start over.

Every one of these depends on client version, configuration, task complexity and tool dependencies. Testing beats guessing here.

A three-state comparison on a throwaway project

Set up a small isolated project with made-up data and a fixed prompt, then run the same instruction through three states.

1. Internet connected, local inference service on.
2. Internet connected, local inference service manually turned off.
3. Internet physically disconnected, local inference service kept on.

Where the errors show up across those three runs tells you whether the network dependency sits in routing, inference or tool execution. Keep "local service off" and "internet off" separate. The first tests how the client handles a missing local inference service. The second tests how much cloud routing and supporting tools depend on the network.

Privacy and Cost Are Two Separate Audits

What the routing request actually carries

Many teams adopt local models for compliance and privacy reasons. The privacy boundary is not about whether model weights sit on your disk. A complete coding task involves prompts, project context, code file contents, tool output and diagnostic logs. Check item by item which fields get packed into cloud routing requests, which content is handled purely by the local model, and which telemetry gets written to cloud logs.

What is confirmed is that Copilot Fusion makes routing decisions in the cloud. GitHub's announcement has not fully disclosed the payload of each routing request, so neither claim holds up. Teams cannot say full code is definitely uploaded, and they cannot assume the cloud only receives metadata with no code. The tool execution stage sends data out too, through dependency installs, external APIs used in testing, and reads or writes against remote Git repositories. For projects with strict confidentiality requirements, do not treat a local model as a complete privacy shield until three things are confirmed. What input goes to the cloud. What the routing logs keep. Whether tools reach external services.

Three line items in the bill

Adding local compute does not cut cost in a straight line. A team's total cost has at least three parts. The base Copilot subscription. The cloud model quota consumed. The hardware depreciation, VRAM usage and maintenance effort of running a large model locally.

If a local model takes a task, whether it still counts against some Copilot chat quota depends on GitHub's actual billing rules. If a task gets switched back to a cloud model midway through a multi-turn conversation, those cloud calls need checking too. Local model efficiency is also not just raw generation speed. Cold-start model loading, long-context prefill, tool call time and rework from bad code changes all stretch out delivery time.

Without same-condition tests and billing records, track end-to-end metrics per task from start to delivery. Time to first response, code change accuracy, unit test pass rate, number of model switches, cloud quota used, and how often a human had to step in. That is the only way to measure real return on investment.

Running the Boundary Test on an Isolated Setup

Where ServBay fits in the workflow

ServBay, a one-stop AI development management tool, is what I would put underneath this kind of test. It stands up the local endpoint, the model runtime and an isolated test project before Copilot CLI ever points at them, and it keeps those pieces separate from the editor and the client. Building on that, the test results can turn into a local agent data-flow checklist recording model status, routing responses, tool calls and network errors.

The five checkpoints

No real business repository is needed. Create a small project with only made-up data, and lock down the Copilot CLI version, the local model (MAI Code 1.1 Flash or Qwen3.8 Flash Next, for example) and the inference service configuration. Then give the AI a standard instruction. Change the project's date-handling function, add unit tests, run the test command automatically.

During testing, switch between the online and offline states and record five checkpoints. Whether the local model server logs the request. Whether cloud routing lets it through. Whether tools can read and write local files. Whether the test script actually launches. And at which stage the error shows up.

Never use real API keys, private business code or production data during testing. Scrub account tokens and local absolute paths before publishing any test logs or screenshots.

How I'd Judge Any Tool Claiming Local Model Support

This Copilot Fusion update officially brings local models into smart routing, and the technical change is clear. Copilot CLI can configure local models and connect compatible services on major operating systems. The Copilot app can connect to and select some local models. The limits are just as clear. Routing decisions stay in the cloud, local inference does not turn a coding session into an offline agent, and a model discovered through BYOK is not automatically eligible for routing.

When evaluating any AI coding tool that advertises local model support, do not stop at whether the weights run on your computer. Follow the task chain and track who picks the model behind the scenes, which steps need the network, what the tools reach in the background, and how quotas and costs get counted. Run the whole chain once in an isolated environment and the relationship between local inference, cloud routing and tool execution stops being a matter of assumption.