TL;DR: Kilo Code runs fully local against Ollama — pick the Ollama provider in the VS Code extension, raise the context window to at least 32K, and run qwen3-coder:30b on a 24GB GPU. The CLI is the trap: its provider picker only shows Ollama Cloud, and local wiring requires a manual kilo.json edit.

What you’ll be able to do after this guide:

• Run Kilo Code’s agent in VS Code against a local model with zero API spend and no code leaving your machine
• Set the two settings that decide whether the agent works or loops — context window size and request timeout
• Wire the Kilo CLI to local Ollama through ~/.config/kilo/kilo.json, the path the interactive picker doesn’t offer

Honest take: qwen3-coder:30b on a 24GB card is the setup to copy — devstral:24b is the fallback if Qwen’s tool calls flake on you. If you have neither the VRAM nor a 32GB Mac, skip local Kilo entirely and BYOK a cheap cloud model instead; a 7B model driving an agentic loop wastes more time than it saves.

Kilo Code became the default landing spot for a lot of displaced VS Code users this year — first the Roo Code shutdown in the spring, then Continue.dev’s cloud dying on July 15 after the Cursor acquisition. The extension is MIT-licensed, sitting at 26.5K GitHub stars, and shipping fast: v7.4.15 landed July 22, 2026, one day before this guide was verified. What most write-ups skip is that its local-model path has two sharp edges the official docs only partially flag — a context-window floor that silently breaks the agent when you miss it, and a CLI provider picker that pretends local Ollama doesn’t exist.

Everything below was verified July 23, 2026, against Kilo Code v7.4.15 and Ollama v0.32.3.

One naming trap before anything else: Ollama ≠ Ollama Cloud

Kilo’s settings expose two providers with nearly identical names, and picking the wrong one defeats the entire point of this setup:

• Ollama — connects to a local daemon you started with ollama serve. Your prompts and code stay on your machine.
• Ollama Cloud — a hosted service that runs inside Kilo’s gateway environment. It never touches localhost. Your code goes to a datacenter.

The distinction comes straight from Kilo’s own provider documentation, and it matters twice in this guide: once in the VS Code dropdown, and again in the CLI, where — as of v7.4.x — only the Cloud variant appears in the interactive picker. More on that below.

What you need

Kilo’s docs are blunt about hardware: a GPU with 24GB+ VRAM or a Mac with 32GB+ unified memory for acceptable performance on the recommended models. That’s not gatekeeping — it follows directly from the model sizes and the context window an agent needs:

	qwen3-coder:30b	devstral:24b
Download size (Q4)	~19 GB	~15 GB
VRAM for weights (Q4_K_M)	~18.7 GB	~14.6 GB
Architecture	MoE (3B active per token)	Dense
Speed on same GPU	Faster (fewer active params)	Slower
Known weakness	Occasional malformed tool calls	Heavier per token
Kilo docs’ verdict	Primary recommendation	Alternative

qwen3-coder:30b is Kilo’s official primary pick, and it earns it: the mixture-of-experts design activates roughly 3B parameters per token, so it generates fast for its size. The same MoE design is also its documented weakness — Kilo’s docs note it “occasionally struggles with tool invocation,” which in an agentic loop shows up as the agent stalling after a malformed tool call. We hit the same class of failure with Qwen MoE models in Cline last month (the qwen JSON tool-call loop); if it bites you in Kilo, switch to the dense devstral:24b and the problem usually disappears at the cost of some speed.

Sub-24GB cards aren’t useless — smaller models handle Kilo’s non-agent features like prompt enhancement fine — but don’t expect a 7B model to survive a multi-step agent task. For picking a model by the VRAM you actually own, the sister-site guide at runaihome.com’s local models by VRAM breakdown covers the full ladder.

Step 1: Install Ollama and pull a model

Install from ollama.com or your package manager, then start the daemon and pull the model in separate terminals:

$ ollama serve
# leave this running

$ ollama pull qwen3-coder:30b
pulling manifest
pulling 8f2ea23eb1a4... 100% ▕████████████████▏  19 GB
success

Confirm the daemon answers before touching Kilo — it saves you from debugging two layers at once:

$ curl http://127.0.0.1:11434/api/version
{"version":"0.32.3"}

Note the 127.0.0.1 instead of localhost. Node-based extensions sometimes resolve localhost to IPv6 ::1 while Ollama listens on IPv4, which produces a fetch failed that looks like Kilo’s fault but isn’t. If you hit connection errors anywhere in this guide, the fetch-failed troubleshooter covers every variant, including WSL and Docker.

Step 2: Configure the VS Code extension

In VS Code, open Kilo Code’s settings panel and go to Providers:

1. Set API Provider to Ollama — the local one, not Ollama Cloud.
2. Base URL: the default http://localhost:11434/v1 works for most setups; change it to http://127.0.0.1:11434/v1 if you see connection errors, or to your machine’s LAN address if Ollama runs on another box.
3. Model: select qwen3-coder:30b from the detected list.

Then the two settings that actually decide whether this works:

