Microsoft outlines planned local and cloud routing for GitHub Copilot

Microsoft outlines planned local and cloud routing for GitHub Copilot

Microsoft’s October 7, 2026 article describes a plan for GitHub Copilot to route tasks between on-device and cloud models. Microsoft set late October 2026 as the target for Copilot Auto, which is intended to make that choice using task context and cache state across a multi-turn session.

GitHub has also described planned automatic discovery of installed local models, including models served through Ollama and Microsoft Foundry Local. Its announcement presents simple requests, codebase explanations and background automations as examples of work intended for local processing. That would put model selection in Copilot’s hands rather than the user’s—but routing could still involve cloud inference.

Manual BYOK and Copilot Auto put model selection in different hands

With BYOK (“bring your own key”), you configure a provider or select a model yourself. Copilot Auto, by contrast, is planned to choose between local and cloud inference based on the task and session context. Microsoft’s description does not make Auto an offline setting: its planned routing can use cloud models.

GitHub presents local routing as a way to use local compute for some work without AI-credit use. Local inference still uses your hardware and electricity, though; avoiding cloud-model credits does not make the computation resource-free.

What GitHub documents for local Copilot CLI models

GitHub’s Copilot CLI BYOK documentation lists the openai, azure and anthropic provider types. The openai type supports OpenAI Chat Completions-compatible endpoints, including Ollama, vLLM and Foundry Local. These details apply to Copilot CLI; they do not establish identical requirements across the Copilot app and Visual Studio Code.

For a local Ollama setup, GitHub’s example sets COPILOT_PROVIDER_BASE_URL to http://localhost:11434 and COPILOT_MODEL to the identifier of an installed model. An API key can be omitted when the local endpoint does not require authentication.

The model must support tool calling and streaming for Copilot CLI. GitHub recommends a context window of at least 128k tokens for best results. Tool calling lets the model request actions through available tools; streaming delivers its response as it is generated.

Local inference does not automatically mean offline use

In Copilot CLI, COPILOT_OFFLINE=true prevents the client from contacting GitHub. It does not block a separately configured remote model provider: that service can still receive prompts and code context. To keep that model traffic local, the provider itself must be local or inside the same isolated environment.

Copilot Auto’s planned routing is a separate design. Because it can choose cloud inference, it is not an offline guarantee. The practical distinction is straightforward: the offline switch controls connections to GitHub, while the provider’s location determines where model requests go.

Model location and tool sandboxing are separate controls

Running inference locally does not, by itself, restrict what an agent’s tools can access. Microsoft describes sandboxing as a separate control, with different boundaries for different tool types when sandboxing is enabled.

Shell commands and, by default, local Model Context Protocol (MCP) and language-server processes run inside a process boundary. Copilot’s built-in file tools are checked against policy inside Copilot rather than isolated as operating-system child processes. Remote MCP servers sit outside the local process sandbox; where MCP sandbox controls apply to those servers, Copilot checks their connection policy in process.

Sandbox backends Microsoft names by operating system

Microsoft identifies these local backends for process sandboxing and says they do not require a separate virtual machine or container image.