ollama-copilot: pointing Copilot clients at a local model

A proxy that reshapes the Ollama API into the Copilot API

The mechanism is the whole point and it is simple to state. ollama-copilot is a proxy that allows you to use ollama as a copilot like GitHub Copilot. The editor side keeps talking to what it thinks is GitHub Copilot, and the proxy translates between that expectation and whatever backend you have configured. The flag table names the provider options as ollama, llmman, openrouter, deepseek, mistral and openai, with ollama as the default, and a token flag for those providers that need a key. The default model is codellama:code, and the prompt template default is the fill-in-middle form with a prefix, suffix and mid section, which is the format a code completion model expects when it is given the text before and after your cursor. That template is configurable, and the system prompt defaults to a generic helpful instruction. So the shape is: an editor plugin sends a completion request with a prefix and a suffix, the proxy formats it using the template, forwards it to the configured backend, and returns the completion in the shape the plugin expects.

Four ports, because the proxy has to look like two different servers

The port flags are the part that looks confusing until you notice what each one is for. The proxy listens on an HTTP port of 11437, an HTTPS port of 11436, an HTTP proxy port of 11438 and an HTTPS proxy port of 11435, and custom TLS is possible with a certificate path and a key path. The split between a plain port and a proxy port is because the editor plugins do two different things: the VS Code Copilot extension is told to override its API endpoint with the debug override proxy URL pointing at the plain port, while the general HTTP proxy setting points at the proxy port, which is how the extension's own network traffic is captured and redirected. Neovim's copilot.vim, Zed's edit prediction provider and the Emacs copilot.el configuration all point at the proxy port instead, since they only offer a proxy setting. The documentation for Neovim also sets a strict SSL flag to false, and the VS Code settings pair the proxy with an http.proxyStrictSSL set to false, so a self-signed certificate does not break the connection.

Five editors, one proxy, and a sign-in step you still have to do

The editor integration is where the documentation is most explicit about a step that surprises people. For Neovim, you install copilot.vim, and you must complete the sign-in command before enabling the proxy, with the instruction that if you already enabled the proxy and sign-in is failing, you remove the proxy settings, sign in first, and then enable them again. The same applies to VS Code, where the documentation says to sign in or sign up with GitHub and then insert the settings. That sounds like a contradiction, since the whole point is to run the model locally, but it is not: the Copilot clients require an authenticated session before they will send completion requests, so the credential is used for the client handshake while the actual inference is handled by your local backend. The Zed integration sets the edit prediction provider to copilot and turns on showing completions on input, with the proxy and a no-verify flag. PyCharm and other JetBrains IDEs are configured through the manual proxy configuration in the HTTP Proxy settings with the host name localhost and the port 11435, plus accepting non-trusted certificates automatically, and a restart. The Emacs support is marked experimental.

Backends beyond Ollama, including a local one

The provider list means the proxy is not tied to Ollama. The DeepSeek configuration passes a token and the deepseek-coder model, and the Mistral configuration passes a token and codestral-latest, and the flag table also lists openrouter and openai as providers, so a hosted API is a one flag change. The llmman option is the interesting one, because it is a local runner rather than a hosted service. llmman is described as a local model runner that serves the Ollama API on port 17434, so it drops into the same slot as Ollama without the proxy needing a second code path. The documented sequence installs llmman, starts the serve command, pulls a model, and then points ollama-copilot at it with the provider flag and the model name. If llmman is hosted elsewhere, the host is set through the LLMMAN_HOST environment variable pointing at the port 17434 address. That last point is worth dwelling on, because a provider that speaks the Ollama API means the proxy is largely a transport and format shim, and a self-hosted or remote Ollama instance works the same way, which is also why there is an OLLAMA_HOST environment variable for the case where Ollama runs in a container or elsewhere.

Install, service and the num-predict setting

There is a self-installing script and a manual path, and the script does more than copy a binary. The install.sh script automates the build, installation and configuration of ollama-copilot and your editors, and it will build the binary and install it to the local bin directory, optionally install and start a Systemd service, and automatically detect and offer to configure Neovim, VS Code and Zed. The service matters because of one configuration option. The num-predict flag defaults to 250, and the documentation says 25 is recommended for copilot, and the service is what allows you to configure num-predict, since a value that makes sense for a batch generation request is far too long for an inline completion that has to appear before you type the next character. The manual path is a Go install of the module at its latest version, followed by making sure the Go bin directory is on your path:

go install github.com/bernardo-bruning/ollama-copilot@latest

And then you run the proxy with no arguments, or point it at a hosted Ollama with the host environment variable set to a container address.

A small Go program with a small dependency list

The code base is compact and the dependency list is unusually revealing. The module is github.com/bernardo-bruning/ollama-copilot and it requires Go 1.24.1. The one direct dependency that matters is github.com/ollama/ollama at version 0.15.2, which means the proxy imports Ollama's own Go packages rather than reimplementing its API client, and the other direct dependencies are the uuid package and testify for tests. The indirect list is the Ollama library's own transitive dependencies, which include generic-list-go, jsonparser, easyjson, an ordered map implementation, and the standard crypto, sys and yaml packages. The repository layout matches a small service: a main.go entry point, an internal directory for the implementation, an install.sh, a systemd unit file, and a flake.nix with a flake.lock for Nix users. The unit file at the root is the systemd service the installer can set up. The licence is MIT, and the only tagged release is v0.3.0 from 2026-01-30, with the last push on 2026-09-14.

Editorial conclusion

ollama-copilot is a good fit for a developer who runs a model locally and wants their editor's inline completion to use it rather than a hosted service, and it is the shortest path to that for anyone already using Copilot in VS Code, Neovim or Zed since the editor side needs no plugin change. It is the wrong tool if you need chat, agentic edits or anything beyond completion, since the roadmap is scoped to completions APIs and fill-in-the-middle, and it is the wrong tool on Windows, which is the one roadmap item still open. Before adopting it, read the flag table, because the default of 250 predicted tokens is a lot for an inline completion and the documentation recommends 25, and note that the editor plugins still expect to sign in to GitHub, so the sign-in step is required even when the inference happens on your machine. The project is MIT licensed, the last push was on 2026-09-14, and the only release is v0.3.0 from 2026-01-30.

Frequently asked questions

Official sources

1. bernardo-bruning/ollama-copilot on GitHub
2. Issues
3. License: MIT
4. README
5. Releases