Zed + Ollama: Local AI Coding With Zero Config (Almost)

Short answer: install Ollama, run ollama pull qwen2.5-coder:1.5b (986MB, runs on any laptop) or qwen3-coder:30b (19GB, for 24GB+ VRAM), open Zed, and pick the model from the dropdown — Zed auto-discovers every model Ollama has pulled, zero config. One setting will still bite you: Zed defaults Ollama models to a 4,096-token context window, which silently cripples inline assist and breaks the agent panel. Raise max_tokens in settings.json (32K+ for agent work) and the setup is done.

That is genuinely the whole thing — Zed has the least-friction Ollama integration of any editor we have configured, and its built-in tab completion can also run on a local model — a first-class option in the editor itself, not something an extension bolts on. The rest of this guide is the part the quick-start skips: the exact settings.json blocks, why the context default breaks things in ways that look like model stupidity, which models fit which VRAM tier, and an honest section on the agent panel, where local models still have a documented rough edge. Verified against Zed's official docs and current model cards in August 2026, on Zed stable v1.14.x.

---

Why Zed for Local AI

Zed is the performance-first editor from the creators of Atom and Tree-sitter (88K+ GitHub stars as of August 2026), and its local-model story is unusually complete: chat, inline assist, agentic editing, and tab completion can all point at Ollama.

Three things make Zed interesting specifically for local AI, rather than just another editor with an AI sidebar:

