Originally published at kunalganglani.com — read it there for inline code, hero image, and live links.

Run Local LLMs in VS Code: No Copilot Plan [2026]

The VS Code Language Model Provider API is the built-in system that lets you register a model — cloud or local — directly into Copilot Chat's model picker, using your own API key or a local runtime instead of a hosted Copilot model. As of the June 18, 2026 release, you can run a local LLM in VS Code through the Language Model Provider without a CLI tool, without a third-party extension, and without ever signing into GitHub or paying for a Copilot plan. That last part is the headline most tutorials still miss.

Here is the thing nobody's saying about the wave of "local LLM in VS Code" content online: almost all of it predates this feature. Search today and you'll be handed a Continue.dev walkthrough or a terminal-agent setup, because those articles were written before Microsoft shipped Bring-Your-Own-Key (BYOK) and native Ollama support into the Chat picker and demoed it at the Build 2026 keynote. This post covers the native path instead — and it's the only walkthrough I've found that sets up both Ollama (a built-in provider) and LM Studio (a custom OpenAI-compatible endpoint) side by side, then explains why your model silently vanishes from Agent mode.

Key takeaways

• VS Code's native BYOK path runs local models in Copilot Chat with zero CLI, zero third-party extension, and zero Copilot subscription — your own runtime is enough.
• Ollama is a one-click built-in provider; LM Studio has no VS Code extension and is wired in as a custom endpoint at http://localhost:1234/v1.
• Local models power Chat and Agent workflows but not inline code completions — that autocomplete still needs a separate model source.
• A local model that doesn't declare toolCalling support gets silently excluded from Agent mode, and this is the single most common "why doesn't it work" trap.
• Restricted Mode, org policy toggles, and a stopped runtime are the three reasons your model won't appear in the picker.

If your local model can chat but vanishes the moment you switch to Agent mode, the model didn't fail — it just never told VS Code it can call tools.

What is the VS Code Language Model Provider API and BYOK?

Bring Your Own Key, or BYOK, is the VS Code feature that surfaces models from external providers — Azure, Anthropic, Hugging Face, Gemini, OpenAI, OpenRouter, or a local runtime — inside the same Chat model picker you'd use for a Copilot model. Underneath it sits the LanguageModelChatProvider extension API, which follows a clean one-provider-to-many-models design. A provider implements provideLanguageModelChatInformation to advertise each model's metadata, handles the actual chat requests, and reports token counts. That's the whole contract.

As Kayla Cinnamon, Product Manager on the VS Code team at Microsoft, laid out when the feature shipped, BYOK works entirely with your own keys or a local runtime — no GitHub account and no Copilot plan required, including fully offline scenarios. Microsoft demoed exactly this live on a Surface RTX Spark Dev Box during the Build 2026 keynote, running a model with no cloud round-trip at all.

The metadata each model declares matters more than it looks. Beyond the obvious fields — id, name, family, maxInputTokens, maxOutputTokens — a provider declares capabilities.toolCalling and capabilities.imageInput. Those two booleans decide whether the model is even eligible for Agent mode and whether you can paste an image into chat. Hold that thought; it's the root of the most confusing failure in the whole system.

This is the same mechanism whether you're plugging in a frontier cloud model or a 7B model quantized to fit your laptop. The entity to keep straight here is the Language Model Provider API itself — the plumbing — versus the two runtimes we'll actually wire into it, Ollama and LM Studio.

Run a local LLM in VS Code with the Language Model Provider: the 7-step version

If you just want the fastest path from nothing to a working local model in Copilot Chat, here it is as a clean sequence. The rest of the post expands each step and covers the failure modes.

1. Install Ollama from ollama.com and confirm it's running (it starts a local server on http://localhost:11434 by default).
2. Pull a model — ollama pull qwen3:8b or ollama pull llama3.1:8b are sane starting points on 16GB of RAM.
3. Open the Chat view in VS Code (latest version — this feature landed June 18, 2026) and click the model picker dropdown at the bottom of the chat input.
4. Choose "Manage Models" from the dropdown to open the provider flow.
5. Select Ollama as the provider — it's built in, so there's no extension to install and no key to paste.
6. Pick your pulled model from the list VS Code fetches from your local Ollama server, and check it.
7. Confirm it works — the model now appears in the picker. Select it, send a message, and you'll see responses generated entirely on your machine with your network disconnected.

