The short answer: run the biggest open coding model your memory can hold. On a 24GB GPU or a 32GB Mac, install Qwen3-Coder-30B-A3B. On 16GB, run gpt-oss-20b or Qwen2.5-Coder-14B. On 8GB, run Qwen2.5-Coder-7B. Drive it with Ollama and wire it into your editor with Continue.dev or aider. Every model here is open-weights, runs entirely offline, and costs nothing per token. Here's the full pick-by-hardware, the VRAM math, and the exact commands.
Why run a model locally at all? Three reasons that a cloud API can't give you: your code never leaves the machine (the real reason most people do this), there's no per-token bill no matter how much you generate, and it works on a plane or an air-gapped network with no rate limits. The catch — covered honestly at the end — is that the very hardest agentic work still belongs in the cloud.
Pick your model by your hardware#
The single decision that matters is memory. A coding model's quality tracks its size, and its size is capped by the VRAM (or unified memory) you have. Find your row:
(The table above is the whole decision. The rest of this piece explains the models, the memory math, and the tools — skim what you need.)
The models worth running#
Qwen2.5-Coder (Alibaba, Apache 2.0) is still the reliable workhorse and the safe default on modest hardware. It comes in 0.5B through 32B sizes; the 7B fits 8GB comfortably and the 14B fits 16GB. It's the model to reach for when you want fast, dependable autocomplete and single-file help without fuss.
Qwen3-Coder-30B-A3B (Alibaba, July 2025) is the current sweet spot for anyone with 24GB of VRAM or a 32GB Mac. It's a 30.5B-total, 3.3B-active mixture-of-experts model with a native 256K-token context (extendable to 1M with YaRN), and because only 3.3B parameters are active per token it runs far faster than its total size suggests. On Ollama the qwen3-coder:30b tag is a single ~19GB file at 4-bit. This is the one to install if it fits — it's the best agentic, multi-file local coder most solo developers can actually run.
gpt-oss-20b (OpenAI, Apache 2.0, Aug 2025) is the standout on a 16GB machine. It's a 20.9B-total, 3.6B-active MoE with a 131K context that ships natively quantized in MXFP4, so it fits in 16GB of memory and delivers roughly o3-mini-class results with strong tool-use and adjustable reasoning effort. Its bigger sibling, gpt-oss-120b, runs on a single 80GB GPU and reaches o4-mini-class coding — out of reach for most laptops but worth knowing about if you have a workstation.
Devstral Small (Mistral, Apache 2.0) is the open, agentic-focused Mistral coder — built with All Hands AI for multi-file, tool-driven work, and it runs in about 14-16GB at 4-bit; its Devstral 2 successor shipped in December 2025 alongside Mistral's Vibe CLI. Note that Codestral is not a local option anymore — Codestral 25.01 and later are API-only. Use Devstral for the self-hosted Mistral experience.
Bigger, if you have the memory: GLM-4.5-Air (Z.ai, 106B-total/12B-active, MIT) and Llama 3.3 70B are the closest a single high-memory machine (64GB+ Mac, or 48GB+ of VRAM) gets to frontier quality, and DeepSeek's R1-Distill models (1.5B–70B) are the locally-runnable slice of DeepSeek's lineup — the full DeepSeek models are cloud-scale. The frontier-approaching open models — GLM-4.7 (355B), DeepSeek V4, Qwen3-Coder-480B — are too large to self-host on one machine; don't chase them locally.
How much VRAM you actually need#
The math is simple enough to do in your head. At 4-bit (Q4_K_M, the usual quality/size sweet spot), the weights need about 0.6GB of VRAM per billion parameters, plus a few GB for the KV cache and context. That gives you:
- 7B → ~4.7GB of weights, ~6-8GB in practice → runs on 8GB
- 14B → ~8-9GB → runs on 16GB
- 30-32B → ~18-20GB → runs on 24GB (Qwen3-Coder-30B is ~19GB)
- 70B → ~40-42GB → needs 48GB+ — no single consumer GPU fits it without slow CPU offload
Longer context costs more memory (the KV cache grows with it), so if you're tight, cap context at what you need rather than maxing it. On Apple silicon, unified memory is shared with the OS, so the tiers shift: a 32GB Mac comfortably runs a 30B model, 64GB reaches a 70B at 4-bit, and 128GB runs 70B at higher precision. If you're buying a GPU specifically for this, a 16GB card (around $350-430 in August 2026) is the value pick for coding models; 24GB is the sweet spot if you can stretch. For where cloud GPU rental sits by comparison, our GPU rental price map has the current H100/H200/B200 rates.
The tools that run it#
There are two layers: the runtime that serves the model, and the editor integration that puts it in your workflow.
Runtimes:
- Ollama — the one-command default.
ollama run qwen2.5-coder:7bdownloads, quantizes, and serves the model, exposing an OpenAI-compatible API onhttp://localhost:11434.ollama serveruns it in the background. Best for solo developers; weakest under heavy concurrency. - LM Studio — a desktop GUI with a model browser, one-click downloads, and a headless server on port 1234 (
/v1/chat/completions). It uses Apple's MLX backend on Mac. The friendliest on-ramp; see our Ollama vs LM Studio vs Jan breakdown to choose. - llama.cpp — the GGUF inference engine underneath most of the above; the fastest raw runner at a given quant, and the most portable. Reach for it when you want maximum control.
- vLLM — production, multi-user serving (PagedAttention, continuous batching) with far higher concurrent throughput. Overkill for one developer, essential if you're serving a team.
Editor integrations:
- Continue.dev — open-source, local-first autocomplete and chat for VS Code, JetBrains, and Neovim. Point its
apiBaseathttp://localhost:11434and you're coding against local weights. A common setup pairs a small 7B model for autocomplete with a larger one for chat. - Cline — an autonomous agent inside VS Code that reads files, plans, edits, and runs commands; point it at any OpenAI-compatible local endpoint.
- aider — the best terminal-first, git-aware workflow; it commits as it goes and runs happily against a local endpoint.
- Zed has built-in Ollama support; Cursor is cloud-first and only loosely supports local endpoints.
A concrete starting recipe: ollama pull qwen3-coder:30b (or qwen2.5-coder:7b on a small machine), install Continue.dev, set the model to your Ollama tag, and you have private autocomplete and chat in your editor in about five minutes.
Local vs cloud: the honest tradeoff#
Local wins clearly on four things: privacy (your proprietary code never leaves the machine), cost (zero per-token, so heavy generation is free after hardware), offline operation, and no rate limits or vendor deprecation. For a solo founder working on a private codebase, those are not small.
Where local still loses is the ceiling. Cloud frontier models — Claude, GPT-5-class, Gemini — remain ahead on large multi-file refactors, long-horizon agentic runs across a whole repository, and very long usable context. A well-chosen local model on a 24GB card now matches frontier models on single-file coding and test generation, but the gap reopens on the genuinely hard, sprawling tasks — and the open models that would close it are too big to self-host.
So the honest recommendation is hybrid: run Qwen3-Coder-30B (or gpt-oss-20b) locally for everyday, private, single-file and autocomplete work, and keep a cloud frontier model on hand for the hardest multi-file jobs. If you want to see where the paid agents land before you decide how much to offload, our AI coding-agent ranking and best LLM for coding comparisons cover the cloud side — and this morning's Founder's Wire has the news on GLM-5.3-Flash, a new MIT-licensed model you can also self-host.



