That recommendation changes with the job. Qwen3-Coder-Next is stronger for demanding coding agents if you have at least 64GB of usable memory. Devstral Small 2 is a dependable dense model for repository work on a single high-end GPU. Qwen2.5-Coder 14B remains the sensible mid-range choice, while StarCoder2 7B is more appropriate for low-latency fill-in-the-middle completion on modest hardware.

This comparison does not rank models from headline coding benchmarks alone. It assesses practical memory requirements, quantisation, expected speed on realistic hardware, repository context, fill-in-the-middle support, tool calling, agent compatibility, licences and the cost of maintaining a local coding stack. Readers who need the deployment basics first should start with DIY AI’s guide to what a local LLM is.

Best local coding LLMs: quick comparison

Model	Best for	Practical local floor	Sensible quantisation	Expected generation speed	Main limitation
Qwen3-Coder-30B-A3B-Instruct	Best overall local coding model	24GB VRAM or 32GB unified memory	Q4_K_M or Q5_K_M	Roughly 35-60 tokens per second on an RTX 4090-class GPU	The full 256K context is not realistic on minimum hardware
Qwen3-Coder-Next	High-end local coding agents	48GB VRAM at the edge, 64GB or more preferred	Q4_K_M or Q5_K_M	Roughly 10-25 tokens per second on a well-configured 48-64GB system	Its 80B total weights make it expensive to load despite only 3B active parameters
Devstral Small 2 24B	Dense agent model on one high-end GPU	24GB VRAM or 32GB unified memory	Q4_K_M to Q6_K	Roughly 25-45 tokens per second on an RTX 4090-class GPU	Dense inference is less efficient than comparable sparse models
North Mini Code 30B-A3B	Open agent workflows and harness portability	24GB VRAM or 32GB unified memory	FP8 where supported, otherwise Q4 or Q5 GGUF	Roughly 30-55 tokens per second on an RTX 4090-class GPU	Fewer mature consumer-runtime recipes than Qwen
Qwen2.5-Coder 14B Instruct	Mid-range GPUs and code chat	12GB VRAM or 16GB system memory	Q4_K_M or Q5_K_M	Roughly 25-45 tokens per second on a modern 16GB GPU	Less reliable for long autonomous agent runs
StarCoder2 7B	Low-VRAM autocomplete and fill-in-the-middle	8GB VRAM or 16GB system memory	Q4_K_M or Q5_K_M	Roughly 40-80 tokens per second on a 12GB consumer GPU	Shorter context and weaker instruction-following than newer agent models

The speed ranges above are planning estimates, not DIY AI benchmark results. Runtime, backend, context length, prompt processing, GPU offload, memory bandwidth, operating system and quantisation can move performance substantially. Measure both prompt processing and token generation on the machine that will do the work.

---

---

How we judge a local coding model without over-trusting benchmarks

A coding benchmark usually tests one model under one scaffold, prompt format, tool set and execution budget. Change the harness, and the result can change sharply. Local users also run quantised weights, smaller context limits and less optimised inference stacks than benchmark labs.

The useful evaluation unit is therefore not the model alone. It is the complete local coding system:

• Model weights: the exact release, instruction tuning and quantisation.
• Inference runtime: llama.cpp, Ollama, MLX, vLLM, SGLang or another backend.
• Context method: full-file injection, repository map, embeddings, search tools or agent-led file discovery.
• Harness: the IDE extension or CLI that formats messages, exposes tools and applies edits.
• Verification loop: the commands, tests, linters and review rules used before accepting a change.

A recurring real-world failure is a tool-call mismatch rather than poor code reasoning. The model may output a shell command as ordinary prose, repeat a malformed JSON call or keep retrying an edit because the runtime and agent disagree about the expected template. Before rejecting a model, confirm that the runtime supports its architecture, chat template and tool-call parser.

DIY AI’s broader AI model comparison is useful for comparing hosted and general-purpose models. This page uses a narrower decision framework because local coding adds hardware fit, quantisation and maintenance overhead that general model rankings rarely capture.

Qwen3-Coder-30B-A3B-Instruct is the best overall local LLM for coding

