Copilot Fusion Takes Local Models, and the Offline Boundary Is Somewhere Else

GitHub published an experimental preview on October 28, 2026 that lets Copilot Fusion add eligible local models to its smart routing and split tasks between local and cloud models. The same announcement states that routing decisions are still made in the cloud. A model running on a developer's machine and a coding session that needs no network at all are two separate things. The first is confirmed. The second has to be checked against a specific setup.

Copilot Fusion is GitHub Copilot's model routing and task coordination layer. Based on the request and the models available, it picks a model and feeds that model's output into the rest of the coding workflow. It answers which model handles a task. It does not move the whole workflow onto local hardware.

For anyone evaluating this feature, three questions carry the weight. Who chooses the model, which model performs inference, and what resources the tools touch while they run. Keep those three apart and the offline boundary, the data exposure and the real cost all become measurable.

What Copilot Fusion Changes and What It Leaves Alone

Routing remains a cloud-side decision

The update adds local models to the candidate pool. It does not relocate the router. GitHub has confirmed that routing decisions continue to run on its cloud servers, so the selection step stays a network dependency no matter which model ends up generating code.

Local support differs between the CLI and the desktop app

The update lands first in Copilot CLI. On Windows, macOS and Linux, Copilot CLI supports configuring local models. Developers prepare the model files and an inference runtime themselves, then connect through a local OpenAI-compatible endpoint. After that they turn on experimental local routing in settings and choose Standard mode in Copilot Fusion. Only then can an eligible local model be considered for automatic assignment.

The Copilot desktop app works differently. It supports connecting to and manually picking compatible local models through bring-your-own-key (BYOK), but smart routing currently only supports models hosted by Windows ML. A local model that can be picked by hand in the desktop app is not automatically a model that Fusion will choose during routing.

The feature is still an experimental preview. Before depending on it for production work, check the client version, subscription tier, operating system, region and the latest support list in the official documentation.

Why a Reachable Endpoint Is Not Automatic Routing

Three states that get confused

A reachable local service only proves the network endpoint responds. A model Copilot can discover only proves it appears in the config file or the model list. Whether it reaches Copilot Fusion's automatic routing depends on the product surface, the model allowlist and the feature access attached to the account. GitHub names MAI Code 1.1 Flash and Qwen3.8 Flash Next as eligible examples. Exposing an OpenAI-compatible endpoint is not the same as Fusion calling that model on its own.

What to check before assuming anything

Confirm the routing mode actually selected in settings, confirm that the model appears on the official eligibility list rather than only in a local config, and confirm that the account and region have access to the preview. When any of the three is missing, the request stays on cloud models even though a local service is running and healthy.

Following a Single Task Through Three Stages

Take a request that asks the AI to change a date-formatting function, add unit tests and run the test command. The interface shows one input box. Behind it, the request loops through routing, inference and tool execution repeatedly.

Cloud routing selects the model

Copilot Fusion weighs eligible local models against cloud models using its own evaluation logic. This update enlarges the candidate pool on the local side. The router itself stays in GitHub's cloud.

Model inference produces the code

If routing sends the request to a local model, code generation runs on local hardware. If it goes to a cloud model, the compute happens in the cloud. Local inference tells you where the model computes. It says nothing about where the rest of the interaction happens.

Tool execution changes the project

Reading local files, writing code changes and launching a terminal to run tests all depend on specific tools. A model that suggests running the tests in plain text and a system that actually launches the test command are two different actions. Tools may only read and write local files, or they may reach a remote repository, pull third-party packages or call external network APIs.

The real path of an AI coding task therefore runs from cloud routing to local or cloud inference to tool execution. Most confusion about local AI coding tools starts here. Where the model runs only describes the inference stage. Who picks the model and what the tools reach have to be checked separately.

Where a Task Stops When the Connection Drops

Three ways to invoke a local model

If requests go straight to the local inference service without the client, you can check whether that service handles input without internet access. That only proves the underlying model service runs offline. If a local model is chosen manually inside the Copilot client, account authentication, session state and other supporting services still need checking. If Copilot Fusion's automatic routing is in play, cloud routing is a gate that cannot be routed around. GitHub has confirmed that even with a local model handling inference, the Fusion session does not become fully offline.

A three-run test matrix

