Wire a Local Model Into Your Editor

Every editor integration in this part comes down to the same string: http://localhost:11434. What changes is where the settings panel hides it, whether the editor charges you for the privilege of typing it, and how many separate jobs the editor expects one model to do.

Ollama's integrations index sorts them into three buckets. Terminal coding agents (Claude Code, OpenCode), assistants (OpenClaw, Hermes Agent), and editors (VS Code). Zed and JetBrains have their own pages outside that index. Continue is documented on Continue's side rather than Ollama's, which turns out to matter.

Zed connects through an LLM Providers panel

Five steps, from Ollama's own Zed page:

1. Install Zed.
2. Click the star icon in the bottom-right corner and select Configure.
3. Under LLM Providers, choose Ollama.
4. Confirm the Host URL reads http://localhost:11434.
5. Click Connect, then pick a model from the Ollama dropdown.

The same panel handles the hosted case. Generate an API key in your ollama.com account settings, then set the API URL to https://ollama.com instead. Same provider entry, different host, which makes swapping between local and cloud a one-field edit rather than a reinstall.

The dropdown reads from whatever your Ollama install already holds, so pull the model first. An empty dropdown almost always means an empty ollama ls.

JetBrains charges a subscription for a local model

The steps are short. Click the chat icon in IntelliJ's right sidebar, select the current model, choose Set up Local Models, pick Ollama under Third Party AI Providers, confirm the Host URL is http://localhost:11434, and click Ok. Your models then appear under Local models by Ollama. The same path works in PyCharm and the other JetBrains IDEs.

One requirement in that page deserves to be read twice: a JetBrains AI subscription is needed to use the Ollama integration. The model runs on your machine, the weights are yours, the inference costs you nothing per token, and the editor still gates the feature behind a paid plan.

That is a licensing decision rather than a technical one, and it changes the calculus if your reason for going local was cost. Zed's route above has no equivalent gate.

Continue turns one model into a list of roles

Continue is the configuration-file option, and its model is different from the others here. Rather than selecting a model, you declare models and assign each one a set of jobs.

Config lives in YAML. The reference lists these top-level keys: name, version and schema as required, then models, context, rules, prompts, docs, mcpServers and data.

Inside a models entry, name, provider and model are required. apiBase overrides the endpoint, roles declares what the model is for, and defaultCompletionOptions carries contextLength, described in the reference as "Maximum context length of the model, typically in tokens", alongside maxTokens, temperature, topP and topK.

A hand-written entry pointing at a local Ollama install looks like this:

- name: Local chat
  provider: ollama
  model: qwen3:8b
  apiBase: http://localhost:11434
  roles: [chat, edit, apply]

The model value has one rule and it catches everyone once. It must match exactly what ollama list prints. Not the display name, not the family name, the tag string including the size suffix.

Continue also ships pre-built blocks that shortcut the whole entry:

models:
  - uses: ollama/qwen2.5-coder-7b

With a caveat the guide states directly: "Blocks only provide configuration - you still need to pull the model locally." A block is a settings shortcut and never a download.

The roles list is where the docs stop agreeing

Continue's Ollama guide names five roles: chat, edit, apply, rerank, autocomplete. Continue's config reference names seven: chat, autocomplete, embed, rerank, edit, apply and summarize, with a default of [chat, edit, apply, summarize].

Two pages on the same documentation site, two different lists, no note explaining which is current. The reference is the more complete of the two and the more likely to reflect the shipping schema, but that is an inference rather than something either page states.

There is a second, larger drift on the same guide. It closes by saying it "is based on Ollama v0.11.x and Continue v1.1.x". Ollama's latest tagged release is v0.32.5, published 27 July 2026. That is a long way from 0.11.x, and the version the VS Code extension page recommends for full features is 0.17.6 or newer.

The practical consequence: when a screenshot or a field name in a third-party guide does not match what is in front of you, the guide is the thing that is out of date. Check the vendor's own reference before you assume you broke something.

Autocomplete and chat want different models

The roles system exists because these are genuinely different jobs, and Continue's guide separates its recommendations accordingly.

The autocomplete row is the interesting one. Those are 1.5B and 3B models, an order of magnitude below the chat recommendations. Inline completion fires on every pause in your typing, so latency dominates and a large model makes the editor feel broken regardless of how good its suggestions are. Chat runs once per question and can afford to think.

Running both at once means holding both in memory at once. Budget for the sum, not the larger of the two, and check the placement with ollama ps after you have opened a file and triggered a completion.

Terminal agents skip the config file entirely

If your editing happens in a terminal, ollama launch handles the wiring. OpenCode is one command:

ollama launch opencode

Ollama's integrations index describes the discovery path plainly: "Run ollama launch to see the latest integrations you can run from the terminal." That is a better source than any list a blog can keep current.

For the manual route, OpenCode's config shows what these integrations do under the hood. The provider block in opencode.json points an OpenAI-compatible client at Ollama:

"options": { "baseURL": "http://localhost:11434/v1" }

Note the /v1 suffix, which is the OpenAI-compatible surface rather than Ollama's native API. Part 7 covers what that endpoint supports and, more usefully, what it drops.

The OpenCode page also states a hard requirement that applies to every agentic tool here: it needs "a context length of 64k or higher" to work usefully across a repository. Ollama's default sits far below that on most machines, which means an agent wired up correctly will still behave as though it has amnesia until you raise OLLAMA_CONTEXT_LENGTH or num_ctx.

Zed for speed, Continue for version control, JetBrains if you must

Zed is the shortest path with no subscription attached. JetBrains works and is the right answer if your team already lives in IntelliJ, with the subscription noted above. Continue is the only option here that gives you role-level control and a version-controlled config file, at the cost of editing YAML and reconciling two doc pages that disagree.

VS Code is covered in part 3, including the 1.120 minimum version and the "Ollama: Refresh Models" and "Ollama: Diagnose Models" palette commands that fix an empty picker.

Whichever you pick, the failure mode is the same and so is the diagnosis. Model missing from a dropdown means ollama ls is empty or the tag string does not match. Answers that ignore your open files mean the context window is too small. Typing that stutters means an autocomplete model too large for the job. None of those are editor bugs.

If you want an assistant rather than an editor, OpenClaw and Hermes Agent both appear on Ollama's integrations index under "Connect an assistant", and part 8 covers the second one in depth.