That's the built-in-provider path. LM Studio takes a different route because it has no VS Code extension — you point a custom endpoint at its OpenAI-compatible server instead. Both are covered below in full.

What BYOK works with: chat, offline, and no GitHub account

There's one boundary that trips people up immediately, so let's draw it clearly. BYOK and local models apply to Chat and utility tasks — the chat panel, Agent mode, and the smaller "utility" jobs VS Code runs behind the scenes like generating commit messages or search keywords. They do not apply to standard inline code completions, the grey ghost-text autocomplete as you type. That still requires a separate model source. If your mental model was "local Ollama replaces Copilot autocomplete," recalibrate: it replaces the chat and agent half, not the completion half.

On the offline question, which comes up constantly: yes, a local model works with no internet connection. Once the model is pulled and the runtime is running, inference happens on your hardware. The only network dependency is VS Code itself, which doesn't phone home to generate tokens. This is the entire privacy argument — your code never leaves the machine.

And the cost argument is just as strong. You do not need a Copilot plan or a GitHub account to use this. That reframes the whole "local LLM to avoid Copilot pricing" genre. The old assumption was that you route around Copilot's subscription by installing a completely separate extension. The 2026 reality is that Copilot Chat's own picker gives you a free BYOK path to local models. As Simon Willison, who has written more hands-on about running models locally than almost anyone, has argued repeatedly, the friction of local models has always been tooling, not capability — and native editor integration removes a big chunk of that friction.

Here's the official BYOK-and-Ollama walkthrough that shipped alongside the feature, worth watching if you prefer to see the picker in motion:

[YOUTUBE:EeUXWrbMtpM|Bring your own key & models to GitHub Copilot & Visual Studio Code! Unlock every model + Ollama!]

That demo, from Microsoft developer advocate James Montemagno, runs through the exact Manage Models flow on real hardware.

Getting started: adding Ollama as a built-in provider

Ollama is the path of least resistance, and that's not an accident. VS Code ships built-in provider support named explicitly for Ollama and Microsoft's own Foundry Local — both selectable straight from the Manage Models flow with no extension install. This matters because Ollama has become the default local runtime for a lot of teams: per its own July 9, 2026 announcement, Ollama's founders report the tool now serves 8.9 million developers and runs inside 85% of the Fortune 500. Microsoft building a first-class integration for it was inevitable.

The setup: install Ollama, pull a model, then in VS Code open the Chat model picker, click Manage Models, and select Ollama. VS Code queries your local Ollama server and lists whatever you've pulled. Check the models you want in the picker, and you're done. No localhost URL to type, no key, no config file.

One detail worth internalizing: because Ollama advertises its models to VS Code programmatically, the capabilities each model reports depend on the model tag you pulled. A model built with tool-calling support in its template will show up as Agent-eligible; a base chat model without it won't. When you pick a model on Apple Silicon or an NVIDIA card, that choice quietly determines whether Agent mode is available — which is the segue into the capabilities discussion below.

If you're setting up a machine from scratch and want the runtime layer done properly first, the local LLM hardware and setup guides cover VRAM budgets and quantization tradeoffs before you ever open VS Code. Getting the model tier right there saves you from picking something that technically loads but generates at unusable speed.

Adding LM Studio as a custom OpenAI-compatible endpoint

Here's where the two runtimes diverge sharply, and where every existing tutorial goes quiet. As of July 2026, LM Studio has no dedicated VS Code extension — search the marketplace for "LM Studio" and you get nothing. So you don't add it as a provider the way you add Ollama. Instead, you use VS Code's custom-endpoint BYOK option and point it at LM Studio's built-in OpenAI-compatible server.

