GitHub adds on-device models to Copilot, but sessions still route through the cloud

What GitHub announced

According to a dev.to article, GitHub used an October 28 announcement to bring on-device models into Copilot. The capability sits inside Copilot Fusion, an opt-in experimental routing preview, and covers supported local models in Copilot CLI, the Copilot app, and VS Code.

Setup differs depending on environment: the article draws a distinction between a managed Windows configuration and manually configured providers that administrators wire up themselves. It also separates two modes of use — directly selecting a local model, and letting Fusion decide at runtime between local and cloud models. The author argues these describe different operating arrangements, and that neither label on its own tells you how a request actually flows.

The catch: local is not offline

The article's central warning is that reading "local" as "offline" would be a mistake. GitHub states explicitly that the session still uses cloud routing. A model running on the device answers only one question: where inference executes. The surrounding application may still reach remote services to choose the model, fetch context, invoke a tool, or handle a later turn of the conversation.

GitHub's Fusion documentation, as summarized in the article, presents Fusion as a system that selects models at runtime rather than pinning one model to every request. Local-model selection is described as a preview capability associated with Fusion Standard, and a model appearing in a picker is not automatically eligible for what the article calls "intelligent local routing." Teams therefore need to check the actually configured mode rather than assume.

An illustration of a hybrid boundary

To make the distinction concrete, the article points to a case study involving an archive application called Illumia. Records there are stored and searched locally in PostgreSQL, a Claude Desktop connection exposes six bounded, read-only retrieval tools, and selected evidence can be sent to online Claude only when the organization approves it. Notably, that project's own public description stops short of calling the workflow offline.

The lesson the author draws is that a hybrid system should be described in verifiable terms: where the archive lives, what retrieval is allowed to do, and where selected material may travel. Collapsing all of that into a single reassuring adjective hides the decisions that matter.

How to rehearse the boundary

The article sets out a testing procedure for teams evaluating such tools. Build a small throwaway archive with fictional records, including a distinctive harmless marker note plus an unrelated record that should stay out of scope. Ask a narrow question that only the marked note can answer, then inspect the retrieval result before anything goes online — checking that the evidence is sufficient and unrelated records are absent. Network diagnostics should be used to watch the request path, while keeping logs limited so that copied prompts do not create a second unintended destination.

The next step is to cut the external service off in that disposable environment and record what survives: whether local search still shows the source, and whether the assistant stops with an understandable message or silently waits while the operator assumes work is continuing. If a task was specified as fully offline, an external routing dependency fails the requirement even if inference itself would have run on the device.

The exercise is not one-and-done. It should be repeated after meaningful configuration or model changes, and a connection log alone cannot establish what a request contains or how it is handled contractually. The article also cautions against the opposite leap: the presence of cloud routing does not prove which record fields a product transmits. Documentation, configuration, and observation have to be combined rather than treating any one of them as complete evidence.

Why it matters

Putting local models inside Copilot makes on-device compute far more accessible, but it also makes the word "local" easier to over-trust. For organizations with privacy or compliance constraints, the useful purchasing question is not whether a product supports local AI, but whether its exact search, routing, inference, and tool path meets the intended operating boundary — and that boundary has to be tested, not assumed. Hybrid routing buys convenience at the cost of a larger, less controlled surface; a deliberately isolated workflow demands that a team operate and validate more of its own stack. One further caveat worth noting: the dev.to post itself carries a disclosure that it was generated and fact-checked with AI and published through an automated workflow without review by its named author, so readers may want to verify the details against GitHub's own documentation.