Qwen3-Coder-30B-A3B-Instruct is the strongest default for a serious home workstation. It has 30.5 billion total parameters but activates about 3.3 billion for each token. That sparse architecture gives it a useful combination: the weight file is large enough to contain broad coding knowledge, while generation can be faster than a similarly sized dense model.

A good Q4 build normally needs around 18-20GB for weights before context, cache and runtime overhead. A 24GB GPU is therefore the practical floor, not an invitation to load the advertised 256K context. On minimum hardware, start at 16K or 32K context and increase only after checking free memory and prompt-processing latency.

Its main advantage is versatility. It can answer contained coding questions, produce multi-file plans and work through tools exposed by compatible agents. The Apache 2.0 licence is also easier for commercial teams than model licences that limit production use.

Where Qwen3-Coder-30B works best

• Repository exploration through search, grep and file-reading tools.
• Feature work that spans several files but remains reviewable in one session.
• Test generation, debugging and iterative repair with terminal feedback.
• OpenAI-compatible local endpoints used by IDE extensions and coding CLIs.
• Daily local use where a 7B or 14B model is too weak but an 80B model is too large.

The hidden limitation is weight memory. Mixture-of-experts models activate only part of the network per token, but the machine still needs to store the complete quantised model. Do not read “3.3B active” as “runs like a 3B download”.

Qwen3-Coder-Next is the best high-end local coding agent

Qwen3-Coder-Next is built for long-horizon coding agents, tool use and recovery after failed commands. It has 80 billion total parameters, about 3 billion active parameters and a native 256K context window. The model is a better fit for an engineering workstation or shared local server than an ordinary gaming PC.

A four-bit build can occupy roughly 45-50GB once metadata and quantisation overhead are included. That makes 48GB VRAM a tight deployment and 64GB or more the sensible target. A 64GB Apple Silicon machine can load it, but usable speed depends heavily on memory bandwidth and context. Two GPUs can provide enough aggregate VRAM, although split inference adds configuration and communication overhead.

Choose Qwen3-Coder-Next when the agent needs to investigate, edit, execute, observe a failure and recover without constant intervention. Do not choose it simply because it is the newer model. For short edits, autocomplete or occasional questions, the 30B-A3B release gives a better quality-to-hardware ratio.

Devstral Small 2 is the best dense model for a single 24GB GPU

Devstral Small 2 is a 24B dense model tuned for software engineering agents. Mistral positions it for codebase exploration, multi-file editing and tool use, with a 256K model context and an Apache 2.0 licence. It is designed to run on a single RTX 4090-class card or a Mac with 32GB of memory.

Dense architecture makes its behaviour easier to reason about than a sparse mixture-of-experts model, but every token passes through all 24 billion parameters. That usually means lower generation speed and more sustained compute than a 30B model activating only 3B parameters.

Devstral Small 2 is a strong choice when your coding harness already supports Mistral’s expected prompt and tool formats. It is less attractive if your preferred runtime only has partial support for the model architecture or if CPU offload is required. A model that technically loads but generates at a few tokens per second makes agent loops painfully slow.

North Mini Code is the best alternative for portable agent workflows

North Mini Code is a 30B sparse model with about 3B active parameters. It was trained for agentic software engineering and exposed to different coding harnesses rather than one fixed tool format. That focus matters because local agents vary widely: some expose a single terminal tool, while others provide typed edit, search, task and file operations.

The model is particularly interesting for OpenCode-style workflows and teams that want an Apache 2.0 option outside the Qwen and Mistral families. It is not the automatic winner for everyone. Qwen has a larger library of consumer quantisations, tutorials and runtime recipes, which reduces setup friction.

North Mini Code should be evaluated on failed-command recovery and tool-call validity, not only code snippets. A model that writes a correct function but loops after a failed test is a poor coding agent.

Qwen2.5-Coder 14B is still the sensible mid-range choice

Qwen2.5-Coder 14B Instruct is older than the leading 2026 agent models, but it remains useful because it fits hardware many developers already own. A Q4_K_M build is around the point where a 12GB GPU becomes workable, while a 16GB GPU gives more room for context and cache.

