GitHub Copilot CLI with Ollama: Use Local Models in Your Terminal

Introduction

If your code cannot leave the building, or you are just tired of cloud latency and rate limits, you can run GitHub Copilot CLI against models served locally by Ollama. This tutorial shows you the whole flow on your own machine: installing both tools, pulling a model that can actually drive an agentic CLI, discovering it with the CLI’s /model command, wiring it manually with environment variables when you need reproducible setups, and understanding what “local” does and does not buy you for privacy.

Quick answer

In Copilot CLI 1.0.94-0 or newer, start Ollama, pull a model that supports tool calling and streaming, then type /model in the CLI and add the discovered Ollama model for the session.

Evidence

Local-model support in Copilot CLI is very new, so dates matter. GitHub shipped local-model discovery in Copilot CLI version 1.0.94-0 on 2026-10-07 (as of October 2026, the current documented behavior). Before this release, the only way to use a local model was manual environment-variable wiring, which still works and is covered below.

Ollama’s own integration documentation for Copilot CLI recommends a context window of at least 64k tokens for the model you choose, and points readers to its context-length documentation for adjusting it (as of October 2026). That number is the reason many small default pulls fail: an 8k-context model will break the moment your repo gets interesting.

The official GitHub changelog describes the discovery flow this way: “Discovery doesn’t automatically add models.” You choose a discovered model, review its provider and endpoint, then confirm Add and use for this session or Add without switching, and you can use the model in your current session without restarting the CLI. Two hard prerequisites apply: Ollama and the model must already be installed, since this flow doesn’t install a runtime or download models, and discovered models must support tool calling and streaming.

A subtle point from the same changelog is worth quoting in paraphrase: choosing a local model does not turn on offline mode and does not disable GitHub telemetry. Offline mode in the CLI is an explicit choice through COPILOT_OFFLINE=true, and a remote provider can still receive prompts and code context over the network even in offline mode. Read the GitHub changelog entry for local model discovery for the full wording, and the Ollama Copilot CLI integration doc for the manual wiring that the discovery flow builds on.

Prerequisites

• A computer with at least 16 GB of RAM (local coding models are hungry; 32 GB is noticeably better).
• GitHub Copilot CLI installed, version 1.0.94-0 or newer for /model discovery.
• Ollama installed and running, plus one pulled model with tool calling and streaming support (for example qwen2.5-coder:7b).
• A GitHub account with Copilot access for the CLI’s cloud features and telemetry path.
• Basic comfort with the terminal; familiarity with the GitHub Copilot local sandboxing tutorial helps if you later want to restrict what the local agent can touch.

Step-by-step guide

Step 1: Install Copilot CLI and check the version

Install the CLI with npm (Homebrew, WinGet, and script installers are also available):

npm install -g @github/copilot

Verify you have a version that includes /model discovery:

copilot --version

You need 1.0.94-0 or newer. If your version is older, update with npm update -g @github/copilot and check again. Without the minimum version, /model will not discover local models at all, and you will be stuck wondering why the picker is empty.

Step 2: Install Ollama and pull a capable model

Install Ollama from the official site or with your package manager, then start the server:

ollama serve

Pull a coding model with tool-calling support. qwen2.5-coder:7b is a solid default used in Ollama’s own Copilot CLI documentation:

ollama pull qwen2.5-coder:7b

Confirm it is available:

ollama list

You can also verify Ollama’s API is listening on its default port with a quick call:

curl http://localhost:11434/api/tags

A JSON list of your pulled models confirms the server is up. Note the port: 11434 is where every later step expects Ollama to answer.

Step 3: Discover the model with /model

Launch the CLI in your project directory:

copilot

Inside the session, type:

/model

The picker lists supported models from your running Ollama instance alongside your configured models and the cloud models provided by GitHub Copilot. Select the Ollama model, review its provider and endpoint carefully, then confirm Add and use for this session to switch immediately, or Add without switching to register it while staying on your current model. There is no restart involved either way.

If a provider connection fails, the picker shows the failure with an explanation instead of silently dropping the model. Read that message first; it usually points straight at the problem (see Troubleshooting).

Step 4: Verify the local model can actually drive the agent

Ask the CLI to do something that requires tool calls, not just chat. For example:

Refactor the retry loop in src/http.ts to use exponential backoff, then run the test suite and report which tests fail.

Watch the output: a healthy setup streams its reasoning and shows tool invocations (file reads, edits, shell commands) interleaved with the answer. If the model answers in prose but never touches files, it probably lacks real tool-calling support, and you should switch to a larger coding model. Ollama’s docs are explicit that Copilot expects strong tool support, and small models that fail tool calls should be reserved for chat and small edits.

Step 5: Wire it manually with environment variables (reproducible setups)

The /model flow is interactive. For scripts, CI runners, or Docker containers, set the provider explicitly using Ollama’s OpenAI-compatible API, exactly as documented in Ollama’s integration doc:

export COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1
export COPILOT_PROVIDER_API_KEY=
export COPILOT_PROVIDER_WIRE_API=responses
export COPILOT_MODEL=qwen2.5-coder:7b
copilot

Or inline for a single run:

COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1 COPILOT_PROVIDER_API_KEY= COPILOT_PROVIDER_WIRE_API=responses COPILOT_MODEL=qwen2.5-coder:7b copilot

This is the same pattern that older community guides used before /model discovery existed, and it remains the recommended route for anything non-interactive. The empty API key is intentional: Ollama on localhost does not require authentication.