Build a small isolated project with made-up data, fix the prompt and run the same flow three times.

1. Internet connected, local inference service running.
2. Internet connected, local inference service manually stopped.
3. Internet physically disconnected, local inference service kept running.

Comparing where errors surface across the three runs shows whether the network dependency sits in routing, inference or tool execution. Keep the second and third runs separate. The second mainly tests how the client behaves when the local inference service is missing. The third tests how much cloud routing and the supporting tools depend on the network.

Five checkpoints to record

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 appears. Until targeted tests are done, leave room for verification on a few concrete behaviors rather than drawing conclusions. Whether in-flight requests finish after the connection drops, whether the terminal returns a clear error code or triggers a fallback when the cloud routing request fails, whether the local toolchain continues unfinished steps while the local inference service stays alive, and whether an interrupted task resumes after reconnection or restarts from zero. All of these depend on client version, configuration, task complexity and tool dependencies.

Code Privacy and Cost Are Separate Questions

What may leave the machine

Many teams adopt local models for compliance and privacy. The privacy boundary is not only about where the model weights sit. A complete coding task involves prompts, project context, code file contents, tool output and diagnostic logs. Each field needs checking against what gets packed into cloud routing requests, what stays with the local model and what telemetry reaches cloud logs.

What is known is that Copilot Fusion makes routing decisions in the cloud. GitHub's announcement has not fully disclosed the payload of each routing request, so a team can neither claim that full code is definitely uploaded nor assume the cloud receives only metadata. Tool execution adds its own outbound traffic through dependency installation, external API calls for testing, and reads and writes against remote Git repositories. For projects with strict confidentiality requirements, a local model is not a privacy shield until three things are confirmed. What input goes to the cloud, what the routing logs retain, and whether tools reach external services.

Adding up the total cost

Local compute does not cut costs in a straight line. A team's total has at least three parts. The base Copilot subscription, the cloud model quota consumed, and 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 a Copilot chat quota depends on GitHub's billing rules. If a multi-turn conversation switches back to a cloud model midway, those cloud calls need their own accounting.

Local model efficiency is not only raw generation speed either. Cold-start model loading, long-context prefill, tool call time and rework caused by bad code changes all extend the time to a finished task. Without same-condition tests and billing records, track end-to-end metrics per task. 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.

Running the Boundary Test with an Isolated Project and ServBay

Set up the sandbox

No real business repository is needed. Create a small project containing only fictional data, then lock three variables in place. The Copilot CLI version, the local model (MAI Code 1.1 Flash or Qwen3.8 Flash Next), and the inference service configuration. Give the AI one standard instruction. Change the project's date-handling function, add unit tests and run the test command automatically.

Record the five checkpoints during both the online and offline states. Never use real API keys, private business code or production data during testing, and scrub account tokens and local absolute paths before publishing any log or screenshot.

Where ServBay fits

ServBay is an AI development management tool that can host the environment side of this test. Its AI Gateway puts every model and key behind one endpoint, accepting official provider APIs, subscription accounts and third-party relay services, and it converts between the OpenAI, Anthropic and Gemini protocols so a client speaking one protocol can reach a model that speaks another. Ollama models run through the same endpoint.

Two details matter for the verification work above. Virtual keys are issued per project while the real upstream keys stay encrypted locally and are never uploaded, which keeps test credentials away from the actual production keys. Usage and cost are tracked per project in real time, so the quota and cost numbers collected during the three runs have a place to land next to the model status, routing response, tool call and network error records.

A switcher answers which provider to use. A gateway answers how traffic moves. That distinction is what separates a routing layer from an access layer, and it is worth keeping in mind when a vendor describes either one.

How to Evaluate Any Tool That Claims Local Model Support

This Copilot Fusion update brings local models into smart routing in an official capacity. The technical change is specific. Copilot CLI can configure local models and connect compatible services across major operating systems, and the desktop app can connect to and select some local models. The limits are just as specific. 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 assessing any AI coding tool that advertises local model support, the question is not whether the weights run on a local disk. Follow the task chain instead. Who chooses the model, which steps require the network, what the tools touch in the background, and how quota and cost are counted. Run the chain once in an isolated environment and the relationship between local inference, cloud routing and tool execution stops being a marketing claim.