It is best for code explanation, contained generation, debugging help and guided edits. It can be connected to an agent, but it should not be given the same autonomy as Qwen3-Coder-Next or Devstral Small 2. Smaller models lose track of long plans sooner, repeat failed approaches more often and are more sensitive to noisy repository context.

This model is also a useful baseline for deciding whether local coding is worthwhile. If a 14B Q4 model feels too slow or too inaccurate on your machine, buying a larger model file will not solve the hardware problem.

StarCoder2 7B is best for low-VRAM fill-in-the-middle completion

StarCoder2 7B is not the best chat assistant or autonomous coding agent in this list. Its value is narrower: fast code completion on limited hardware. It was trained with a fill-in-the-middle objective, which lets an editor provide code before and after the cursor and ask the model to generate the missing section.

That workflow differs from chat. Inline completion needs low latency, compact prompts and predictable continuation. A fast 7B model can feel more useful than a slower 30B model if every suggestion arrives while the developer is still typing.

The compromise is context and reasoning depth. StarCoder2 7B is better treated as a local autocomplete engine than as the model responsible for a repository-wide refactor. Its BigCode OpenRAIL-M licence also deserves review before commercial deployment.

Codestral remains useful for FIM, but its licence changes the decision

Codestral 22B remains a capable fill-in-the-middle model and supports more than 80 programming languages. Technically, it can be a good fit for local IDE completion. Commercially, it is harder to recommend as the default because the freely downloadable weights use the Mistral AI Non-Production Licence.

That licence allows research and testing but requires a separate commercial arrangement for production activity. Individual developers experimenting at home may accept that boundary. Businesses should prefer an Apache 2.0 model unless Codestral’s completion quality justifies the licensing work.

Minimum usable VRAM depends on the coding workflow

Model download size is only the first memory requirement. The runtime also needs memory for the key-value cache, temporary buffers, the prompt and any parallel requests. Coding agents make this worse because they repeatedly append tool outputs, diffs, test logs and file contents to the conversation.

Hardware tier	Models that make sense	Realistic coding use	Avoid
8GB VRAM	3B-7B Q4 models	Autocomplete, short code questions, small functions	Large repository agents and long context
12GB VRAM	7B comfortably, 14B Q4 carefully	Code chat, guided edits, FIM and small-project assistance	24B dense models with heavy CPU offload
16GB VRAM	14B Q4/Q5, some 20B-class quants	Daily code assistance and moderate context	Assuming a 30B model plus long context will fit cleanly
24GB VRAM	Qwen3-Coder 30B-A3B Q4, Devstral Small 2 Q4	Useful local agents, repository search, tests and multi-file edits	Loading maximum advertised context
48-64GB VRAM or unified memory	Qwen3-Coder-Next Q4/Q5 and larger workstation models	Longer agent runs and stronger local code reasoning	Expecting cloud-scale throughput from one workstation

System RAM can substitute for VRAM through CPU inference or partial GPU offload, but speed often falls sharply. A 24B model split between a 12GB GPU and ordinary DDR memory may technically run while feeling worse than a fully GPU-resident 14B model. For coding, responsiveness is part of quality because slow feedback discourages iterative testing.

Quantisation can break code and tool calls before prose looks bad

Quantisation reduces the precision of model weights so they consume less memory. The trade-off is not evenly distributed across every task. A low-bit model may still explain a function convincingly while becoming less reliable at exact syntax, structured tool arguments, long dependency chains or uncommon programming languages.

Format	When to use it	Coding trade-off
Q8	You have abundant memory and want a close-to-full-precision baseline	High memory use with limited practical benefit for many consumer setups
Q6_K	Code quality matters more than fitting the largest possible model	Good quality retention, but often pushes a model into the next hardware tier
Q5_K_M	Quality-focused daily coding	Often the best compromise where memory allows
Q4_K_M	Default consumer deployment	Usually the practical floor for agentic coding without excessive quality loss
Q3 or lower	Experiments where the model otherwise cannot load	Higher risk of brittle syntax, weaker reasoning and malformed tool calls

Do not compare quantisations by chatting with each for five minutes. Run the same repository tasks at Q8 or FP8, Q5 and Q4. Track whether the code compiles, whether tests pass, how many retries are needed, whether tool calls parse and how large the final diff becomes. The cheapest quantisation is the one that reduces total task time, not the one with the smallest download.