LM Studio exposes that server by default at http://localhost:1234/v1, with the standard /v1/models, /v1/chat/completions, and /v1/embeddings routes. The steps: in LM Studio, load a model and start the local server (there's a Server tab for this). Then in VS Code, open Manage Models, choose the option to add a custom OpenAI-compatible endpoint, and enter the base URL http://localhost:1234/v1. LM Studio doesn't require a real API key for local use, so any placeholder string works in the key field. VS Code will fetch the model list from /v1/models, and your loaded LM Studio model appears in the picker.

The practical difference between the two: Ollama's integration is managed — VS Code understands it natively and reads capabilities directly. LM Studio's is generic — VS Code treats it as a black-box OpenAI endpoint, so capability declarations like tool calling depend on how LM Studio and the model report themselves through the OpenAI-compatible layer. If you want the deeper comparison of the two runtimes as standalone tools, I wrote a full LM Studio vs Ollama breakdown that gets into their memory handling and model-management philosophies. For VS Code specifically, the one-line summary is: Ollama for zero-config, LM Studio when you want its GUI model management and are fine typing a URL.

Ollama vs LM Studio in VS Code: the setup compared

Since no single source puts these side by side, here's the direct comparison for wiring each into VS Code's model picker.

Dimension	Ollama	LM Studio
Integration type	Built-in provider	Custom OpenAI endpoint
VS Code extension needed	No	No (none exists)
Setup in picker	Select "Ollama"	Enter base URL manually
Default local address	http://localhost:11434	http://localhost:1234/v1
API key required	No	No (placeholder accepted)
Capability detection	Native, per model tag	Via OpenAI-compatible reporting
Model management	CLI / ollama pull	GUI browser + downloader
Best for	Zero-config, scripting	Visual model management

Both land you in the same place: a local model in the Chat picker, running offline, free. The choice is ergonomics, not capability. Teams that already script model pulls in their Claude Code or terminal workflows tend to stay on Ollama for consistency; developers who like browsing and swapping quantizations visually lean LM Studio.

Choosing the right local model: tool calling, context, and image input

This is the section that saves you an afternoon of confusion. Three capabilities decide whether a local model is actually usable for the work you want, and none of them are about raw quality.

Tool calling is the big one. Agent mode — where the model reads files, runs terminal commands, and edits code across your project — only works if the model declares capabilities.toolCalling. Many local models don't. When that happens, the model works fine in plain chat but is silently excluded from Agent mode, or it appears but never actually invokes tools. There's no error dialog. The model just quietly behaves like a chatbot. This is documented only in the extension-author API reference, buried where end users never look, which is why nobody warns you. If you want Agent-mode behavior, pull a model tag explicitly built for function calling — Qwen and recent Llama tool-tuned variants are reliable choices.

Context window is the second. VS Code reads maxInputTokens from the model's declared metadata, and if the model's real context is smaller than what you throw at it, responses get truncated or the model degrades badly. This is especially punishing in Agent mode, where the system prompt, file contents, and tool schemas eat context fast. A model advertising 8K context will choke on an agentic task that a 32K model handles cleanly. I dug into exactly this failure mode in a piece on RAG context window limits — the short version is that bigger isn't automatically better, but too-small is a hard wall.

Image input (capabilities.imageInput) is third and simplest: if the model isn't multimodal, you can't paste screenshots into chat. Most local coding models aren't, and that's usually fine.

On model selection itself, a real data point from my own testing. Based on the benchmark data I maintain at kunalganglani.com/llm-benchmarks, quantization quality cliffs are model-family-specific — a blanket "just use Q4" recommendation is wrong. Some families hold up beautifully at Q4_K_M; others fall off a cliff below Q6 and start producing subtly broken code that passes a glance but fails at runtime. Before you commit a quantized model to your daily VS Code workflow, check where its cliff is. I broke the levels down in detail in a guide on LLM quantization from Q4 to FP16.

And the memory angle, from the same benchmark work: unified memory on Apple Silicon changes the VRAM-is-the-limit intuition entirely. Big models load on an M-series Mac that would never fit on a comparable discrete GPU — but throughput becomes the real trade, and a model that loads isn't the same as a model that's pleasant to code with in an editor.

