Kilo Code + Ollama: Free Local AI Coding Agent in VS Code

Short answer: yes — Kilo Code (26.7K GitHub stars, MIT, v7.4.20 as of August 2026) runs fully local on Ollama in VS Code and JetBrains. Open Settings → Providers tab → select Ollama (not Ollama Cloud), pick your model as ollama/qwen3-coder:30b (19GB download, 24GB-VRAM class), and raise Context Window Size (num_ctx) to at least 32K — Kilo's own docs say "you need to have at least 32k to get decent results." One hard limitation up front: the Kilo CLI does not support local Ollama (two feature requests closed as "not planned") — local models are an extension feature only.

That paragraph is the whole setup. The rest of this guide is the part that keeps it working: why the 32K context rule exists, which models are honestly usable at each VRAM tier, the four gotchas people keep filing GitHub issues about, and how Kilo compares to Cline — its closest relative — for local work. Everything here was verified against Kilo's official Ollama docs, the GitHub repo, and Ollama's model cards in August 2026.

---

What Kilo Code Is (and What Happened to Roo Code)

Kilo Code is a free, MIT-licensed AI coding agent for VS Code and JetBrains — 26.7K GitHub stars and 1.38M+ VS Code Marketplace installs as of August 2026 — and it is the de facto successor to Roo Code, which shut down in May 2026.

