SpektiqCan Windsurf use Ollama? Wiring a local model
· 12 min read
Windsurf and Ollama: the short answer, checked on 2026-11-09
No, not natively. As of 2026-11-09, the official documentation for the standard plans documents no way to point Windsurf's built-in agent at an Ollama model: the models page mentions no bring-your-own-key, custom endpoint or local model setting. The first thing to know is that "Windsurf" is no longer the product name: according to the official FAQ, Cognition renamed it Devin Desktop on June 2, 2026, and the documentation has moved to docs.devin.ai (the old Windsurf models page, for one, redirects there as of 2026-11-09). The same FAQ says the IDE, its extensions and workflows are still there, and that plans and pricing did not change with the rename.
Two routes do get a local model into the editor. The first is to plug a third-party agent that already speaks Ollama, such as OpenCode, into Devin Desktop through the Agent Client Protocol (ACP); Codex CLI is a possible variant, but one you would have to test yourself, as explained below. The second is to install the Continue extension from Open VSX and point it at your Ollama server. Either way, the main limit applies from the start: as documented on 2026-11-09, Devin Desktop's native agent and its Tab suggestions keep using the vendor's cloud models.
Every statement below was checked against the official documentation on 2026-11-09. This product has changed its name, its default agent and its documentation site within a year, so treat any undated answer you read elsewhere with suspicion.
Why the 2025 answers no longer hold
Search for this question and you will find answers that contradict each other: some mention custom endpoints, others say bring-your-own-key only covers one provider. Many of them describe Windsurf as it was in 2025.
The current state, read on 2026-11-09, is narrower. The official AI Models page (docs.devin.ai/desktop/models) lists Cognition's in-house SWE models and third-party cloud models such as Claude, GPT and Gemini (read on 2026-11-09). It says nothing about bring-your-own-key, a custom endpoint, a local model or Ollama. Self-serve plans are billed by tokens against a quota, Enterprise plans by ACUs, and the model selector shows the model lists and their prices.
Cascade, the agent most 2025 tutorials are built on, is now documented as the legacy agent: the app no longer starts new Cascade conversations, and the agent selector no longer offers it. A guide that begins with "open Cascade and..." is a dead end.
MCP is not a back door either. Devin Local, the native agent, reads MCP server configuration from .devin/mcp_config.json in the project, from a .devin/mcp_config.local.json override, or from a user file under ~/.config/devin. MCP gives the agent extra tools. It does not swap out the model doing the thinking, and the customization page documents no custom or local model setting.
Then there is the trap. Devin's documentation does contain an OpenAI-compatible models file, and its example even shows an Ollama server on localhost next to a vLLM server. Entries point a base_url at each endpoint, plain http is accepted only for loopback hosts, the bundled agent inherits the Desktop app's environment rather than the terminal's, and even an unauthenticated server like Ollama needs its key variable set, possibly empty. That page sits in the federal air-gapped section and states that it is documentation for the federal deployments of Devin. It is not presented as a feature of Free or Pro plans, so do not expect it to apply to a standard install.
Route one: an Ollama-aware agent through ACP
This is the main documented route. Devin Desktop runs third-party agents in its Agent Command Center through the Agent Client Protocol. The docs name Codex CLI, Claude Agent, OpenCode, Junie and Gemini CLI as examples and say any agent implementing ACP can be plugged in. On 2026-11-09, ACP agents are available on Free, Pro, Max and Teams plans and are off by default on Enterprise.
The key point is that the agent, not Devin Desktop, talks to Ollama. So you set up the agent first, then register it in the editor.
Get OpenCode talking to Ollama first
Ollama documents a launcher command that starts OpenCode with Ollama models preconfigured:
ollama pull <model-name>
ollama launch opencode
If you prefer to write the configuration yourself, Ollama's OpenCode guide describes an opencode.json provider using the @ai-sdk/openai-compatible package, with baseURL set to the OpenAI-compatible path of your local Ollama server, exactly as given in that guide. Ollama's OpenAI-compatible API ignores the API key for a local server, so a placeholder value is enough.
For the editor route, the persistent opencode.json provider is the safer choice: Devin Desktop starts opencode acp itself, so test with plain opencode (not through ollama launch) and check that a local model is selected. OpenCode's docs say it behaves the same through ACP as in the terminal, so if it fails there, fix it there.
Register it in Devin Desktop
Open the local ACP registry with the command "Open Local ACP Registry Config". On macOS and Linux the documented file is ~/.windsurf/acp/registry.json; note that the folder still carries the Windsurf name. Add an entry for OpenCode with cmd set to opencode and args set to acp, for each platform you use. Keep Devin Desktop's ACP documentation open while you do it: the entry format, with cmd and args per platform, is shown on that page.
Devin Desktop does not download the binary for you: OpenCode must already be installed. Then enable the agent in Devin User Settings, under the Agents tab. If you change the entry later, run "Reload ACP Connections" from the Command Palette and the new version is picked up without restarting the app.
What the editor actually launches is this:
opencode acp
OpenCode's documentation says this runs OpenCode as a subprocess speaking JSON-RPC over stdio. Whatever model your OpenCode configuration points at, an Ollama model included, is the model doing the work inside the Agent Command Center.
The Codex CLI variant
Codex CLI is one of the ACP examples Devin Desktop names, and Ollama documents two ways to run it against the local server in a terminal. The documentation checked on 2026-11-09 does not show the ACP registry entry for Codex or how to carry the Ollama choice into an editor-launched Codex, so treat this as a variant to test yourself; OpenCode is the route documented end to end. The two terminal commands are:
ollama launch codex
codex --oss
Inside Codex, /model switches between installed Ollama models that support tool calling. One warning, documented by Ollama: through the Ollama profile, Codex's web-search requests are executed by Ollama's service, which requires ollama signin, and web search can be disabled per session. A local model does not automatically mean nothing leaves the machine.
Route two: the Continue extension from Open VSX
The lighter route gives you chat, edit and autocomplete inside an editor panel rather than a full agent in the Command Center. Devin Desktop uses the Open VSX Registry through its Extensions panel, and Continue ("Continue - open-source AI code agent") is published there under the Continue namespace.
Continue's Ollama guide sets it up in ~/.continue/configs/config.yaml: provider: ollama, a model name that matches the output of ollama list exactly, and an apiBase pointing at your Ollama server. Each model can take roles such as chat, edit, apply and autocomplete, and agent mode requires the tool_use capability.
Two practical tips come from Continue's own guide. Download models with ollama pull rather than ollama run. And expect some models to still report agent mode as unsupported even with tool_use declared, so check the model before blaming your configuration.
ollama pull <model-name>
ollama list
Older threads may point you to other extensions or to assorted community forks; check that an extension is actively maintained before handing it your codebase. Continue is published openly on the registry Devin Desktop actually uses, which makes it the sensible answer here.
Which route to pick? ACP gives you a full agent in the Command Center, the same OpenCode you would run in a terminal, powered by your local model. Continue gives you an assistant in a side panel, with its own autocomplete role that Ollama can serve. Nothing stops you from using both.
What still runs on Cognition's cloud, and who bills you
Here are the limits, stated plainly as of 2026-11-09. With an external ACP agent, Devin Desktop's docs say all agent operations are delegated to that agent and that billing is directly between you and the third-party provider. That covers the work that agent does, nothing more. The native Devin Local agent and Tab suggestions do not switch to Ollama: they remain Cognition's features, covered by your Devin Desktop plan (on self-serve plans, usage of the selector's models is billed by tokens against the plan's quota; Enterprise plans use ACUs).
Nothing in the standard-plan documentation supports a fully offline, zero-cloud editor, so this article does not promise one. And keep the Codex detail in mind: web search through the Ollama profile goes through Ollama's service.
On cost, the framing is simple. A local agent replaces token spending for the tasks it handles, but it does not replace the editor's own features or your plan. Whether that trade is worth it depends on your hardware and on how much agent work you do; our guide to running an LLM locally compares the local route with paying a quota or an agent provider.
Picking a model your machine can actually hold
Coding agents lean on tool calling and long context, so before any question of quality, the model has to fit. The table below gives the memory needed to load a model's weights alone, in common GGUF formats. The values are computed, not measured: parameters times bits per weight, converted to bytes. The bits-per-weight figures were measured by the llama.cpp project on one model's files and are applied here as an estimate to other models (see the table's sources).
| Model | Parameters (model card) | Q4_K_M (4.8944 bits/weight) | Q6_K (6.5633 bits/weight) | Q8_0 (8.5008 bits/weight) | F16 (16.0005 bits/weight) | Sources |
|---|---|---|---|---|---|---|
| Qwen2.5-7B-Instruct | 7.61 billion | 4.7 GB | 6.2 GB | 8.1 GB | 15.2 GB | [1] [2] |
| Qwen2.5-14B-Instruct | 14.7 billion | 9.0 GB | 12.1 GB | 15.6 GB | 29.4 GB | [1] [3] |
| Qwen2.5-32B-Instruct | 32.5 billion | 19.9 GB | 26.7 GB | 34.5 GB | 65.0 GB | [1] [4] |
| Qwen2.5-72B-Instruct | 72.7 billion | 44.5 GB | 59.6 GB | 77.3 GB | 145.4 GB | [1] [5] |
Each value is computed, not measured: parameters × bits per weight ÷ 8, in decimal gigabytes (1 GB = 10^9 bytes, slightly less than one GiB).
The bits-per-weight figures were measured by the llama.cpp project on Llama 3.1 8B files. Applied to other models they estimate the size of the weight file; they are not a measured size for that model.
llama.cpp's quantization README states that memory and disk requirements are the same because models are fully loaded into memory. The llama-server README is more nuanced: the server memory-maps the weight file (mmap) rather than locking it in RAM (mlock) unless asked to, and its --lazy-mode option reads certain tensors, such as per-layer embeddings, from disk on demand instead of keeping them resident. Reading from disk is slower than reading from memory, so the figures here describe the weights fully resident: to run at full speed, the weight file has to fit in RAM, in VRAM, or across both.
This table counts the weights only. It does not count the memory a runtime uses for the conversation context or its own buffers, so it is a lower bound, not a full hardware requirement.
Lower-bit formats trade quality for size. The table says what fits, not how well a given format answers.
Sources
- llama-quantize README, Memory/Disk Requirements and Quantization sections (measured on Llama 3.1 8B), ggml-org/llama.cpp (GitHub), read on 2026-10-05
- Qwen2.5-7B-Instruct model card, Qwen (Hugging Face), read on 2026-10-05
- Qwen2.5-14B-Instruct model card, Qwen (Hugging Face), read on 2026-10-05
- Qwen2.5-32B-Instruct model card, Qwen (Hugging Face), read on 2026-10-05
- Qwen2.5-72B-Instruct model card, Qwen (Hugging Face), read on 2026-10-05
- llama-server README, model loading options (--load-mode, --lazy-mode), ggml-org/llama.cpp (GitHub), read on 2026-10-12
Read these values as lower bounds. The table counts weights only: the context these agents ask for, and the runtime's own buffers, come on top. If you are unsure what your machine can hold, start with what your hardware can run.
To run at full speed, the weight file has to sit in RAM, in VRAM, or across both. The table's notes describe llama.cpp's own server, llama-server, which by default memory-maps the file rather than locking it in memory; anything read from disk is slower than reading from memory. On a modest GPU, a model that loads may still leave no room for the long context an agent wants; the small-VRAM guide covers that case.
Lower-bit formats trade quality for size, so the table tells you what fits, not how well it answers. Once the wiring works, the real question becomes which model to pull for agentic work in OpenCode or Continue, and that is what the local coding model guide is for.