Best Local LLMs for Coding in 2026: Open-Weight Models Compared

The best local LLM for coding is the strongest open-weight model whose license you can accept and whose weights plus KV cache fit your memory. In September 2026 that means Devstral Small 2 or Qwen3.8-27B on a 32 GB GPU, Qwen3-Coder-Next or gpt-oss-120b on a 128 GB machine, and GLM-5.3-Flash on multi-GPU servers.

Open-weight coding models moved fast in the last twelve months. Several now ship with tool-calling formats built for coding agents, 256K-token context windows, and mixture-of-experts (MoE) designs that keep only a few billion parameters active per token. That makes local coding practical on hardware a team can buy without a data-centre project.

This comparison covers ten models. Every license, parameter count, context length and release month below was checked against the vendor’s model card or announcement on 27 September 2026. Benchmark figures appear only where a vendor published them, with the benchmark named. Open-weight releases land monthly, so re-check the card before you standardise.

How to choose a local coding model

Five questions settle most shortlists, and they are worth asking in this order.

1. Can you use it commercially? A license that fails review ends the evaluation, however good the model is. Apache 2.0 and MIT are the easy cases. Modified MIT and custom licenses need a careful read.
2. Does it fit? All MoE experts must sit in memory, so total parameters set the memory bill. Active parameters set how many bytes are read per generated token, which is what decode speed depends on.
3. How much context will you actually serve? A 256K window on the card is a ceiling. The KV cache for each session grows with every token, and it often limits you before the weights do.
4. Was it trained for agentic tool use? Coding agents call tools on almost every turn. Prefer models whose card documents a tool-call format and names the harnesses it was tested with.
5. Can your runtime serve it correctly? New architectures need recent vLLM, SGLang or llama.cpp builds, and some ship custom chat encodings.

The same logic applies to general model selection. Our local LLM overview covers the basics if you are new to self-hosting.

The shortlist: ten open-weight coding models

Checked against vendor model cards on 27 September 2026. The 4-bit column is planning arithmetic: total parameters × 0.55 bytes, which allows for quantization scales and a few layers kept at higher precision. Where a vendor ships a native low-precision checkpoint, the column shows the published checkpoint size instead.

Notes on each model

Qwen3-Coder-Next

Qwen describes this as a model “designed specifically for coding agents and local development.” Only 12 of its 48 layers use full attention, with 2 KV heads each; the rest use linear attention. That keeps the KV cache unusually small for a 256K model. It runs in non-thinking mode only. The card asks for vLLM 0.15.0 or SGLang 0.5.8 or later with the qwen3_coder tool-call parser. Qwen’s launch post reports over 70% on SWE-bench Verified using the SWE-Agent scaffold.

Qwen3-Coder-30B-A3B-Instruct

The smaller agentic Qwen coder from July 2025. With 3.3B active parameters it reads few bytes per token, which suits single-GPU workstations. Its 48 layers each keep 4 KV heads, so long sessions cost more memory than they do on the Next model.

Qwen3.8-27B

A general model, not a coder, but Qwen reports 61.7 on SWE-bench Pro using the Claude Code harness on its refined version of the benchmark. Thinking is on by default. Budget for longer outputs or lower the reasoning effort per request.

Devstral Small 2 and Mistral Medium 3.5

Devstral Small 2 is the Apache 2.0 option from Mistral. The card says it is light enough for a single RTX 4090 or a Mac with 32 GB of RAM, and Mistral reports 68.0% on SWE-bench Verified. Mistral Medium 3.5 is a dense 128B model that now replaces Devstral 2 in Mistral’s Vibe CLI, with a reported 77.6% on SWE-bench Verified. Its Modified MIT license grants no rights to any company whose consolidated monthly revenue exceeded $20 million in the previous month. Most enterprises reading this will need a commercial agreement.

Gemma 4 31B

Google released Gemma 4 under Apache 2.0. The 31B dense model interleaves 1,024-token sliding-window layers with global attention layers, and Google reports 80.0% on LiveCodeBench v6. The 26B A4B MoE sibling trades some quality for speed.

gpt-oss-120b and gpt-oss-20b

OpenAI ships both models natively quantized in MXFP4, so the 120b runs within 80 GB and the 20b within 16 GB. The catch for tooling is the harmony response format. OpenAI states the models should only be used with it, so confirm your runtime applies the chat template correctly.

GLM-5.3-Flash

Z.ai’s MIT-licensed, multimodal MoE uses hybrid sparse and linear attention to cut long-context serving cost. The FP8 checkpoint is 328 GB, which puts it on multi-GPU servers or a 256 GB-class machine at 4-bit. The larger GLM-5.3 (753B) uses a separate GLM-5.3 License with a security-review clause for very large model-service operators.

DeepSeek-V4-Flash

The July release (V4-Flash-0731) supersedes the April preview and keeps the MIT license. DeepSeek’s preview card reports 79.0 on SWE-bench Verified in its maximum reasoning mode. The release ships no Jinja chat template. DeepSeek supplies Python encoding scripts instead, so check how your runtime formats prompts before trusting results.