Adding models from third-party provider extensions

Between the two built-in providers and the fully manual custom-endpoint route sits a third option: provider extensions. Because the LanguageModelChatProvider API is public, anyone can ship an extension that registers a whole family of models into the picker. You install the extension from the marketplace, and its models appear in Manage Models alongside Ollama and your custom endpoints.

This is how you'd get first-class support for a provider VS Code doesn't build in natively — a specific inference server, a niche cloud, or a company's internal gateway. The one-provider-to-many-models design means a single extension can expose an entire catalog, each model carrying its own capability declarations. For most people running local models, you won't need this layer; Ollama's built-in provider and LM Studio's custom endpoint cover the two dominant runtimes. But it's worth knowing the extension route exists, because it's the answer to "my runtime isn't Ollama, LM Studio, or Foundry Local — now what?"

This is also the honest answer to "why not just use Continue.dev?" Continue.dev and similar chat extensions are perfectly good, and for years they were the only way to get local models into VS Code. The difference now is that the native picker gives you Agent mode, utility tasks, and the rest of Copilot Chat's surface with your local model — inside Microsoft's own UI, not a bolt-on panel. If you're comparing the broader tradeoffs of native versus third-party AI coding setups, the developer tools hub has the fuller landscape.

Troubleshooting: why isn't my local model showing up?

Every real setup hits at least one of these. Here's the checklist, in rough order of how often each one bites.

1. The runtime isn't actually running. Ollama needs its background server up; LM Studio needs you to have clicked "Start Server" in the Server tab. VS Code fetches models from a live endpoint — if nothing's listening on localhost:11434 or localhost:1234, the provider shows empty. Confirm the server first, always.
2. You're in an untrusted workspace. In VS Code's Restricted Mode, the chat model picker collapses to only "Auto." Your local and BYOK models won't appear at all until you trust the workspace. This is a silent one — nothing tells you the picker is truncated. If your models vanished after opening a cloned repo, this is almost certainly why.
3. Your org disabled the policy. Copilot Business and Enterprise admins can turn off the "Bring Your Own Language Model Key" policy org-wide in GitHub.com's Copilot settings. If you're on a managed work account and local models are missing entirely from Manage Models — not empty, but gone — check with whoever administers your Copilot org before debugging your runtime for an hour.
4. The model works in chat but not Agent mode. Back to toolCalling. The model didn't declare tool support, so VS Code excluded it from agentic work. Pull a tool-capable model tag. This isn't a bug you can fix in settings — it's a property of the model itself.
5. Responses get cut off mid-thought. Context window mismatch. The model's real maxInputTokens is smaller than your workload. Switch to a longer-context model tag or trim what you're feeding it.

Work down that list and you'll resolve the overwhelming majority of "it's not showing up" cases. The pattern to internalize: the picker is quiet about failures by design, so the debugging is always about which silent condition you've tripped.

The bigger shift, and where this goes next

Step back and the interesting part isn't the setup — it's the collapse of the wall between "the editor's AI" and "my own model." For two years, running a local model in VS Code meant accepting a second-class, bolt-on experience. Now it's the same picker, the same Agent mode, the same free surface, pointed at hardware you own. The LLM cost math that used to justify a separate extension now justifies almost nothing extra — the native path is free and better.

My prediction: within a year, "which local runtime does your editor support natively" becomes a real axis of competition, the way language-server support did a decade ago. Ollama got the first built-in slot in VS Code because it earned it with 8.9 million developers. The next runtimes to get native slots will be the ones that make capability declaration — tool calling especially — dead simple and honest, because that's the one thing standing between a local model and a genuinely agentic editor.

So here's the challenge: stop routing your local models through a terminal or a third-party panel out of habit. Open Manage Models, wire in Ollama or LM Studio, pull a tool-capable model, and run a real agentic task offline. If it works — and for tool-calling models with enough context, it does — you've just replaced a paid subscription with hardware you already own. If it doesn't, you now know exactly which of five silent conditions to check.

---

Originally published on kunalganglani.com