GitHub Copilot CLI Can Now Discover Local Ollama Models: What It Does and Doesn't Mean for Offline Use

Bottom line: Copilot CLI 1.0.94-0 can discover a running local Ollama model from the /model picker. That is not the same as offline mode, which still requires COPILOT_OFFLINE=true, and if you choose a remote provider your prompt is still sent to that provider.

Discovery and offline mode are different switches. GitHub’s October 7 changelog says that starting in Copilot CLI 1.0.94-0, /model can discover supported models from a running local Ollama instance, next to your configured models and the cloud models Copilot already lists. The same note says choosing a local model does not turn on offline mode, and does not disable GitHub telemetry. Offline mode is still an explicit environment variable: COPILOT_OFFLINE=true.

We already wrote a router that picks a workflow, not a machine. HydraFusion’s September preview cut cost on the benches and beat Opus on one of them. We already wrote a local Gemma path that still needed a runtime. Antigravity’s SDK for Gemma 4 is that stack. We already wrote a small-model price that was not the average saving. Haiku 5.5’s $0.10 line is a different cut from the 75 percent figure. This week’s CLI note is a fourth shape. It is a picker change. It is not Auto, and it is not a promise that the prompt stayed on the laptop.

/model lists a running Ollama. It does not install one.

The October 7 steps are short, and the negations are the part worth pinning up. Ollama has to be running. The model has to already be installed. The flow does not install a runtime, and it does not download weights. Models must support tool calling and streaming. If those conditions are not met, discovery is not a repair tool. It is a list of what the running daemon is willing to show.

You open /model. Supported models from that local Ollama instance appear alongside configured models and Copilot’s cloud models. Discovery does not add them by itself. You pick a discovered model, you review the provider and the endpoint, and you confirm either Add and use for this session or Add without switching. The first option changes the session model. The second adds it and leaves the current model in place. GitHub says you can use the added model in the current session without restarting the CLI. “Without restarting” is about the CLI process. It is not about Ollama. If Ollama was not running when you opened the picker, the changelog does not say the picker will start it.

Provider connection failures show up in the picker with an explanation. That is the failure mode the note bothers to name. It does not print the explanation strings. If your picker says the endpoint refused the connection, you are in the case the changelog pointed at. If your picker is simply empty of local models, the note’s preconditions are the first place to look: daemon running, model already pulled, tool calling, streaming.

The Copilot app is a different surface in the same note. You add a supported provider under Settings > Model providers. The CLI discovery flow and the app’s provider screen are “the same idea,” in GitHub’s words, not the same keystrokes. The October 9 weekly release note restates the CLI half and links back to the October 7 post. It does not add a new flag. If you are on a CLI older than 1.0.94-0, the weekly note does not say the picker grew this feature anyway. The version floor is in the October 7 post. The weekly note assumes it.

A local model and COPILOT_OFFLINE=true are not the same switch

GitHub’s sentence is the one to keep next to the command. Choosing a local model does not turn on offline mode, and does not disable GitHub telemetry. Offline mode remains COPILOT_OFFLINE=true. A remote provider can still receive prompts and code context over the network, even in offline mode. Read that twice. Offline mode, in the CLI note, stops a class of GitHub contact. It does not stop a remote model provider you configured yourself.

NeoTeo’s October 8 account, published in the search index on October 9, says the same split in operational language. COPILOT_OFFLINE=true prevents contact with GitHub. If the configured model provider is remote, that provider still receives prompts and code context. NeoTeo is not GitHub.

That extra setup, in NeoTeo, is how you point the CLI at a local Ollama without using the new discovery picker. Set COPILOT_PROVIDER_BASE_URL to http://localhost:11434. Set COPILOT_MODEL to the identifier of a model you have installed. Start copilot. An API key is not needed when that local service does not require authentication. The October 7 discovery flow is a picker on top of a running Ollama. The environment variables are a configured provider. NeoTeo says the CLI BYOK provider types are openai, azure, and anthropic, and that the openai type also works with Ollama, vLLM, Foundry Local, and other OpenAI Chat Completions-compatible endpoints. The changelog links it: use your own model in Copilot CLI.

NeoTeo also says a CLI model must support tool calling and streaming, which matches the October 7 discovery note, and that GitHub recommends a context window of at least 128k tokens for best results. “At least 128k” and “best results” are a recommendation in NeoTeo’s telling. The changelog’s hard line is tool calling and streaming. A model under 128k that still streams and calls tools is a case the changelog does not close.