Context Window Size (num_ctx). Kilo’s docs set a hard floor: at least 32K tokens. This is the single most common reason local Kilo setups “don’t work.” Ollama truncates over-long prompts silently — no error, no warning — and recent Ollama builds auto-scale the default window to your VRAM, which on most consumer GPUs lands well below what an agent needs. Kilo’s system prompt plus tool definitions plus your file context can blow through a small window before the model sees your actual request, and the visible symptom is an agent that ignores instructions or loops. Set 32K minimum in the provider settings; Ollama’s own FAQ recommends 64K for coding tools and agents if your VRAM allows — the KV cache for the larger window is exactly what that 5GB of headroom on a 24GB card is for. The full mechanics, including the num_ctx-with-an-underscore spelling trap, are in our Ollama context length fix.

API Request Timeout. Kilo defaults to 10 minutes per request. A 30B model on consumer hardware chewing through a 32K-token prompt can legitimately need longer on big agentic steps. If tasks die with timeout errors mid-run, raise this in Settings → API Request Timeout before blaming the model.

Start with a small task — “add a docstring to this function” — before handing it a refactor. Local agents reward short conversations and focused prompts; Kilo’s docs say plainly that local models are more likely to loop or fumble tools than cloud models, and long contexts amplify both failure modes.

Step 3: The CLI — where the picker lies to you

Here’s the problem that generated a GitHub issue and zero official fixes: run the Kilo CLI, open the provider picker, and the only Ollama option listed is Ollama Cloud. A user on CLI v7.0.41 filed exactly this (Kilo-Org/kilocode #6871) with a working local daemon — curl returning the version, models pulled, everything healthy — and the issue was closed “not planned.”

The picker never got the option, but the config file path works and is now in the official docs. Edit ~/.config/kilo/kilo.json by hand:

{
  "provider": {
    "ollama": {
      "baseURL": "http://localhost:11434/v1"
    }
  },
  "model": "ollama/qwen3-coder:30b"
}

Two details that matter:

• The model ID uses the ollama/ prefix — ollama/qwen3-coder:30b, not the bare tag you’d give ollama run.
• Models Kilo doesn’t recognize need to be registered in the config with capability definitions before the CLI will drive them properly. Stick to the documented recommendations unless you enjoy schema archaeology.

Restart the CLI after editing and it picks up the local provider even though the interactive flow never offered it. It’s an odd gap — the extension treats local Ollama as a first-class provider while the CLI buries it in a hand-edited JSON file — but as of v7.4.15 that’s the state of things.

Where this setup breaks

Three failure modes dominate the issue tracker and Kilo’s own docs, in descending order of frequency:

The agent loops or ignores instructions. Context window, almost every time. Verify with ollama ps while a task runs — if the loaded context is smaller than what you set in Kilo, the setting didn’t take. Fix the provider setting, or set the window server-wide with OLLAMA_CONTEXT_LENGTH=64000 ollama serve.

Tool calls fail with qwen3-coder. The documented MoE quirk. Ollama’s parser has been improving on exactly this class of bug — v0.32.1 (July 16) shipped more reliable tool-response continuations for Gemma 4, and v0.32.3 fixed incomplete GLM tool-call finalization — but qwen3-coder still throws a malformed call now and then. Retry once; if it recurs on the same task, switch to devstral:24b.

Long tasks die at exactly 10 minutes. That’s the API timeout default, not a crash. Raise it.

And one honest structural limit no setting fixes: a 30B local model is not a frontier model. Kilo’s Orchestrator mode and its 500+ model gateway routing — the features that headline our three-way comparison with OpenCode and Cline — were built around cloud-class models. Local Kilo is the right tool for privacy-bound codebases, offline work, and burning zero API credit on routine tasks. It’s the wrong tool for the hardest 10% of agentic work, and pretending otherwise wastes afternoons.

FAQ

Is this actually free?

The extension and CLI are MIT-licensed and cost nothing; a local model has no per-token cost. Kilo sells an optional Kilo Pass credit subscription for its cloud gateway, but nothing in this guide touches it.

Can I use LM Studio instead of Ollama?

Yes — Kilo talks to any OpenAI-compatible endpoint, and LM Studio exposes one at http://127.0.0.1:1234/v1. The context-window rule carries over: set it in LM Studio before loading the model, or you get the same silent truncation.

Does a 32GB MacBook really run this?

It meets Kilo’s stated minimum for qwen3-coder:30b, with unified memory holding weights plus KV cache. Expect slower generation than a discrete 24GB card, and keep the context at 32K rather than 64K to leave room for the OS.

Why does my Kilo CLI only show Ollama Cloud?

Known gap, closed “not planned” upstream. Use the manual ~/.config/kilo/kilo.json config from Step 3 — it’s the documented supported path.

Which quantization should I pull?

The default Ollama tags for both recommended models are Q4-class, which is what the VRAM numbers in the table assume. Higher quants improve output marginally but eat the headroom you need for a 32K+ context window — on 24GB, the bigger window beats the bigger quant.

Sources

• Using Ollama with Kilo Code — Official Kilo docs
• Kilo-Org/kilocode — GitHub repository (v7.4.15, MIT license)
• Kilo Code CLI only offers Ollama Cloud — GitHub issue #6871
• Ollama releases (v0.32.3, tool-calling fixes) — GitHub
• Ollama FAQ — context length configuration (docs.ollama.com)
• qwen3-coder:30b — Ollama model library
• Devstral 24B VRAM requirements — willitrunai.com

Last updated July 23, 2026. Versions, defaults, and hardware guidance change frequently; verify against the official docs before committing to hardware.