Kimi K3

At 2.8T parameters, Kimi K3 is a rack-scale model: the MXFP4 checkpoint alone is about 1.56 TB. Its license exempts internal use from both the model-as-a-service condition and the display requirement, which matters for teams that only serve their own developers.

Left off the list

Codestral 22B remains under the Mistral AI Non-Production License, which forbids production use. Qwen3.8-Flash-Next ships under the Qwen Community License 1.0, which requires a separate license for any business offering a model service or an “AI Work Assistant” such as a coding product. Internal use is exempt, but software vendors should note it.

New open-weight coding models: October 2026 update

We repeated the search on 14 October 2026 across Hugging Face and vendor announcements. Six open-weight releases between 10 September and 13 October matter for local coding, and one of them is a new version of a shortlisted model. The 4-bit column uses the shortlist’s arithmetic. None of the six displaces a pick below the rack tier.

DeepSeek-V4.1-Flash succeeds V4-Flash, but at about 510 GB it outgrows the 256–512 GB tier. vLLM’s recipe moves its Engram memory tables into host RAM on H200, Blackwell and AMD Instinct servers. At maximum reasoning effort, DeepSeek’s card reports 74.2 on DeepSWE v1.1 with mini-SWE-agent and 69.8 with Claude Code as the harness. Since 1 October the repository has also held a Jinja chat template, merged from a pull request, although the card text still says the release has none. Our DeepSeek self-hosting review covers the server sizing.

On SWE-bench Verified, three of the new MoE models trail a Qwen model in their own vendor’s table. Kolibri 1 scores 66.4 against 73.8 for Qwen3.6-35B-A3B in the Harbor harness, Mellum2.1 scores 47.0 against 50.0 for Qwen3.5-9B in Pi, and LFM2.5 scores 51.00 against 66.20 for Qwen3.6-35B-A3B in OpenCode. Kolibri also needs Aleph Alpha’s vLLM plugin, and Liquid AI’s license withholds commercial rights from organisations with annual revenue of $10 million or more.

Bonsai 2 27B is Qwen3.8-27B compressed to ternary weights by Prism ML. Its card reports coding scores level with full precision on HumanEval+, MBPP+ and LiveCodeBench but no SWE-bench or Terminal-Bench result, and the GGUF files need Prism ML’s fork of llama.cpp. Xiaomi’s MOPD checkpoint targets agents that keep issuing the same tool call; its card publishes no coding scores.

Qwen has not released a Qwen3.8 35B. The “Qwen3.8-35B-A3B” distill on Hugging Face comes from a third party, Empero, and is built on Qwen3.6-35B-A3B. Qwen3.8-Flash-Next, GLM-5.3-Flash and Kimi K3 still carry the weights, licenses and cards we checked in September.

We re-checked every shortlisted model’s Hugging Face repository on 14 October 2026: none has changed its weights, license or model card since 27 September, and the only new commit, on GLM-5.3-Flash, adds a benchmark result to its metadata.

Memory arithmetic for coding workloads

Three terms decide whether a model fits:

• Weights ≈ total parameters × bytes per parameter: about 2 at BF16, 1 at 8-bit, 0.5 to 0.6 at 4-bit.
• KV cache per token = 2 × full-attention layers × KV heads × head dimension × bytes per value. Multiply by tokens in context and by concurrent sessions.
• Headroom of 10 to 20 percent for activations, the runtime and fragmentation.

Three worked examples, using layer and head counts from each model’s config.json and a 16-bit KV cache:

The Devstral row shows why context is the variable to watch. A 24B dense model with 40 attention layers needs more memory for one 128K session than for its weights. Storing the KV cache at 8-bit halves that term; vLLM, for example, supports an FP8 KV cache. Our GPU sizing method walks through the same arithmetic for concurrency planning.

Hardware tiers for local coding

Memory capacity decides the tier. Memory bandwidth and active parameters decide how quickly tokens arrive. A 3B-active MoE reads about a ninth of the weight bytes per generated token that a 27B dense model reads, which is why MoE coders suit bandwidth-limited unified-memory machines. We compare the three popular desk-side boxes in our DGX Spark, Mac Studio and Ryzen AI Max comparison.

Serving the model and connecting a coding agent

Runtimes

• Ollama is the quickest start. Its docs describe connecting Claude Code through Ollama’s Anthropic-compatible API and advise a context of 64K or more for larger repositories. Aider’s docs warn that Ollama’s default context is small and silently drops what overflows, so set it explicitly.
• LM Studio exposes OpenAI-compatible and Anthropic-compatible endpoints, and ships a headless daemon, llmster, for servers.
• llama.cpp (llama-server) offers OpenAI-compatible routes, Anthropic Messages compatibility, and tool calling with the --jinja flag.
• vLLM and SGLang are the production-style options. Tool calls need --enable-auto-tool-choice plus the parser the model card names.
• MLX-LM runs and quantizes models natively on Apple silicon.

