The two-model idea (read this first)

A good local setup uses two models, not one, because autocomplete and chat have opposite needs:

JobNeedsModel
Autocomplete Sub-second latency, fires on every keystroke qwen2.5-coder:1.5b
Chat / edits / agent Intelligence, big context, tolerable to wait a few seconds qwen3-coder:30b

Using one big model for both makes autocomplete unusably slow; using one small model for both makes chat dumb. The 30B is a mixture-of-experts, so despite its size it generates fast — see the Qwen3-Coder run page for hardware and speeds. On a 24GB card both models coexist comfortably; on 8–12GB, drop the chat model to qwen2.5-coder:7b.

Step 1 — Pull the models (5 min)

$ ollama pull qwen3-coder:30b # chat, edits, agent $ ollama pull qwen2.5-coder:1.5b # fast autocomplete

New to Ollama? The install-and-first-run basics are in our Ollama + Open WebUI tutorial.

Step 2 — Install Continue and wire up chat + autocomplete (10 min)

Install the Continue extension from the VS Code marketplace. It handles in-editor chat, inline edits (select code → Cmd/Ctrl+I) and tab autocomplete. Open its config (~/.continue/config.yaml) and point it at Ollama:

models: - name: Qwen3-Coder provider: ollama model: qwen3-coder:30b roles: [chat, edit, apply] - name: Autocomplete provider: ollama model: qwen2.5-coder:1.5b roles: [autocomplete]

Reload VS Code. You now have chat in the sidebar and gray autocomplete suggestions as you type. Autocomplete uses the tiny model, so it keeps up with your keystrokes; chat uses the 30B.

Step 3 — Add Cline for agentic edits (5 min)

Continue is great for "help me with this function." For "implement this feature across three files, run the tests, fix what breaks," you want an agent. Install Cline, set its API provider to Ollama and the model to qwen3-coder:30b. Cline plans, edits files, runs terminal commands and reads the output back in a loop — the same pattern as cloud agents, but local and free.

This is where a fast MoE model pays off dramatically: an agent task is dozens of generations, so the difference between 30 and 100 tok/s is the difference between minutes and coffee breaks.

Step 4 — Fix the context window (the #1 mistake) (5 min)

Ollama defaults num_ctx to a tiny 2K–4K window. An agent editing multiple files silently overflows it and starts "forgetting" the code it just read — the single most common reason people conclude "local coding models are bad." They aren't; they're being starved of context. Force a real window with a Modelfile:

$ cat > Modelfile <<'EOF' FROM qwen3-coder:30b PARAMETER num_ctx 65536 EOF $ ollama create qwen3-coder-64k -f Modelfile

Point Continue and Cline at qwen3-coder-64k instead. Mind the memory: a 64K context adds several GB of KV-cache on top of the weights — the exact math, and how to halve it with cache quantization, is in our KV-cache guide. If you're tight on VRAM, 32K is a sane compromise.

The honest verdict vs Copilot & Cursor

No hype — here is where a local setup wins and where it doesn't:

  • ✅ Privacy: your code never leaves your machine — the whole reason regulated teams and sovereignty-minded shops do this.
  • ✅ Cost: zero subscription, zero per-seat fees, works offline.
  • ✅ Autocomplete quality: with the two-model setup, genuinely close to Copilot for everyday code.
  • ⚠️ Agentic edits: good, but a frontier cloud model still plans multi-file changes more reliably. Local closes the gap every few months.
  • ⚠️ Hardware: you need a capable GPU. Below 12GB VRAM, expect a real quality drop from smaller chat models.

Want to try the 30B without owning a 24GB card? Rent one by the hour and run Ollama on it — see RunPod vs Vast.ai. And if this assistant is for a team, graduate the backend to vLLM in Docker so several developers share one GPU.