Kodo Now Runs Fully Offline — Local Models, No Internet Required

Coding Doesn't Stop When the Wi-Fi Does

Every AI coding tool we've shipped so far has shared one dependency: a network connection. Fine, most of the time — until you're on a flight, in a client's air-gapped facility, on a train through a dead zone, or just sitting behind a corporate firewall that won't let traffic anywhere near a model API. In those moments, your AI assistant goes dark exactly when you still need to ship.

Starting today, it doesn't have to. Kodo now runs entirely offline, powered by local models on your own machine. No API calls, no network requests, no data leaving your laptop.

$ kodo --local "refactor this component to use the new data layer"

Same CLI, same IDE extensions, same workflow — just pointed at a model running on your own hardware instead of a hosted endpoint.

Why We Built This

A few reasons kept coming up in requests from the community:

No connectivity, no problem. Flights, trains, remote job sites, disaster-recovery drills — plenty of real engineering happens somewhere without reliable internet.
Air-gapped and regulated environments. Defense contractors, healthcare systems, and financial institutions often can't send code to a third-party API at all, full stop. Local inference is the only option that clears their security review.
Zero data egress. Even with encryption in transit, some teams want a stronger guarantee than "we don't store your code" — they want *nothing leaves the machine*, verifiable by watching the network interface.
Zero marginal cost. Once a model is downloaded, running it locally doesn't touch your credit balance. For high-volume, low-stakes tasks — linting passes, doc generation, boilerplate — that adds up.

Local mode doesn't replace hosted models. It's a mode you drop into when the situation calls for it, and Kodo makes switching between the two a non-event.

How It Works

Kodo's local mode talks to whichever inference runtime you already have installed. We didn't want to force a new tool into your setup, so we built support for the three most common ones:

Ollama — the easiest path if you're starting from scratch
LM Studio — a good fit if you prefer a GUI for managing models
llama.cpp server — for anyone who wants full control over quantization and runtime flags

Kodo auto-detects a running local server on startup. If it finds one, --local just works. If it doesn't, it tells you exactly what's missing instead of failing silently.

$ kodo --local status

✓ Ollama detected on localhost:11434
✓ Model available: qwen2.5-coder:32b
✓ Offline mode ready — no network calls will be made

Recommended Models for Local Coding

Not every open-weight model is worth running locally for coding work — context handling and tool-calling reliability vary a lot once you're off a hosted API. A few that have held up well in our testing:

Qwen2.5-Coder (32B) — our default recommendation. Strong all-around coding performance and reliable tool use, and it fits comfortably on a single 24GB GPU when quantized.
DeepSeek-Coder-V2 (16B) — lighter weight, still sharp on everyday tasks like refactors and test generation, and fast enough to feel responsive on a laptop GPU.
Llama 3.3 (70B) — the best reasoning of the group if you have the VRAM to spare (or the patience to run it on CPU).
CodeGemma (7B) — the fallback for modest hardware. Not a frontier model, but genuinely useful for boilerplate, docstrings, and quick lookups when that's all you need.

$ ollama pull qwen2.5-coder:32b
$ kodo --local --model qwen2.5-coder:32b "write tests for the auth service"

Quantized (4-bit and 5-bit) versions of all of these work fine with Kodo — trade a little quality for a lot less VRAM, which is usually the right call on a laptop.

Hybrid Setups: Local by Default, Cloud When You Want It

Most people won't run local-only. The more common pattern is local by default, with hosted models available on demand for the tasks that benefit from more horsepower. You can wire that up directly in .kodo.config:

{
  "defaultModel": "local:qwen2.5-coder:32b",
  "offlineFallback": true,
  "modelOverrides": {
    "architecture/**": "claude"
  }
}

With offlineFallback set, Kodo checks connectivity before every request. If you're online, it routes normally. If you're not, anything that would have gone to a hosted model automatically falls back to your local one instead of erroring out.

Getting Started

If you already have Ollama installed, you're most of the way there:

$ ollama pull qwen2.5-coder:32b
$ kodo --local "explain this codebase to me"

Starting from nothing:

$ npm install -g @eldlabs/kodo-cli
$ kodo init
$ ollama pull qwen2.5-coder:32b
$ kodo --local "walk me through this project's structure"

No Ollama? kodo init --local will detect that and walk you through installing it, pulling a recommended model, and verifying offline mode before you write your first prompt.

What's Next

This is a first release, not a finished feature. On the roadmap: better guidance for picking a model based on your actual hardware, support for running local models alongside a project-specific fine-tune, and tighter integration so local and hosted sessions share the same context history seamlessly. If you hit rough edges, we want to hear about them.

Running Kodo fully offline in a regulated or air-gapped environment? We'd love to hear how it's going — find us on [Discord](#).