The lineage matters because it answers the question most people arrive with. Kilo's own migration guide states it plainly: "We started Kilo as a Roo fork in 2025. The two codebases share real git history." Roo Code itself was a fork of Cline. Then in April 2026 Roo's maintainer announced the shutdown — "Roo Code hit 3 million installs. We're shutting it down to go all-in on Roomote" — and archived the repo on May 15, 2026. Kilo published an official Roo-to-Kilo migration path (your .roorules, custom modes, and MCP configs carry over; API keys don't), and it is now where most of that ecosystem landed.

Two things distinguish Kilo from the tool it forked:

• It's a platform, not just an extension. VS Code, JetBrains, a CLI, and five task modes (Code, Plan, Ask, Debug, Review) plus inline autocomplete. The extension is the part that matters for local models.
• It has commercial backing. Anaconda acquired Kilo Code on July 15, 2026. In a fork family where the previous champion just folded, a funded maintainer is a real argument — release v7.4.20 shipped the day before we checked, so the cadence is alive and well.

The fork-family churn cuts both ways, though, and we'd be doing you a disservice to skip it: Cline → Roo → Kilo is three generations in about two years, and Roo died at 3 million installs. Kilo looks like the stable branch now — Anaconda's backing is the best evidence — but if you build your workflow on any of these tools, keep your rules files portable. (They mostly are: AGENTS.md and MCP configs travel well.)

Why run it on Ollama at all? Same three reasons as every local agent: $0 in subscriptions and per-token bills, code that never leaves your machine, and no rate limits. Kilo's cloud gateway advertises 500+ models; the local provider trades that catalog for privacy and a price of zero.

---

The 5-Minute Setup

Four steps: install Ollama, pull a model, install the Kilo Code extension, point its Ollama provider at localhost. No API key exists anywhere in this flow.

1. Install Ollama (skip if it's already running):

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

# Start the daemon if it isn't running
ollama serve

2. Pull a coding model. Kilo's Ollama docs recommend exactly two, and we'd start with the same one (full reasoning in the model section):

# Kilo's primary recommendation — needs ~24GB VRAM class hardware
ollama pull qwen3-coder:30b

# Their listed alternative — 14GB download, dense 24B agent-tuned model
ollama pull devstral:24b

3. Install the extension. VS Code → Extensions (Ctrl+Shift+X / ⇧⌘X) → search "Kilo Code" → Install. The Kilo icon lands in the Activity Bar. (JetBrains users: the plugin is on the JetBrains Marketplace and the provider config below is the same.)

4. Configure the Ollama provider:

1. Click the Kilo Code icon, then the settings gear in its panel.
2. Open the Providers tab.
3. Select Ollama — the local one. There is a separate Ollama Cloud entry for Kilo's gateway; picking that one is the single most common wrong turn (see gotchas).
4. Leave the base URL at the localhost default unless Ollama runs on another machine.
5. Pick your model — Kilo uses the ollama/<model_name> format, so the pull above appears as ollama/qwen3-coder:30b. If nothing appears, confirm with ollama list that the model is actually pulled.
6. Set Context Window Size (num_ctx) to 32768 or higher. This is the step that decides whether the agent works. Next section explains why.

Test it: open a repo, switch Kilo to Code mode, and give it something small — "add input validation to this function." If it plans, edits, and finishes, you're done. If it stalls after a step or two, you skipped step 6.

---

The 32K Context Rule

Kilo's official Ollama docs put the requirement in one sentence: "You need to have at least 32k to get decent results." Ollama's default context is 4,096 tokens (per its FAQ) — an eighth of the minimum — and an agent on a 4K window doesn't degrade gracefully, it silently breaks.

Here's the failure mechanism, because recognizing it saves you a debugging session: an agentic tool like Kilo stuffs a large system prompt, tool definitions, file contents, and the running conversation into every request. On a 4K window that overflows almost immediately, Ollama truncates from the top, and the model loses the very instructions that tell it how to call tools. From the outside it looks like the model "forgot" the task, re-reads the same file forever, or emits malformed tool calls. People blame the model; it's the window.

Kilo makes the fix easier than most of its relatives — it's a first-class setting, no custom Modelfile required:

• In Providers → your Ollama profile, set Context Window Size (num_ctx) to 32768 (or 65536 if your VRAM allows — more below).

Two alternates if you'd rather fix it at the Ollama layer, where it applies to every client at once:

# Session-wide: restart the daemon with a bigger default
OLLAMA_CONTEXT_LENGTH=32768 ollama serve

# Permanent per-model tag: bake it into a Modelfile
# Save as "Modelfile", then: ollama create qwen3-coder-32k -f ./Modelfile
FROM qwen3-coder:30b
PARAMETER num_ctx 32768

The cost of context, stated honestly: the KV cache grows with the window, on top of the model weights. On a 24GB card, a Q4 30B-class model at 32K is comfortable and 64K is workable; chasing qwen3-coder's full 256K native window on consumer hardware means offloading and a crawl. Size the window to your tasks, not to the model card's maximum. Kilo's docs make the same point — bigger values "increase memory usage and may impact performance."

---

Which Local Model to Run

Run qwen3-coder:30b if you have 24GB of VRAM or a 32GB+ unified-memory Mac — it's Kilo's own primary recommendation. Take devstral:24b as the dense alternative at 14GB. Below 16GB, drop to Qwen2.5-Coder and scale your expectations with the parameter count.

Specs below are from each model's Ollama library page; the SWE-bench figure is Mistral's own reported number, not our measurement:

The honest fine print, straight from the source: Kilo's docs note that even their recommended qwen3-coder:30b "occasionally struggles with tool calls," and that local models in general are "much more likely to get stuck in loops, fail to use tools properly or produce syntax errors" than cloud frontier models. That is our experience with this model class too — 30B-class local coders are genuinely useful agents with occasional babysitting, not set-and-forget.

Which also frames the 7B question people keep asking: can you run Kilo on a small model? You can select one, and Kilo's docs themselves say smaller models are fine for the light features — Enhance Prompt, commit-message generation. But agentic multi-step editing is the hardest thing you can ask a local model to do, and tool-call reliability falls off fast below ~14B. On an 8GB card, treat Kilo's agent modes as a "scoped, single-file edits" tool and expect to interrupt loops. For the field beyond Kilo's two picks — and honest notes on what each size class can actually do — our best local models for programming ranking is the deeper reference.

One sizing note: download size is not VRAM-at-load. Weights plus KV cache plus runtime overhead is the real number, and it grows with the num_ctx you just raised. Our Ollama RAM/VRAM table maps model-by-model what actually fits.

---

Gotchas From the Issue Tracker

Four failure modes account for most "Kilo + Ollama doesn't work" reports on GitHub. All four are avoidable in setup.

1. The CLI doesn't do local Ollama — at all. This is the big one, and it's a decision, not a bug: feature requests for local Ollama in the Kilo CLI were filed in February 2026 (#6326) and again in March (#6871 — "the CLI only allows me to select Ollama Cloud"), and both were closed as not planned. The Kilo CLI is a fork of OpenCode wired to Kilo's cloud gateway; local models live in the VS Code and JetBrains extensions. If a terminal agent on local models is what you actually want, use a tool built for it — Aider has first-class Ollama support.

2. "Ollama" vs "Ollama Cloud" confusion. The provider list contains both, and users have filed bugs after finding only "Ollama Cloud" where they expected their local daemon (issue #8491, April 2026 — the reporter's local setup worked in JetBrains while VS Code showed only the cloud entry). If you don't see the local Ollama provider: update the extension first (releases ship near-daily), confirm ollama serve is actually running, then restart VS Code so the extension can detect the daemon.

3. Silence instead of errors. Issue #3348 is the archetype: models show up in Kilo's dropdown, the request visibly hits Ollama, and no response ever arrives — on a CPU-only Windows/WSL2 machine. Two things gang up here. First, CPU-only inference on a 30B-class model is slow enough that a response may not land within any reasonable window. Second, Kilo's API Request Timeout defaults to 10 minutes — a slow first token on cold model load plus a big context can blow through it, and what you observe is a hang. Fix: raise the timeout in Kilo Code's settings (Extensions panel → Kilo Code gear → Settings → API Request Timeout), warm the model first with a trivial ollama run prompt, and be honest with yourself about CPU-only agentic coding — it technically functions and practically doesn't.

4. The context window, again. It's gotcha #4 only because we gave it its own section. If the agent loops, forgets, or mangles tool calls: num_ctx, always num_ctx first.

---

Kilo Code vs Cline

Same family, same local-model mechanics, different trade: Cline has the bigger community (65.8K stars vs 26.7K), Kilo has more built in — autocomplete, five modes, and a context-window setting that saves you the Modelfile dance.

We maintain a full Cline + Ollama guide, so here's just the decision layer:

Because Kilo descends from Roo which descends from Cline, your intuition transfers almost completely — the provider config, the approval flow, and crucially the same context-window trap. Our first-hand throughput numbers were measured in Cline rather than Kilo, so we'll point you at them rather than re-badge them: on an RTX 3090 running a 24B dense model at 64K context we saw roughly 18-22 tok/s in agent loops (details in the Cline guide) — the same model class in Kilo's harness should land in the same neighborhood, but treat that as an inference, not a measurement.

If what you actually want is inline completion rather than an autonomous agent, skip both and set up Continue.dev + Ollama — lighter models, lighter footprint. And for the whole landscape ranked side by side, see our best AI coding tools roundup.

---

Hardware Reality Check

Kilo's docs set the bar themselves: "a GPU with a large amount of VRAM (24GB or more) or a MacBook with a large amount of unified RAM (32GB or more)" for the recommended models. Below that, you're trading down the model, the context, or both.

The agent workload is unusually context-hungry — that's why this table is more conservative than a chat-use table for the same GPUs. For picks tuned to each tier, see best coding LLMs for 24GB VRAM at the comfortable end and best coding LLMs for 8GB VRAM at the honest-compromise end.

---

Where Local Kilo Falls Short

A well-configured local Kilo is a real daily driver for scoped, private work — and it is not frontier-cloud-class on hard multi-file tasks. Kilo's own documentation says as much, which is to their credit.

What works well on a 24GB-class setup: single-concern edits, test generation, boilerplate, codebase Q&A, refactors with clear boundaries. What still favors cloud models: long-horizon multi-file refactors, ambiguous specs, and marathon agent sessions — the places where a 30B model loses the thread and a frontier model doesn't. The pragmatic pattern is the same one we recommend in every guide in this series: local for the bulk of daily, private, unlimited work; cloud for the occasional genuinely hard task.

Two Kilo-specific caveats to carry forward:

• Fork-family risk is nonzero. Roo Code died this year at 3 million installs. Kilo's Anaconda acquisition (July 2026) and near-daily releases are the counter-evidence, and it's currently the healthiest branch of the family — but keep your AGENTS.md rules and MCP configs portable, because in this family, they're what survives.
• The local story is extension-only. No local Ollama in the CLI, closed as not planned. Plan your workflow around the editor.

---

Sources

• Kilo Code Ollama provider docs — provider config, ollama/<model> format, the 32K minimum, model recommendations, hardware guidance, timeout (checked August 2026)
• Kilo Code GitHub repository — stars, MIT license, v7.4.20 release (August 4, 2026); issues #3348, #6326, #6871, #8491
• Kilo's Roo-to-Kilo migration guide — Roo fork lineage quote, Roo shutdown timeline, what migrates
• Kilo blog: Anaconda acquisition — July 15, 2026
• qwen3-coder and devstral Ollama model cards — download sizes, context windows, parameter counts, Mistral's SWE-bench figure
• VS Code Marketplace listing — install count, version (checked August 2026)

---

FAQ