Advertised context is not the same as repository understanding

A 256K context window does not mean you should paste an entire repository into every prompt. Large prompts consume memory, slow prompt processing and fill the context with generated files, dependencies and repeated code that may not matter to the task.

Local coding systems generally use one or more of four context methods:

• Explicit file selection: the developer chooses the relevant files. This is simple and often produces the cleanest context.
• Repository maps: the tool supplies symbols, file paths and relationships before opening full files.
• Retrieval: embeddings or lexical search find likely relevant chunks. This scales, but a poor index can omit the file that contains the actual constraint.
• Agent-led exploration: the model uses search, grep, tree and file tools to investigate incrementally.

For most repositories, agent-led exploration plus a compact repository map is better than maximum context stuffing. It preserves room for test output and revision while making the model show which files it believes are relevant.

Fill-in-the-middle support matters more for autocomplete than agents

Fill-in-the-middle, usually shortened to FIM, asks a model to generate code between a prefix and suffix. It is valuable for inline IDE completion because the code after the cursor constrains the answer. A chat-only model may continue the prefix while ignoring the function, closing bracket or type that already exists below.

FIM support should not dominate an agent-model decision. An agent normally reads files, proposes edits and applies patches through tools. For that workflow, instruction-following, search behaviour, tool validity and recovery after failed commands matter more than raw infilling ability.

IDE and CLI compatibility is a model-runtime-harness problem

Most local coding integrations connect to an OpenAI-compatible server exposed by Ollama, llama.cpp, LM Studio, vLLM or another runtime. That shared API shape helps, but it does not guarantee full compatibility. Tool schemas, streaming, stop tokens, reasoning fields and chat templates still vary.

A sensible setup sequence is:

1. Load the model in the recommended runtime and confirm plain chat works.
2. Run a structured-output test and verify that JSON is valid.
3. Enable one harmless tool, such as listing a temporary directory.
4. Confirm the harness recognises the tool call instead of printing it as text.
5. Test file reading, patch application and command execution separately.
6. Add repository indexing only after the basic loop is reliable.

Changing the model, runtime and IDE extension simultaneously makes failures difficult to isolate. Keep two components fixed while testing the third.

How to measure tokens per second on your own hardware

Published speed claims often mix prompt processing with token generation, use short contexts or test a backend that behaves differently from your chosen IDE stack. Use the llama.cpp llama-bench tool to measure prompt processing and generation separately on GGUF models.

For coding, record at least four numbers:

• Cold-load time: how long the model takes to become available after launch.
• Prompt-processing speed: how quickly it ingests repository context and logs.
• Generation speed: output tokens per second after the prompt is processed.
• Time to first token: the delay the developer actually feels.

Run the test at the context length you expect to use. A model that reaches 50 tokens per second on an empty conversation can still feel slow after ingesting 20,000 tokens of code and terminal output.

Privacy gains are real, but local coding still has data exits

Local inference can keep proprietary code away from a model provider, remove API retention questions and support offline or air-gapped development. Those are meaningful advantages for sensitive repositories.

The rest of the coding environment may still transmit data. IDE telemetry, crash reports, extension update checks, package managers, web-search tools, remote MCP servers, cloud embeddings and source-control integrations can all create network activity. A local model is only one layer of the privacy design.

For a genuinely private setup, inspect outbound connections, keep embeddings local, disable unneeded telemetry, exclude secrets and generated credential files, and restrict the agent’s filesystem and shell permissions. Local inference reduces one exposure point; it does not make an unrestricted coding agent safe.

A hosted coding model is often cheaper than buying local hardware

Local inference removes per-token charges, but it does not make compute free. The true monthly cost includes hardware depreciation, electricity, storage, backups, setup time, updates and the extra verification caused by a weaker model.

Consider an illustrative £1,800 workstation used for three years. Hardware depreciation alone is £50 per month. If it draws an average of 350 watts for four hours on 22 working days, it uses about 30.8 kWh. At an assumed £0.25 per kWh, that adds roughly £7.70 per month before maintenance or the value of your time.

