Copilot CLI local model discovery: verify the endpoint and active session

Establish what the update actually provides

The October 7 release note introduces local discovery from CLI 1.0.94-0. Ollama and its model must already be installed and running; the flow installs neither. After reviewing a discovered model, choose Add and use for this session or Add without switching.

The provider documentation requires tool calling and streaming. A model answering an ordinary chat question does not establish those capabilities. This article neither prescribes a universal model nor reports performance testing on your device.

Record four different states

Prepare a bounded pilot environment

Editorial advice: use a separate sample directory and fictional text without keys, customer material or production code. Record CLI version, service state, model identifier and endpoint first. Retain any connection-failure explanation in the picker. Check service state and address before widening restrictions.

Inference location is separate from file and network access. The Windows agent-boundary guide explains scope checks. This article does not configure MXC or treat a local model as a sandbox.

1. 1
   Enter /model in an installed, compatible Copilot CLI session and inspect the running Ollama candidates.
2. 2
   Check that provider and endpoint belong to the intended service. A familiar model name is insufficient.
3. 3
   Choose Add and use for this session to test now, or Add without switching to save configuration. Record what the current session still uses.
4. 4
   Run the sample below and inspect both response and active-session state. If required tool capabilities are missing, record incompatibility or unresolved status rather than accepting an ordinary text reply as a complete agent test.

Use a request whose answer you can verify yourself

This original request and rubric are not a measured model result. The prompt specifies line-by-line output without browsing, file writes or shell execution. If the client calls tools anyway, inspect why and review its permission record. A response claiming local execution does not establish the actual provider.

Read only the three supplied rows. Do not use tools, browse, run commands, or write files.
Rows:
A01 | ready
A02 | pending
A03 | ready
Return ready IDs in source order, one per line. Do not add other text.

Retain any output that adds A02, omits A03 or changes order, then reduce the task to locate the failure. Correct text and the correct endpoint need separate evidence.

Local selection and offline operation are different choices

The release note says local selection does not automatically enable offline mode or disable GitHub telemetry. The explicit offline choice is COPILOT_OFFLINE=true. The provider documentation explains that a remote provider still receives prompts and code context over the network even with offline mode enabled.

Editorial advice: record the actual endpoint and permitted connections, not just the model name. A remote endpoint, network-using tool or another session restoring older configuration can change the boundary. Review organizational rules and network evidence for a controlled environment; this guide does not promise absolute disconnection.

Keep a session record that can be repeated

Record the time, CLI and model versions, addition choice, active selection, endpoint and complete output. Reuse the sample after changing a model or service. The release also mentions intelligent-routing announcements; discovery alone does not establish routing availability on your account or device.

For multistep work, check processed input and traceable results as well. The completion-versus-document-coverage guide supplies an acceptance principle for another product, not a claim that Copilot has identical APIs.