Coding agents and editors

General agent harnesses follow the same endpoint pattern. Our guide to running OpenClaw or Hermes Agent locally covers that setup. For the wider tool landscape, see our on-prem coding assistant comparison.

Local coding LLMs vs Claude Code

Claude Code is Anthropic’s agentic coding tool. Anthropic’s overview describes it reading a codebase, editing files, running commands and working with development tools from the terminal, IDE extensions, a desktop app or the browser. Comparing it with a local model comes down to two questions: where your code goes, and how much coding ability you give up by keeping it on your own hardware.

Where Claude Code sends your code

Checked against Anthropic’s documentation on 2 October 2026:

• The client is local; the model is not. Claude Code runs on the developer’s machine and sends prompts and model outputs over TLS to the model provider (data usage). The conversation it sends also includes tool results, such as the contents of files it opens.
• Five inference routes, all Claude models. Anthropic’s own API (Team and Enterprise plans or a Console key), Amazon Bedrock, Claude Platform on AWS, Google Cloud’s Agent Platform (formerly Vertex AI) and Microsoft Foundry (deployment options). Picking a cloud provider changes whose cloud receives the code, not whether it leaves your network. On Foundry’s Hosted on Azure option, prompts and completions stay within Azure.
• Commercial terms exclude training. Anthropic does not train models on code or prompts sent under commercial terms unless the customer opts in. Standard retention is 30 days, and zero data retention is available to qualified Enterprise accounts.
• Self-hosted runners still call Anthropic. Self-hosted environments, in public beta for Team and Enterprise plans, keep checkouts and build artifacts on your machines while session content still goes to api.anthropic.com for inference.
• Gateways stay on Claude. You can route Claude Code through your own LLM gateway with ANTHROPIC_BASE_URL, but Anthropic does not support sending it to non-Claude models through any gateway. The Anthropic-format endpoints in Ollama, LM Studio and llama.cpp described above make a local pairing work in practice, outside that support boundary.

Coding benchmarks: local models vs Claude

Vendor scores come from different harnesses and settings, so a model card’s number cannot be ranked against Anthropic’s. Two public leaderboards run Claude and open-weight models through one harness:

What the numbers say, read on 2 October 2026:

• The newest Claude models have since reached Terminal-Bench, not SWE-bench. When we re-read the Terminal-Bench 4.0 board on 14 October 2026, it listed Claude Opus 5.5 at 64.8% and Claude Sonnet 5.5 at 61.8%, both at max effort in Claude Code; Anthropic’s own runs had reported 66.4% (22 September 2026) and 70.6% (28 September 2026). GLM-5.3 at 41.8% was still the top open-weight entry.
• The gap varies by benchmark. In the same Claude Code harness, GLM-5.3 trailed Opus 5 by ten points at max effort. On the February SWE-bench run, the strongest open-weight model finished one point behind the strongest Claude model.
• The close contenders are large. Every open-weight model in those rows has more than 200 billion parameters, which means server-class or high-memory hardware rather than a developer workstation. Devstral Small 2 (24B) from the shortlist above resolved 56.4% of SWE-bench Verified with an earlier version of the same harness (1.17.2, December 2025).

Local model or Claude Code: which fits

Whichever side you choose, run a pilot on your own repositories: a model that leads a public board can still stumble on your build system, your conventions or your test suite.

Governance for enterprise source code

Running the model locally moves inference inside your boundary. It does not by itself make the setup governable.

• License. Store the license file with the weights and record which version you approved. Revenue caps, model-service clauses and display requirements differ between the Mistral, Kimi and Qwen community licenses above. Our note on open-weight licensing terms covers the review.
• Data egress. Mirror weights to an internal registry and verify checksums, so developer machines never pull from the internet. Audit the harness too: editor extensions, update checks and web-fetch tools can still call out when the model is local.
• Audit. Log the model version, prompts, tool calls, file diffs and the developer who approved each change. A shared internal endpoint with per-developer credentials makes this possible. A model running on every laptop does not.
• Execution. Coding agents run shell commands. Run them in containers or sandboxes without production credentials, SSH keys or cloud CLIs.
• Artifacts. Community quantizations, such as the GGUF builds some model cards point to, are third-party files. Evaluate the exact file you deploy against your own test set, not the vendor’s full-precision scores.

How VDF AI fits

VDF Code is VDF AI’s coding assistant for teams that need this governance built in. According to its product page, it ships extensions for VS Code, JetBrains IDEs, Neovim and Visual Studio. It deploys in your VPC, on-premises on Kubernetes, OpenShift or bare metal, or fully air-gapped with signed offline update bundles. The on-premises tier includes open-weight model hosting for model families such as Qwen, Mistral and DeepSeek.

Teams that end up running more than one local model can put the choice in policy. VDF AI Router registers Ollama and custom on-premises deployments alongside approved cloud models, and its air-gap mode restricts routing to local models only. Shortlist two candidates from the table above, test both on your own repositories, and let routing rules decide which one serves each request.