A hosted model is usually cheaper when coding use is occasional, frontier quality substantially reduces retries, the task needs very long context, or the team would otherwise buy dedicated hardware. Local is more economical when suitable hardware already exists, usage is heavy and predictable, privacy has real value, or API access is impossible.

Choose local coding	Choose a hosted model
Source code cannot leave controlled hardware	You need the strongest available reasoning for a difficult task
You already own enough VRAM or unified memory	Usage is light or irregular
You need offline or air-gapped operation	You need large context without managing memory
You want stable, pinned model behaviour	A managed agent saves more engineering time than it costs
You can maintain runtimes, models and permissions	Your team does not want inference infrastructure

How to choose the right local coding LLM

Start with the hardware, then choose the workflow. Reversing that order leads to oversized downloads, heavy CPU offload and disappointing speed.

1. Reserve memory for context: do not spend every gigabyte on model weights.
2. Choose chat, FIM or agent use: each workflow rewards different model behaviour.
3. Prefer Q4_K_M as the first test: move to Q5 or Q6 when the model fits comfortably.
4. Verify the licence: open weights do not always permit production use.
5. Use the model’s expected template: tool calling can fail before code quality becomes relevant.
6. Test a real repository: include a bug fix, a multi-file feature, tests and a failed-command recovery.
7. Measure accepted-task cost: count retries, review time and maintenance rather than only tokens per second.

The practical default is straightforward. Use Qwen3-Coder-30B-A3B on a 24GB GPU, Qwen2.5-Coder 14B on a 12-16GB GPU, and StarCoder2 7B where fast FIM completion matters more than agent depth. Move to Qwen3-Coder-Next only when your memory capacity and workload justify it.

Common mistakes with local LLM coding setups

• Choosing by parameter count: active parameters, architecture, training and harness fit matter more than the largest number in the model name.
• Using the maximum context by default: longer context consumes memory and can slow every agent step.
• Dropping below four-bit quantisation too quickly: fitting the model is not useful if tool calls and code syntax become unreliable.
• Confusing local with private: extensions and connected tools may still send code elsewhere.
• Ignoring licences: downloadable weights can carry commercial or production restrictions.
• Testing only fresh code generation: real engineering work includes investigation, edits, tests, failures and rollback.
• Keeping a weak agent running because inference is free: repeated failed loops consume electricity and developer attention.

Best local LLMs for coding FAQs

What is the best local LLM for coding in 2026?

Qwen3-Coder-30B-A3B-Instruct is the best overall local coding LLM for most developers with a 24GB GPU or 32GB unified-memory Mac. Qwen3-Coder-Next is better for high-end local agents when at least 64GB of memory is available.

What is the best coding LLM for 8GB VRAM?

StarCoder2 7B is a practical choice for local autocomplete and fill-in-the-middle completion on 8GB VRAM. A small Qwen coder model may be better for chat, but neither should be expected to run complex repository agents reliably.

Can I run a local coding LLM with 16GB RAM?

Yes. A 7B Q4 model is comfortable, and a 14B Q4 model may fit with limited context, although CPU-only generation can be slow. Keep enough memory free for the operating system, IDE, compiler and tests.

Is Ollama a coding LLM?

No. Ollama is a runtime and model-management layer. It downloads and serves models such as Qwen, Devstral or StarCoder2, but the coding capability comes primarily from the selected model and its integration with the IDE or agent.

Are local coding models as good as Claude or hosted Codex models?

Not consistently. The best local models can handle useful repository work, debugging and test generation, but hosted frontier models usually remain stronger on difficult long-horizon tasks and require less setup. Local models win on control, privacy, offline operation and predictable access rather than absolute capability.

The best local coding model is the one your hardware can run cleanly

A fully GPU-resident 14B model with a correct chat template can be more productive than a larger model split across slow system memory. The same principle applies to agents: reliable tool use, compact context and fast verification are worth more than a benchmark lead that disappears after quantisation.

For most capable consumer workstations, start with Qwen3-Coder-30B-A3B at Q4_K_M and a 16K-32K context. Developers with less memory should use Qwen2.5-Coder 14B or StarCoder2 7B rather than forcing a 30B model to crawl. High-end users can move to Qwen3-Coder-Next, but only after measuring speed, tool reliability and accepted-task cost on their own repositories.