GitHub Copilot Adds Ollama and Memory to JetBrains GitHub shipped two upgrades for JetBrains Copilot users on August 11: Ollama is now a supported bring-your-own-key provider in the plugin, and persistent memory now carries context across agent sessions. The Ollama integration works in IntelliJ IDEA, PyCharm, WebStorm, GoLand, CLion, and other JetBrains IDEs, routing completion and chat requests to a local instance at localhost:11434. Persistent memory, available for Copilot Pro and Pro+ users, automatically purges stored facts after 28 days of non-use. GitHub shipped two underrated upgrades for JetBrains Copilot users on August 11: Ollama is now a supported bring-your-own-key provider in the plugin, and persistent memory now carries context across agent sessions. Neither is a flashy keynote moment. Both will quietly change how a lot of developers work. Local Models in Your IDE: How It Works The Ollama integration lands in IntelliJ IDEA, PyCharm, WebStorm, GoLand, CLion, and every other JetBrains IDE that runs the GitHub Copilot plugin. The setup lives in the plugin’s BYOK provider configuration — dig into Settings, find GitHub Copilot, and look for the provider settings. From there, point it at your local Ollama instance default endpoint: localhost:11434 , pick a model from whatever you have pulled, and Copilot routes completion and chat requests to your machine instead of GitHub’s hosted inference. Ollama is not the only option. The same BYOK system also supports Azure OpenAI, Anthropic’s API, LM Studio, or any endpoint that speaks the OpenAI-compatible API. If you already run a self-hosted model server, this probably just works. One critical caveat before you assume this makes Copilot fully private: it does not. Routing model requests locally cuts one data path, but other Copilot telemetry may still contact GitHub’s servers. If you need true air-gap compliance, route the model requests locally and verify the plugin’s remaining traffic independently. GitHub provides network environment variables for Copilot CLI, but the IDE plugin does not inherit CLI environment variables — configure each client separately. The feature is available for Copilot Pro and higher plans in public preview. GitHub’s August 11 changelog https://github.blog/changelog/2026-08-11-copilot-memory-and-ollama-in-github-copilot-for-jetbrains/ has the official details. Persistent Memory: Stop Re-Explaining Your Codebase The second feature shipped in the same update and it is arguably the one you will feel every day: Copilot now remembers things across agent chat sessions. Previously, each session started blank. You would explain your project’s architecture, preferred libraries, naming conventions, and code style repeatedly — every time. Now those facts persist. Tell Copilot once that you prefer Kotlin coroutines over Java threads, or that your team uses a particular error-handling pattern, and it carries that forward. According to the GitHub Copilot Memory documentation https://docs.github.com/en/copilot/concepts/agents/copilot-memory , any stored fact is automatically purged after 28 days of non-use, though active use resets that timer. You can manage what Copilot remembers via the Copilot Memory toggle in the settings portal. For Pro and Pro+ users, it is on by default — check your settings if you did not explicitly opt in and want to understand what is being stored. Why Local Inference Is Worth Caring About in 2026 The cost arithmetic for local models has shifted substantially. Cloud inference costs scale linearly with usage. Local inference costs are fixed — hardware up front, then effectively $0 per query https://dev.to/pooyagolchian/local-ai-in-2026-ollama-benchmarks-0-inference-and-the-end-of-per-token-pricing-32e7 after that. For high-volume development workflows — dozens of context-heavy completions per hour — the math starts to favor local runs within months, especially on Apple Silicon hardware that handles most coding models without a discrete GPU. For sensitive codebases, the privacy argument is simpler: data that never leaves your machine cannot be logged, retained, or subject to a third-party provider’s terms. That is relevant for teams in regulated industries, companies with strict IP policies, or anyone working on code they genuinely cannot let leave their network. The Copilot BYOK integration does not replace a full security audit, but it removes one significant data-sharing point from the equation. GitHub’s Broader Direction: Copilot as an Orchestration Layer This update is not a standalone feature drop. It fits a clear pattern. GitHub added BYOK to Copilot CLI in April 2026, to the Copilot app in June, expanded JetBrains BYOK in July, and now added Ollama as a provider in August. The same August release also added server-based enterprise admin controls covering MCP server access, plugin availability, and OpenTelemetry configuration for agent workflows. The direction is legible: GitHub is turning Copilot into a model-agnostic orchestration layer. Bring your own model, your own toolchain, your own data. The model is increasingly a swappable component. That matters for teams who want Copilot’s workflow integrations — PR summaries, code review, agent sessions — without being locked to a specific model or provider. Community setup guides https://axentia.in/blog/github-copilot-ollama-jetbrains-run-local-models-in-your-ide are already appearing as early adopters configure this. What You Should Do Today If you are a JetBrains user on Copilot Pro or higher: update the plugin, pull a model via Ollama if you have not already, and test the BYOK configuration. The persistent memory feature is worth enabling even if you skip the local model routing — it pays for itself the first time you open a session without having to re-explain your project. If privacy is your concern: do the routing, then verify the remaining traffic before declaring victory. Local model inference is a meaningful step. It is not a complete solution on its own.