Best Local LLM for Coding, by How Much Memory You Have

The best local LLM for coding supports tool calls (so it can change your files, not just chat) and fits in your memory with room for a 64K context window (how much text it holds at once). As of October 2026, that's Qwen3.8 27B if you have about 22 GB, or Gemma 4 12B if you have less.

With more memory, you can give Qwen3.8 27B a bigger context, or switch to Qwen3.6 35B-A3B for speed. All three run in Ollama or LM Studio, and all three work in Dyad, the free, open-source app builder I make (I'm Will Chen). Below: how to pick one, and how to set it up so it actually edits your files.

Best Ollama model for coding at each memory size

"Memory" here means what the model can use: your graphics card's memory, or on a Mac, the shared memory left after your other apps. Download is the size Ollama lists for each model in the second column.

A few things the table doesn't tell you:

• Under 12 GB, a local model will struggle to build an app. In Sebastian Raschka's tool-calling test, the tiny gemma4:e2b passed 0 of 5 tasks where qwen3.6:35b passed 3, and he found many smaller models "make pretty bad local coding agents." On a less powerful machine, Dyad's FAQ recommends a cloud model. A small local one is still fine for quick fixes.
• Thoughtworks' Birgitta Böckeler picks Qwen3.6 35B-A3B. She runs it on 48 GB and 64 GB Macs. Qwen suggests a context of at least 128K to keep its thinking mode working well. Böckeler found that with reasoning turned off, models did the same or slightly better.
• DeepSeek V4 isn't a local pick. DeepSeek V4.1 Flash 1017 is the top open-weight (downloadable) model on Vals' Vibe Code Bench, at 87.73% on October 19, 2026, but Ollama offers V4.1 Flash only as a cloud model. Its downloadable DeepSeek V4 Flash was retired on September 25, 2026.

What makes a local LLM good for agentic coding

A coding tool doesn't just ask the model for code. It hands the model tools (actions like "write this file" or "search the project") and the model decides which to call. That's what tool calls are.

In Dyad, every chat mode works this way. As of version 1.20.0, Build, Ask, Agent and Plan all run on tool calls. Build mode, for one, edits your project with tools such as write_file, search_replace, read_file and grep. A model that can't make tool calls can't change your files. It can only answer in chat.

Here's what it looks like when a model can't keep up: it replies in the chat, sometimes with code in the wrong format, and your app's preview doesn't change. Dyad's FAQ puts it plainly: when a local model gives bad outputs, "you're likely using a local model which is too small and not smart enough to follow Dyad's instructions." The fix is a bigger model, or a cloud model for that chat.

You can check this before you download anything. Each model's page in the Ollama library lists its capabilities, and you want to see tools there. All three picks above list both tools and thinking.

Some older favorites list tools but not thinking, like qwen3-coder:30b and devstral-small-2:24b. They still work in Dyad, with one setting: Dyad sends an Effort level to Ollama models, medium by default. A model without thinking answers that with a "does not support thinking" error. Set Effort to None and it goes away. As one user put it on GitHub: "none set to effort worked for me."

Ollama context length for coding

The context window is how much text the model can hold at once: your request, the tool's instructions and the files it has read. Local runtimes often start with a small one, and that quietly breaks coding tools.

Here's the math for Dyad. Its Build mode instructions alone are about 16,600 characters, roughly 4,200 tokens (small pieces of text), before the tool definitions and before any of your app's files. Dyad doesn't pick a context size for local models. When a user reported a local model running on the CPU, my answer on GitHub was short: "we don't have any special configuration and use whatever ollama defaults to."

Ollama's docs set its default by graphics memory: 4K tokens under 24 GB, 32K from 24 to 48 GB, and 256K above that. On a 4K default, Dyad's instructions alone don't fit. Ollama itself says coding tools should be set to at least 64,000 tokens.

To set it in Ollama:

• In the Ollama app, open settings and move the context length slider to 64K.
• Or start the server with the setting:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

Then run ollama ps while the model is loaded. The CONTEXT column shows what you actually got, and PROCESSOR shows how much runs on the GPU. Do this on a Mac too: Ollama's docs don't say which default a Mac gets.

In LM Studio, the default can be as small as 4K, according to Alex Ewerlöf's setup notes. Raise the context length in the model's load settings before you load it.

Local LLM for coding hardware requirements

The rule of thumb you'll see everywhere is about 1 GB of memory per billion parameters at 4-bit (a compressed copy of the model). It's off in both directions.

The model file is usually smaller. Qwen3.8 27B at the common Q4_K_M setting is a 17.44 GB file, not 27 GB. But the context window costs memory on top of that. For Qwen3.8 27B it's about 64 KB per token, by ComputingForGeeks' measurement: about 2 GB at 32K, 4 GB at 64K and 8 GB at 128K. So the 18 GB download needs about 22 GB once it has a 64K context.

Fast models can fool you the other way. Sebastian Raschka found Qwen3.6 35B-A3B needs roughly 30 to 40 GB of RAM. The speed comes from the 3 billion parameters at work on each word. The memory bill comes from all 35 billion.

Speed depends on your hardware:

• On an RTX 4090, ComputingForGeeks ran Qwen3.8 27B at 95.5 tokens a second with Ollama's default tag, and 47.7 with its built-in speed-up turned off (September 2026). At 131K context, 30% of the model spilled onto the CPU and speed fell to 16.4.
• Raschka measured Qwen3.6 35B-A3B at about 40 tokens a second on a recent Mac Mini with a 50K context, and about 30 on a DGX Spark. His bar: "anything faster than 20-30 tok/sec is pretty reasonable for local agent work."
• On a Mac, speed follows memory bandwidth. In llama.cpp's community benchmark on a small 7-billion-parameter model, an M5 Max (40-core GPU) wrote about 120 tokens a second, and an M4 Pro (20-core GPU) about 51.

The other wait is before the first word. The model reads the whole prompt first, and a coding tool's prompt is long. I ran into this early on, and wrote on GitHub: "on my macbook air it takes a long time for local llms to start responding because the prompt sent isn't that small, e.g. thousands of tokens."

Which version of the model to download

Most models come in several sizes of the same file, squeezed to different precisions (quantization). Ollama's default tags are 4-bit, called Q4_K_M, and that's the right download for most machines.

The bigger versions cost a lot of memory. An 8-bit copy of Qwen3.8 27B is 29.12 GB, against 17.44 GB at 4-bit. On a 32 GB or 48 GB machine, spend spare memory on context first: taking Qwen3.8 27B from 64K to 128K costs about 4 GB, while the 8-bit copy costs about 12 GB more. Only move up to 8-bit once the context is where you want it.

Is there a free LLM for coding?

Yes. All three picks are open-weight models under the Apache 2.0 license, so you can download them, run them and use what you build with them, commercially too. Ollama is free and open source. LM Studio is free for personal use. Add Dyad, and a local setup costs nothing beyond your computer and its electricity.

Is a local LLM good enough for coding?

For fixing and changing code, close. For building a whole app from one prompt, not yet.

• Fixing real GitHub issues: Qwen3.8 27B scored 86.00% on Vals' SWE-bench Verified, against 97.00% for the top model, Claude Opus 5. That board was last updated September 1, 2026, and Vals no longer adds models to it: scores have saturated.
• Building a web app from scratch: Qwen3.8 27B scored 64.85% on Vals' Vibe Code Bench on October 19, 2026, against 92.39% for the top model, Claude Sonnet 5.5.

Vals' default setup for Qwen3.8 27B is Alibaba's hosted service with reasoning set to extra high, not a 4-bit copy on your machine. The gap is 11 points on fixes and 28 points on whole builds. So split the work. Start a new app with a strong cloud model, using your own API key or your ChatGPT subscription. Then use the local model for the follow-up changes, where the gap is smaller. In Dyad you pick the model per chat, so you switch in the model picker.

How to run a local LLM for coding in Dyad

1. Install Ollama or LM Studio.
2. Pull a model from the table, for example ollama pull qwen3.8:27b.
3. Set the context length to 64K, as above, and check it with ollama ps.
4. Open Dyad and click the model picker. Your models show up under Local models.
5. If you picked a model without thinking, set Effort to None.

With a local model, your prompts and code stay on your computer, and in Build mode Dyad doesn't count your messages (on the free plan). The local models guide covers LM Studio and custom Ollama hosts, and our Ollama walkthrough goes step by step.

Which model are you running, and on how much memory? If you find one that beats Qwen3.8 27B in Dyad, I'd love to hear about it.