VS Code, still in NeoTeo’s account, is a third surface. Open the chat model picker, choose Manage Language Models, add a provider or a compatible endpoint. NeoTeo says VS Code sends Ollama users to the official extension because the built-in Ollama provider is deprecated. That deprecation is not in the October 7 CLI changelog. Do not paste it into a CLI runbook and attribute it to GitHub’s CLI post. It belongs, if you are in VS Code, to the account NeoTeo is giving of the editor path.

The offline split inside VS Code is sharper than the CLI’s, in that same NeoTeo piece. VS Code can do fully offline BYOK chat with a local model, without a GitHub account and without a Copilot plan. Inline suggestions, semantic search, and features that rely on embeddings still require a GitHub account. Local chat and inline completions are not one offline bundle. A laptop that answers in chat with no network can still refuse the ghost text, and the refusal is not a broken Ollama. It is a feature that NeoTeo says still wants the account.

Auto at the end of October is not this picker’s job

The October 7 changelog announces intelligent routing with local models and points at a Microsoft Command Line blog post. The verb is announce. The next sentence is “stay tuned for availability.” Discovery in /model is available from CLI 1.0.94-0, in that same post. Routing is not given a date there.

NeoTeo, writing about October 8, says Microsoft described Copilot Auto as a planned way to route work between local and cloud models, with an end-of-October 2026 target, across Copilot CLI, the Copilot app, and Visual Studio Code. BYOK, in that account, is the path where you configure a provider or select a model. Auto is the path where Copilot is intended to choose local or cloud inference from task context and cache state across a multi-turn session. Those are different hands on the switch. The October 7 picker is closer to the first. You review the endpoint and you confirm add-and-use or add-without-switching. Nothing in that flow says the CLI scored the prompt and moved it.

GitHub printed “stay tuned.” NeoTeo printed a target. A target in a secondary writeup and a “stay tuned” in the changelog can describe one plan. They are not the same commitment. If October 31 arrives and /model still only discovers, the discovery feature has not failed. The routing announcement has not become a switch. The weekly note on October 9 does not close the gap. It repeats discovery. It does not say Auto shipped.

HydraFusion, which this site already covered as a research preview, is a different router again. That one builds a workflow across cloud models. It is not the local-versus-cloud Auto NeoTeo is describing, and it is not the Ollama row in /model. If a session is on HydraFusion and you expected the prompt to hit localhost, you picked the wrong row. The October 7 note does not say HydraFusion consults Ollama.

The sandbox is a tool boundary, and the model does not move it

The same morning, GitHub published a second changelog: local sandboxing is generally available. It is GA in Copilot CLI, the Copilot app, and VS Code sessions that use Agent Host. The October 9 weekly note repeats that list and says it is included with Copilot at no extra cost. “No extra cost” is about the sandbox feature. It is not a statement about what a BYOK provider bills you. GitHub is not the meter on a model you brought.

The sandbox, in GitHub’s words, restricts tools and commands Copilot initiates: filesystem, network, credentials, and other system capabilities, based on policies you or your organization defined. It is powered by Microsoft eXecution Container, which translates one policy into native controls on Windows, macOS, and Linux. The capability list in the changelog is concrete. Limit which files and directories agent-run commands can read or modify. Control access to the internet, local networks, Git credentials, and GitHub CLI credentials. Apply the sandbox to local tools and services, including local MCP and language servers where supported. Enterprise settings can require sandboxing and block developers from weakening the policy.

Then the sentence that keeps the model out of it. “Model execution and tool isolation are separate concerns. Sandbox policies apply to tool execution regardless of which model Copilot uses.” A local Ollama model does not tighten the sandbox. A cloud model does not loosen it. The policy is on the tool, not on the weight file.

Shell commands and, by default, local MCP servers and language servers run inside a process boundary. Built-in file tools take a different path: the agent harness applies policy checks, rather than isolating those tools as operating-system child processes. Remote MCP servers sit outside the local process sandbox. Choosing a local model does not change those lines. If your threat model was “the weights are local, so the tools are local,” both GitHub and NeoTeo are telling you that is the wrong model. The weights’ location and the tool’s boundary are separate configuration.

For sandbox details, see GitHub’s About cloud and local sandboxes. If that page has a flag the two October 7 posts do not name, this tutorial does not have the flag. The posts are enough to stop the common merge: local model equals offline equals sandboxed. Three switches. CLI 1.0.94-0 adds a picker for the first. COPILOT_OFFLINE=true is the second, and it still lets a remote provider see the prompt. The sandbox is the third, it is GA on three surfaces, and it does not care which model you confirmed in /model.

What this means for you

If data residency matters to your team, document both settings explicitly: which model is selected and whether COPILOT_OFFLINE is set. Verify with a network monitor during a test session rather than assuming that a local model keeps every request on the machine.