GitHub Copilot CLI can now find models in a local Ollama instance and add them to a session from the /model picker without a restart. The useful detail for teams is what it does not do: picking a local model does not switch on offline mode or turn off GitHub telemetry, so data handling needs its own setting.
What was released
Local model discovery in GitHub Copilot CLI was announced by GitHub on 7 October 2026 in the GitHub changelog. It ships from CLI version 1.0.94-0. In the same entry GitHub mentioned intelligent routing with local models, announced on the Microsoft Command Line blog, with availability still to follow, so that part is not something teams can use yet.
What actually changed
Copilot CLI already let teams configure their own model provider; what is new is discovery. According to the announcement, the /model command now lists supported models from a running local Ollama instance next to your configured models and the cloud models GitHub provides. The details that matter:
- Nothing is added silently. You pick a discovered model, review its provider and endpoint, then choose to add it and use it for this session, or add it without switching.
- No restart. The model can be used in the current session straight away.
- No installer. Ollama and the model must already be installed; the CLI does not install a runtime or download models.
- Capability floor. Models must support tool calling and streaming, so a model that cannot call tools will not work as a coding agent here.
- Visible failures. If the provider cannot be reached, the picker shows the error and an explanation.
The Copilot CLI provider documentation linked from the announcement covers configuration and limits. The GitHub Copilot app already offers the same idea under Settings, Model providers.
Local is not the same as offline
This is the part most likely to be misread. GitHub states that choosing a local model does not turn on offline mode or disable GitHub telemetry. Offline mode in the CLI stays an explicit choice, set with the environment variable COPILOT_OFFLINE=true. GitHub also notes that a remote provider can still receive prompts and code context over the network, even in offline mode.
So a developer who switches to a local model because a repository is sensitive has changed where inference runs, not necessarily what leaves the laptop. If your reason for going local is data handling, the setting that matters is offline mode plus a check of which providers are configured, not the model choice alone.
What it means for teams building with AI agents
In CodeDTX's view, local model discovery lowers the effort of trying a local model, which makes a written policy more important, not less. Practical steps:
- Decide why you want local models. Cost, latency on small tasks, and keeping code on the machine are different goals. Our guide to running an AI agent on a self-hosted model covers the trade-offs that apply here too.
- Pair local models with offline mode where data is the reason. Set COPILOT_OFFLINE=true in the environments that handle sensitive repositories, and remove remote providers that should not see that code. Map this against your data residency rules for AI agents.
- Test the model on agent work before adopting it. Supporting tool calling is the entry bar, not proof the model will plan and edit code well. Run the same tasks you use for cloud models, as described in what AI agent evals catch.
- Keep tool access governed separately. Changing the model does not change what the agent's commands can reach. Use Copilot local sandboxing to limit files, network and credentials whichever model is selected.
- Record which model produced a change. With cloud and local models in one picker, note the model in review or audit records so a weak result can be traced.
When not to switch
Do not move a team to local models just because the picker makes it easy. If laptops lack the memory or GPU to run a capable model, quality and speed will drop. If your models do not handle tool calling well, agent sessions will fail in ways that look like Copilot problems. And if the goal is to keep code private, a local model without offline mode and a provider review does not achieve it. Intelligent routing between local and cloud models is announced but not yet available, so plan around manual selection for now.
Frequently asked questions
Which local models can GitHub Copilot CLI discover?
From CLI version 1.0.94-0, the /model command lists supported models from a running local Ollama instance. Ollama and the model must already be installed, because the CLI does not install a runtime or download models. The model must also support tool calling and streaming. Discovered models are not added automatically; you review the provider and endpoint and confirm before the model is used.
Does using a local model keep my code on my machine?
Not on its own. GitHub states that choosing a local model does not turn on offline mode or disable GitHub telemetry. Offline mode is set separately with COPILOT_OFFLINE=true, and GitHub notes that a remote provider can still receive prompts and code context over the network even in offline mode. Review which providers are configured if keeping code local is the goal.
Do I need to restart Copilot CLI to use a discovered model?
No. After you pick a discovered model in /model and review its provider and endpoint, you can choose to add it and use it in the current session, or add it without switching. Either way the CLI does not need a restart. If the local provider cannot be reached, the picker shows the connection error with an explanation of what needs attention.
Is intelligent routing between local and cloud models available?
Not yet. In its 7 October 2026 changelog entry, GitHub said intelligent routing with local models was announced on the Microsoft Command Line blog and that availability will follow. Until it ships, teams choose the model themselves in the /model picker, so any policy about which work runs on local models has to be followed by developers rather than enforced by routing.
