GitHub shipped a quiet but consequential update on August 11: JetBrains users can now point GitHub Copilot at a local Ollama model instead of routing every inference request through a hosted provider. For teams running IntelliJ IDEA, PyCharm, or WebStorm at scale, that shifts both the cost and the privacy calculus. But “local inference” and “fully private AI coding assistant” are not the same thing — and the gap between those two ideas is worth understanding before you reconfigure anything.
What GitHub Shipped on August 11 #
The August 11 JetBrains Copilot update drops two features simultaneously. First: Ollama is now a supported BYOK (bring-your-own-key) provider, meaning you can tell the Copilot plugin to send its inference requests to a model server running on your own machine. Second: Copilot Memory lands in JetBrains — persistent context that survives across agent chat sessions so you stop re-explaining your project structure every time you open a new conversation.
This is the last leg of a phased rollout. Copilot CLI got BYOK and local model support in April. The Copilot app extended it to agent sessions in June. JetBrains expanded BYOK further in July. The Ollama integration and Memory arriving together on August 11 essentially puts JetBrains at parity with VS Code for this capability.
The August 11 release also tightens enterprise controls: administrators now get server-based settings for MCP server access, plugin availability, permission bypass behavior, and OpenTelemetry configuration. Codex sessions surface in agent debug logs. These are not splashy features, but for teams managing Copilot across an organization, the control surface is getting serious.
How to Set It Up #
The mechanics are straightforward. Start an Ollama server locally, pull a compatible model, then add Ollama as a BYOK provider in the Copilot plugin settings. Because you are pointing at a local server, there is no API key to configure — a local Ollama instance has no authentication by default.
ollama pull qwen2.5-coder:32b
export COPILOT_PROVIDER_BASE_URL=http://localhost:11434
export COPILOT_MODEL=qwen2.5-coder:32b
Model selection matters more than it looks. Copilot requires tool calling (function calling) and streaming support from any model you plug in. Run a model that lacks either, and Copilot CLI will return an error. Qwen 2.5 Coder 32B is the current benchmark leader for agentic coding tasks — 84% tool-calling accuracy and reliable multi-step workflows. It is the safest choice until you have a reason to try something else. GitHub documents the full BYOK model requirements here.
What You Actually Gain #
Three things improve when you route inference to Ollama locally. The per-token billing disappears — once your hardware is running, inference is effectively free. The LLM call, which contains your code and your prompt, stays on your machine instead of transiting to GitHub’s servers. And for teams with code that contractually or legally cannot touch external endpoints, this makes Copilot viable where it previously wasn’t.
Latency is a wildcard. A machine with a modern GPU running Qwen 2.5 Coder 32B will feel fast. A CPU-only machine running the same model will feel like a regression. If your team doesn’t already have Ollama set up with capable hardware, “free inference” has a hardware cost attached.
What You Now Own #
Here is the part that most coverage glosses over. Switching to local inference transfers a chunk of operational responsibility onto your team. Ollama must stay running and accessible in your development environment. Model weights need security patches as they become available — treat them as infrastructure, not one-time downloads. You need to validate model provenance, the same way you would audit any dependency in your supply chain. And capacity planning falls on you: a 32B model running on shared hardware will create contention.
It is also worth being precise about what “local” means in this context. The inference request — your code, your prompt — goes to your local Ollama server. But GitHub authentication, Copilot telemetry, and session metadata still communicate with GitHub’s servers. Routing inference locally is a meaningful privacy improvement for the LLM call itself. It is not a complete air-gap, and claiming otherwise inside your organization will create compliance problems later.
Copilot Memory: The Detail Worth Reading #
Copilot Memory is the other half of the August 11 update and it deserves more attention than it is getting. The feature retains context across agent chat sessions — facts about your project, preferences, architectural decisions — so Copilot picks up where you left off instead of starting cold. For teams doing extended agentic work in a single repository, the productivity improvement is real.
The constraints are specific and worth knowing upfront. Memories expire automatically after 28 days. They are strictly repository-scoped — a memory in your backend repo is invisible from your frontend repo. Only users with write access can create memories, though anyone with Copilot Memory enabled in the repo can benefit from them. Memories are validated against the current codebase before being applied, which prevents stale facts from sending the agent in the wrong direction.
Who Should Make the Switch #
BYOK with Ollama is worth enabling if you already have Ollama running on GPU hardware, Copilot costs at team scale are material, or you have code that cannot be sent to a third-party inference endpoint. It is not worth the ops overhead if your team lacks GPU capacity, lacks a model patching process, or needs the full Copilot feature surface — some capabilities still depend on hosted inference.
The right mental model: this is not “free AI.” It is “shift the cost from per-token billing to infrastructure and ops.” For the right team, that is a better deal. For many teams, it is not. Check the full August 10 weekly release notes for the complete list of what landed alongside the Ollama and Memory updates.