Best Local LLM for Coding in 2026 (Picked by Your Hardware)

The best local LLM for coding in October 2026 depends on your memory. With 24 to 32 GB of VRAM or Mac unified memory, run Qwen3.8 27B (dense, Apache-2.0, 18 GB on Ollama) or Devstral Small 2 24B (Apache 2.0, 15 GB). With 64 GB or more, try Qwen3-Coder-Next, an 80B mixture-of-experts coder with 3B active parameters (52 GB at 4-bit). On a 16 GB machine, gpt-oss 20B (14 GB) is the practical choice. All of them run in Ollama, LM Studio or llama.cpp, and all of them can drive agent tools such as Claude Code through a local API.

Quick picks

Sizes are the download sizes Ollama lists. Leave headroom for context: coding agents read a lot of files.

How to read coding benchmarks

Vendors publish their own numbers, usually on SWE-bench Verified, SWE-bench Pro, LiveCodeBench or Terminal-Bench. They are useful signals, with three caveats:

1. Different benchmarks are not comparable. SWE-bench Pro is harder than SWE-bench Verified, so a lower Pro score can mean a stronger model.
2. The harness matters. The same model scores differently depending on the agent scaffold and settings the vendor used.
3. Local quantization costs a little quality. Vendor scores are usually measured at full precision; your 4-bit download may do slightly worse.

So treat the numbers below as "worth trying", then test on your own repository.

The models in detail

Qwen3.8 27B: the best all-rounder for 24 to 32 GB

The Qwen3.8-27B model card describes a "compact, deployment-friendly dense model" with native vision, 262,144 tokens of native context (extendable to 1M with YaRN) and an Apache-2.0 license. Qwen reports 61.7 on SWE-bench Pro, 73.0 on Terminal Bench 2.1 and 90.3 on LiveCodeBench v6. On Ollama it is qwen3.8:27b at 18 GB, with an MLX build (27b-mlx) for Macs. It is also among the most downloaded models on Hugging Face right now.

Because it is dense, every token uses all 27B parameters, so it is slower per token than a 3B-active MoE model, but it tends to be more consistent.

Devstral Small 2: the agentic specialist on one GPU

Mistral's Devstral Small 2 is a 24B model with a 256k context and an Apache 2.0 license, built for software-engineering agents. Its model card lists 68.0% on SWE-bench Verified and says it is compact enough to run on a single RTX 4090 or a Mac with 32 GB of RAM. Ollama describes it as excelling "at using tools to explore codebases, editing multiple files". At 15 GB, it leaves more room for context than the 27B to 31B options.

Qwen3-Coder-Next: the dedicated coder for big-memory machines

Qwen3-Coder-Next is built on Qwen3-Next-80B-A3B: 80B total parameters with 3B activated per token, 256K native context, Apache-2.0. Its card lists 70.6 on SWE-bench Verified, 44.3 on SWE-bench Pro and 36.2 on Terminal-Bench 2.0, and names Claude Code, Qwen Code, Cline and others as supported agents.

The catch is memory. Only 3B parameters compute per token, which makes it quick, but all 80B must be loaded: 52 GB at q4_K_M and 85 GB at q8_0 on Ollama. That puts it in 64 GB Mac or multi-GPU territory.

Qwen3.6 35B-A3B: MoE speed in 32 GB

Qwen3.6-35B-A3B is a mixture-of-experts model with 35B total and 3B activated parameters under Apache-2.0. Ollama ships dedicated coding tags (for example qwen3.6:35b-a3b-coding, 23 to 24 GB) and lists "upgrades in agentic coding" in its description. If Qwen3.8 27B feels slow on your machine, this is the one to compare against.

gpt-oss 20B: the 16 GB option

OpenAI's gpt-oss 20B is Apache 2.0, supports tools and reasoning, and has its MoE weights quantized to MXFP4 (about 4.25 bits per parameter). Ollama says it runs on systems with as little as 16 GB of memory. It is a general model rather than a coding specialist, but it is the most capable option many 16 GB machines can hold with room for context.

Qwen3.8-Flash-Next: if you have 128 GB

Qwen3.8-Flash-Next is a 125B mixture-of-experts model with about 6B activated per token, released in August 2026 under the qwen-community-1.0 license (not Apache). Its card reports 62.5 on SWE-bench Pro. Ollama's MLX build is 105 GB, so this is for Mac Studio-class machines.

Still useful: older coding models

qwen2.5-coder (0.5B to 32B) and qwen3-coder (30B, 480B) remain among the most pulled coding models on Ollama. Newer models have overtaken them for agent work, but the small Qwen2.5-Coder sizes are still handy for fast autocomplete.

Hardware: weights plus context

For coding, context is not optional. An agent reads files, diffs and test output, and Ollama's docs recommend at least 64,000 tokens of context for coding tools. That context lives in the KV cache, which can add several gigabytes on top of the download size. A 15 to 18 GB model on a 24 GB card with 64k context is a comfortable fit; a 24 GB model on a 24 GB card is not.

Two ways to stretch memory:

• Quantize the KV cache. In Ollama, OLLAMA_KV_CACHE_TYPE=q8_0 uses about half the memory of the default f16 when flash attention is on.
• Prefer MoE on Macs with lots of memory. A 3B-active MoE model generates faster than a 27B dense one, as long as you can load it.

Our local LLM hardware guide shows the full arithmetic.

How to use a local model for coding

In Claude Code

Ollama has a one-command integration:

ollama launch claude

Or set it up by hand, as the Ollama docs show:

export ANTHROPIC_AUTH_TOKEN=ollama
export ANTHROPIC_API_KEY=""
export ANTHROPIC_BASE_URL=http://localhost:11434
claude --model qwen3.8:27b

Start the Ollama server with a bigger context first (OLLAMA_CONTEXT_LENGTH=64000 ollama serve). Ollama notes that hosted web search and some advanced tool controls are not fully supported this way. LM Studio also offers an Anthropic-compatible endpoint if you prefer it.

In other agents and IDEs

ollama launch also supports Codex, Copilot CLI, Droid and OpenCode. Any editor extension that accepts an OpenAI-compatible endpoint can use http://localhost:11434/v1 (Ollama) or LM Studio's local server. For a comparison of the main coding tools themselves, see Claude Code vs Codex vs Cursor and our best AI coding assistant guide.

Common problems and fixes

Local coding setups fail in predictable ways. Most are context or configuration problems, not model problems.

Two habits help any local model:

• Give it a project rules file. A short file describing the stack, test command and conventions, loaded at the start, saves the model from rediscovering them. This is basic context engineering.
• Keep tasks scoped. "Fix the failing test in billing/tax.py" works far better locally than "improve the billing module".

How to choose for yourself

Run this simple test on each candidate:

1. Pick three real tasks from your own repo: a bug fix, a small feature, and a refactor across files.
2. Run each model in the same agent with the same context length.
3. Score: did it finish, did tests pass, how many corrections did you make, and how long did it take?

You will learn more from an afternoon of this than from any leaderboard. A pattern that works well: a local model for private code, routine edits and offline work, and a frontier cloud model for the hardest problems. New to local models? Start with how to run an LLM locally.