GitHub Copilot CLI can discover Ollama models without making the session offline

Starting with Copilot CLI version 1.0.94‑0, the /model picker can discover supported models from a running local Ollama instance, according to GitHub's October 7 changelog. Discovered entries appear alongside configured providers and models supplied by GitHub Copilot.

The picker does not install Ollama, download a model or add every discovered entry automatically. Ollama and the model must already be installed and running. GitHub also says the model needs tool calling and streaming, which excludes a model that can only return plain text.

The operational improvement is fewer configuration steps for a compatible local runtime. The trust decision remains explicit: select the entry, inspect its provider and endpoint, then choose either Add and use for this session or Add without switching. The selected model can be used without restarting the CLI.

Discovery proves that the picker found an advertised model. It does not prove the model follows Copilot's tool schema, streams reliably, fits available memory or produces acceptable edits. GitHub surfaces provider connection failures in the picker, but successful connection is only the first gate. Use a bounded acceptance task after adding a model: ask it to inspect a small fixture, call one read‑only tool, propose an edit and stop before mutation. Record the model identifier, endpoint, context limit, tool‑call result and peak runtime resource use. Then test a malformed or unavailable tool response so that a plausible text answer is not mistaken for functioning agent control. For larger repositories, add a context‑pressure test. A model that works on one file may fail when the prompt includes repository instructions and tool results. Keep the cloud model available until the local path passes the same completion checks.

GitHub explicitly says choosing a local model does not turn on offline mode or disable GitHub telemetry. In Copilot CLI, offline mode is a separate choice through `COPILOT_OFFLINE=true`. GitHub also warns that a remote provider can still receive prompts and code context over the network even when offline mode is enabled. That wording matters because “offline” describes Copilot CLI's behavior, not the physical location of every configured endpoint. A provider URL can point to localhost, a private‑network server or a remote API. The [BYOK model guide](https://docs.github.com/en/copilot/how‑tos/copilot‑cli/customize‑copilot/use‑byok‑models) groups Ollama with OpenAI‑compatible endpoints, so the actual destination must be inspected. Before using sensitive code, verify the resolved endpoint and observe network behavior in a controlled session. If the goal is a fully local path, deny unrelated network destinations and confirm the task still completes. Do not rely on the model's display name as evidence of locality.

Copilot CLI's [programmatic reference](https://docs.github.com/en/copilot/reference/copilot‑cli‑reference/cli‑programmatic‑reference) supports `--model`, allow and deny lists for tools and URLs, path grants and JSON output. Those flags make an automated local‑model test reproducible, but only when the chosen model identifier is recorded and available in that execution context. A safe automation probe pins the model, permits only the fixture path and one read tool, denies unneeded URLs, and emits structured output. Avoid `--allow‑all` during qualification because it removes the evidence that the local model can work inside the intended boundary. If the provider is unavailable, fail the run instead of silently changing to a cloud model. For workflows involving an [MCP server](https://opentools.ai/mcp), test the server separately from model discovery. A local model may still direct a local tool that reaches external services, so model location and tool network behavior belong in different columns of the review.

Keep one row per local model with the exact model ID, runtime version, endpoint class, tool‑calling and streaming result, context test, network result and approved task types. This turns discovery into an operational choice rather than a long picker list. Start with low‑risk tasks whose expected result is known. If a model fails tool use, keep it available for plain‑language work only or remove it from the agent workflow. If it passes, add one realistic repository task and compare rework with the existing model. No single local benchmark establishes general coding quality. GitHub says intelligent routing with local models is announced separately and asks users to wait for availability. Do not describe that as active routing in the current CLI discovery feature. Follow [GitHub's OpenTools organization page](https://opentools.ai/organizations/github) for later updates. *Figure: The three‑stage path from Ollama discovery to an accepted Copilot CLI model. Sources: [GitHub's discovery announcement](https://github.blog/changelog/2026‑10‑07‑discover‑local‑models‑in‑github‑copilot‑cli/), the [BYOK model guide](https://docs.github.com/en/copilot/how‑tos/copilot‑cli/customize‑copilot/use‑byok‑models) and [programmatic CLI reference](https://docs.github.com/en/copilot/reference/copilot‑cli‑reference/cli‑programmatic‑reference). Figure by OpenTools Team; no third‑party expressive material used.*