Step 6: Understand offline mode before you rely on it

If your goal is a network-isolated agent, add the explicit offline flag:

COPILOT_OFFLINE=true copilot

Then confirm the privacy boundary honestly: GitHub’s changelog states that choosing a local model does not disable telemetry, and that a remote provider can still receive prompts and code context over the network even in offline mode. For real isolation, pair the local model with the sandbox restrictions from the GitHub Copilot local sandboxing tutorial and audit which providers are configured in the CLI. Local inference plus an explicit sandbox policy is a much stronger story than local inference alone.

Step 7: Keep cloud fallback one command away

Intelligent routing between local and cloud models was announced on the Microsoft Command Line blog alongside the /model release, but GitHub asked readers to stay tuned for availability, so as of October 2026 it is not something you can turn on. Until it lands, the pragmatic pattern is manual: use /model to add the discovered Ollama model, and switch back to a cloud model in the same picker when you need stronger reasoning. For a different flavor of local agency entirely, the GitHub Copilot computer use tutorial covers driving applications on your desktop with local models.

Troubleshooting

1. /model shows no local models

Check three things in order. First, is Ollama actually running? curl http://localhost:11434/api/tags should return your model list; if it refuses the connection, run ollama serve. Second, did you pull a model at all? Discovery never downloads anything. Third, does the model support tool calling and streaming? Models that fail either requirement are excluded from the picker, and provider connection failures appear in the picker with an explanation, so read that line before assuming the feature is broken.

2. The model chats but never calls tools

This is the classic symptom of a model without real function-calling support. Small general-purpose chat models often produce text that looks like a tool call but never emits a valid one. Fix: pull a coding model known for tool support such as qwen2.5-coder:7b, re-add it via /model or the COPILOT_MODEL variable, and re-run a task that forces tool use. If the model still only chats, it is not suitable for agentic work in this CLI; keep it for Q&A and pick a larger model for edits.

3. Context window errors on real repositories

Ollama’s docs recommend at least 64k tokens of context for Copilot. If you see truncation errors or the model starts hallucinating file contents, your model is running with too small a context. Adjust Ollama’s context length (the num_ctx parameter) following Ollama’s context-length documentation, and consider a model with a natively large window. This is the single most common failure when moving from toy demos to real codebases.

4. Copilot CLI feels sluggish on a local model

Local inference speed depends on your hardware, the model’s quantization, and how much context you feed it. Start in a small directory rather than your monorepo root, keep the context window modest, and prefer quantized variants of coding models. If the CLI consumes a lot of tokens per task, as community guides warn, that is normal agentic behavior; the fix is a faster model or a bigger GPU, not a config flag.

5. “Local” setup still sends data somewhere

If you assumed local inference meant nothing leaves the machine, re-read the changelog: GitHub telemetry stays on, offline mode is opt-in via COPILOT_OFFLINE=true, and a remote provider can still receive prompts and code context even in offline mode. Audit the providers configured in your CLI, remove any remote providers you do not want, and treat COPILOT_OFFLINE=true as necessary but not sufficient for air-gap-grade isolation.

FAQ

Does using a local Ollama model make GitHub Copilot CLI fully private?

No. Choosing a local model changes where inference happens, but GitHub’s telemetry stays on. Offline mode is a separate, explicit choice made with COPILOT_OFFLINE=true, and GitHub warns that a remote provider can still receive prompts and code context over the network even in offline mode.

Which Ollama models actually work with Copilot CLI?

Any model that supports tool calling and streaming. Ollama’s integration docs use qwen3.5, glm-5:cloud, and qwen2.5-coder:7b as examples, and recommend at least 64k tokens of context. If a small model fails tool calls, use it for chat and small edits, or switch to a larger coding model.

Does /model discovery install Ollama or download models for me?

No. Ollama and the model must already be installed before you run /model, because the discovery flow does not install a runtime or download weights. If nothing is discovered, the first thing to check is that ollama serve is running.

Can I point Copilot CLI at a provider other than Ollama?

Yes. The manual setup wires Copilot CLI to Ollama through its OpenAI-compatible API using COPILOT_PROVIDER_BASE_URL, COPILOT_PROVIDER_API_KEY, COPILOT_PROVIDER_WIRE_API, and COPILOT_MODEL. The same pattern works for any OpenAI-compatible endpoint, so LM Studio, vLLM, or a proxy can be substituted.

What is intelligent routing with local models?

GitHub announced intelligent routing with local models alongside the /model discovery release on the Microsoft Command Line blog. GitHub said to stay tuned for availability, so as of October 2026 it is announced but not yet generally available.

Do I need to restart Copilot CLI after adding a discovered model?

No. You can use a discovered model in your current session without restarting the CLI. Choose “Add and use for this session” to switch immediately, or “Add without switching” to register the model and keep your current one.

Conclusion

Copilot CLI 1.0.94-0 turned local models from a hand-wired hack into a first-class picker entry: start Ollama, pull a tool-calling model, type /model, and you are coding with local inference in the same terminal. The manual environment-variable route from Ollama’s integration docs remains the right tool for automation, and an honest read of the offline-mode caveats keeps your privacy story accurate. As a next step, pair your local model with sandbox restrictions in the GitHub Copilot local sandboxing tutorial, or compare how other frameworks use local models in the n8n Ollama AI agent tutorial.

Frequently asked questions