• Auto-discovery. Zed's docs state it plainly: "Zed automatically discovers models that Ollama has pulled." No API-key dialog, no provider wizard, no extension to install. If ollama list shows a model, Zed's model dropdown shows it too.
• Local tab completion. Edit prediction — Zed's autocomplete-on-steroids — supports Ollama as a provider alongside its default Zeta model. In VS Code, local completion means installing and configuring Continue.dev; in Zed it is a provider switch in the editor's own engine.
• Speed budget. A big local model already costs you seconds per response. An editor written in Rust that stays instant while a 19GB model chews through a prompt is a better host for that workflow than an Electron app juggling extensions. (Performance is Zed's entire pitch; we will not relitigate the benchmarks here.)

The honest counterweight: Zed's agent panel — the multi-step, edit-your-files mode — is the least mature part of the local story, and there is a long-running GitHub discussion documenting exactly why. We cover it below instead of pretending it does not exist.

---

The 5-Minute Setup

Three commands and a dropdown click: install Ollama, pull a model, make sure the server is running, select the model in Zed.

1. Install Ollama (skip if you have it):

# macOS / Linux
curl -fsSL https://ollama.com/install.sh | sh
# Windows: installer from ollama.com/download

2. Pull a model. Pick from the model table below; the safe starter that runs on nearly anything:

ollama pull qwen2.5-coder:1.5b   # 986MB — any laptop
# or, if you have 24GB VRAM / 32GB+ unified memory:
ollama pull qwen3-coder:30b      # 19GB — the agent-capable pick

3. Make sure the server is running. On macOS, having Ollama.app open is enough. Otherwise:

ollama serve

4. Select the model in Zed. Open the agent panel or inline assist, click the model dropdown, and your pulled models are already there under the Ollama provider. That is the auto-discovery working — Zed polls the local server at http://localhost:11434 and lists whatever it finds.

If the models do not appear: confirm ollama list shows them, confirm nothing else moved the server off port 11434, and restart Zed so it re-queries the provider.

New to Ollama itself? Our complete Ollama guide covers the server side — models, quants, memory behavior — in depth.

---

The settings.json That Matters

Auto-discovery needs zero config, but two blocks in settings.json (Cmd+, / Ctrl+,) turn a demo into a daily driver: a model entry that raises max_tokens, and a default model for the agent and inline assist.

Everything below is the documented shape from Zed's local-model and agent-settings docs.

Register the model properly — this is where you fix the context window and declare capabilities:

{
  "language_models": {
    "ollama": {
      "api_url": "http://localhost:11434",
      "available_models": [
        {
          "name": "qwen3-coder:30b",
          "display_name": "Qwen3 Coder 30B (local)",
          "max_tokens": 32768,
          "supports_tools": true
        },
        {
          "name": "qwen2.5-coder:1.5b",
          "display_name": "Qwen2.5 Coder 1.5B (laptop)",
          "max_tokens": 16384
        }
      ]
    }
  }
}

The fields do real work: max_tokens is the context window Zed will actually use (see the trap), and supports_tools tells Zed the model can drive the agent panel's tool calls. Zed's docs also support supports_thinking and supports_images flags for models that have those capabilities, and an auto_discover: false switch if you want only your hand-registered list to show up.

Set the default model for the agent panel:

{
  "agent": {
    "default_model": {
      "provider": "ollama",
      "model": "qwen3-coder:30b"
    }
  }
}

Zed also lets you point individual features at different models — agent.inline_assistant_model, agent.commit_message_model, agent.thread_summary_model — which is exactly what you want locally: a 30B model for agent threads is overkill for commit messages, where the 1.5B is instant and fine. Assign the small model to the cheap jobs and the big one only where reasoning matters.

One more documented detail: if your Ollama server sits behind authentication (a remote box, say), Zed reads OLLAMA_API_KEY — for a stock localhost setup you never touch it.

---

The 4,096-Token Trap

Zed uses a 4,096-token context window for Ollama models by default, per its own docs — and 4K is small enough that inline assist on a large file, or one agent-panel turn, overflows it immediately.

This is the same failure mode we documented for Cline, wearing a different config key. When context overflows, nothing errors: the model just stops seeing the top of its prompt. Symptoms you should recognize:

• Inline assist rewrites code while ignoring the instruction you just gave — the instruction got truncated away.
• The agent panel "forgets" the task mid-thread, or answers in chat instead of using tools — its tool definitions fell out of the window.
• A model that benchmarks well behaves like a much dumber one — it is only seeing a fragment of your file.

The fix is the max_tokens field in available_models shown above — per-model, which beats the blunt global context_window override Zed also accepts. Sizing guidance: 16K is comfortable for inline assist and chat on real files; 32K minimum for agent work (the figure the Ollama-agent integrations converge on in their own docs); more if your VRAM allows.

The cost is memory: the KV cache scales with context, so doubling max_tokens roughly doubles the cache VRAM on top of the model weights. A 19GB model at 32K context on a 24GB card is comfortable; the same model at 128K is not. Set what the task needs, not what the model card brags about.

---

Which Model to Pull

One model cannot serve all three of Zed's AI surfaces well. The working setup is a pair: a small fast model for inline assist and completion, plus — if your hardware allows — a tool-calling model for the agent panel.

Download sizes below are what ollama.com lists per tag, checked August 2026; VRAM-at-load is higher once the KV cache is added:

Notes that matter more than the table:

• The 1.5B is better than it sounds for this job. Inline assist tasks are scoped — rename this, add a docstring, convert this loop — and a 986MB model answers them near-instantly even on CPU. It is the difference between local AI you actually leave enabled and a demo you tried once.
• The agent panel is why the 30B exists here. Qwen3-Coder is a mixture-of-experts model (30B total, ~3.3B active per token, per its model card), so it generates faster than a dense 30B while carrying a 256K native context and — critically — tool-calling training that the agent panel depends on.
• -base is not a typo. Completion models predict text continuations; instruct models answer questions. Zed's edit-prediction docs specifically use qwen2.5-coder:7b-base. Feeding an instruct model to completion gets you chatty, wrong suggestions.

For how these picks stack against the wider field — DeepSeek, Devstral, the bigger Qwens — see our best local AI models for programming ranking. For what your specific card can hold, the best coding LLM for 8GB VRAM and 24GB VRAM pages do the arithmetic.

---

Local Tab Completion

Zed's edit prediction — the tab-completion engine — accepts Ollama as a provider, which makes Zed the rare editor where even autocomplete never leaves your machine. This block enables it:

{
  "edit_predictions": {
    "provider": "ollama",
    "ollama": {
      "api_url": "http://localhost:11434",
      "model": "qwen2.5-coder:7b-base",
      "prompt_format": "infer",
      "max_output_tokens": 512
    }
  }
}

That config is verbatim from Zed's edit-prediction docs (model swapped for nothing — it is their example model). prompt_format: "infer" lets Zed pick the fill-in-the-middle prompt template for the model; max_output_tokens: 512 keeps suggestions snappy.

Why bother, when Zed's default Zeta model exists? Three reasons, all verifiable in Zed's docs:

• Zeta runs on Zed's servers and wants a sign-in. Local Ollama predictions need neither.
• The free plan caps Zeta at 2,000 predictions per month. Tab completion fires constantly; 2,000 goes fast. Ollama predictions are unlimited.
• Privacy is total. Completion providers see your code mid-keystroke — the most intimate telemetry an editor feature can have. localhost sees it instead.

The honest trade: Zeta is purpose-built for edit prediction and hosted on fast hardware; a local 7B base model on an 8GB card will feel a beat slower and suggest a beat dumber. Zed's docs also show running their open Zeta 2 model itself through Ollama ("model": "zeta2") — though it was not in the main Ollama library when we checked, so qwen2.5-coder:7b-base remains the pull-and-go path.

---

The Agent-Panel Caveat

Here is the part most Zed + Ollama tutorials skip: Zed's agent panel — the mode that plans and edits files across your repo — is documented by its own community as the weak link with local models. It works, but only with the right model, the right flags, and calibrated expectations.

The evidence is public, in Zed's GitHub discussion #33682 (running since mid-2025):

• Stock chat models silently fail at tool calling. The opening report describes an Ollama model configured for agent editing behaving "chat-like" — talking about edits instead of making them. A key finding from the thread: qwen2.5-coder "doesn't work with Zed out of the box" for agent use because the modelfile Ollama ships lacks a proper tool-calling template. The model is not refusing; it literally was not templated for the job.
• Even configured correctly, the gap to hosted models is real. A February 2026 summary in the thread, from a developer running a 32GB M1 Max, lists the persistent issues: buggy prompt templates producing corrupted output, KV-cache reuse failures that slow threads to a crawl, and context windows too small for real agent work. Their blunt verdict on agentic editing: locally-runnable models remain "much dumber than the large hosted models."
• As of mid-2026, the thread had reached no consensus fix for reliable agentic editing on typical hardware — several participants concluded hosted models were still the practical choice for agent threads specifically.

What this means in practice, not in doom: if you want to try local agentic editing anyway, stack the deck — a model trained for tool calling (qwen3-coder:30b, whose model card leads with its agentic training, is the accessible one) with supports_tools: true and max_tokens at 32K+, and scoped asks. Multi-file refactors with a dozen tool calls are where local agents wobble; "add tests for this file" or "fix this function" is a far fairer fight. And Zed's split of features is actually the advantage here: inline assist, chat, and edit prediction — the surfaces you touch a hundred times a day — are exactly the ones where local models are already excellent.

If agentic editing on local models is your primary goal and 24GB of VRAM is available, it is worth comparing how the dedicated agents handle the same constraint — our Cline guide covers the num_ctx and Modelfile surgery that community found, and Aider remains the most local-model-tolerant of the agents, by its own documented design goals.

---

Zed vs the VS Code Routes

Choose Zed + Ollama when you want the lowest-friction local setup and local completion; choose a VS Code extension when you need the deepest agent tooling or can't leave the VS Code ecosystem.

The pattern we keep landing on: Zed is the best editor experience wrapped around local AI — assist and completion feel native because they are built in, not bolted on. Continue.dev is its closest VS Code equivalent. Cline is the pick when the agent loop is the whole point. All three cost exactly nothing to run on the same pulled models, which is the quiet luxury of the Ollama ecosystem: switching tools is a dropdown, not a subscription decision.

---

Sources

• Zed docs: Use a Local Model — auto-discovery, available_models config, the 4,096-token default, OLLAMA_API_KEY
• Zed docs: Edit Prediction — Ollama provider config (verbatim), Zeta free-plan limit, provider list
• Zed docs: Agent Settings — default_model shape, per-feature model settings
• Zed GitHub repository — star count and stable release v1.14.2 (checked August 2026)
• Zed discussion #33682 — local-model agentic-editing reports and workarounds
• qwen2.5-coder and qwen3-coder Ollama model cards — tags, download sizes, context windows

---

FAQ