Best Ollama Model for Coding: Picks by VRAM and Agent Tool

I gave four local model setups the same five Python coding tasks on an 8 GB M1 MacBook Air, and qwen3.5:4b with thinking turned off passed 4 of 5, twice as many as any other setup, while qwen3.5:9b was too slow on that machine to test at all. That run covers only the smallest tier. Above it, the best Ollama model for coding on a 24GB GPU or a 32GB+ Mac, as of September 2026, is qwen3.8:27b (18GB): it supports the tool calling coding agents need, has a 256K maximum context, and higher vendor-reported coding scores than Qwen3.6 27B. For agent work on a 16GB card, pick gpt-oss:20b (14GB); on an 8GB GPU, qwen3.5:9b (6.6GB); on an 8 GB Mac, qwen3.5:4b with thinking off. Whichever you pull, raise Ollama's context window to at least 64k before pointing Claude Code, Continue, Cline, or Aider at it, because Ollama's context docs set the default under 24GB of VRAM to only 4k tokens.

That context rule matters more than most model rankings admit. A 27B model starved at 4k tokens will lose your files mid-task, while a smaller model with 64k of room can finish the job. The matrix below maps each memory tier to a tag, its size on disk, its maximum context, and whether its tool calls are known to work in coding agents. The same tiers answer the broader best local LLM for coding question, because LM Studio and llama.cpp run GGUF builds of these same models; only the setup commands change.

Best Ollama model for coding by VRAM: the decision matrix

Size on disk is the weight file Ollama downloads, so treat it as the floor of what the model needs in memory. The KV cache for your context window sits on top of it, which is why a 23GB model is a tight fit on a 24GB card. Sizes and context values come from each model's tags page in the Ollama library, as of September 27, 2026.

The two "fast" rows are mixture-of-experts models, which run fastest for their quality because only a few billion parameters are active per token: qwen3-coder:30b activates 3.3B of 30B, and qwen3.6:35b-a3b-coding about 3B. At the small end, qwen2.5-coder:1.5b (986MB) is the fastest practical choice for tab autocomplete. On any machine, keeping the whole model on the GPU matters more for speed than parameter count.

I would leave a few GB of headroom above the file size for a 64k context; the exact figure depends on each model's layer and attention-head counts. The KV cache size guide shows the per-model math, and the LLM VRAM calculator runs it for any tag.

Most tags in the matrix are Q4_K_M builds (the gpt-oss rows ship as MXFP4). If a tier leaves spare memory, the Q4_K_M vs Q5_K_M comparison covers whether a larger quant is worth it over more context.

What happened when I ran five coding tasks on an 8 GB Mac

The matrix comes from tag pages and model cards, so I checked its smallest tier against real code. I wrote five Python tasks, each with a test file, before any model ran: parse a log line, fix an off-by-one bug, parse a duration string with edge cases, refactor an invoice function without changing its behavior (compared with the original on 400 randomized inputs), and merge intervals. Each setup got each prompt once through Ollama 0.35.1 on a MacBook Air M1 with 8 GB of unified memory, and the code it returned either passed the tests or did not.

Read this as a smoke test, not a ranking. Every pass count rests on one attempt per task at temperature 0 and seed 42, so a single different task could reorder the three 2-of-5 rows. What it does show is which setups break on ordinary edge cases at this memory size.

I changed one test after the first runs, and both counts are in the table. The refactor test originally demanded exact float equality with the original function, and reordered arithmetic such as total *= 0.9 produced 1-cent rounding differences. The default test now accepts a difference under 0.011; the strict column keeps exact equality, which drops qwen3.5:4b from 4 to 3 passes and qwen2.5-coder:7b from 2 to 1.

Thinking cost more than it bought at 4B. With thinking on, qwen3.5:4b generated 15,883 tokens across the five tasks and spent 1180.6 s of wall time, against 1,177 tokens and 79.9 s with thinking off. The three tasks it failed with thinking on all ran out of token budget before any code appeared.

Speed on 8 GB depends on what else is in memory, and a browser, an editor, and a Claude Code session were open throughout. My first qwen3.5:4b session ran at a median 3.48 tok/s; a second session produced identical tokens and identical pass/fail results at 18.35 tok/s, which is the figure in the table. qwen2.5-coder:7b sat at 5.2 GB in ollama ps with a 12%/88% CPU/GPU split even at the 4096-token default context. qwen3.5:9b loaded but generated at 0.079 and 0.086 tok/s on two 10-token requests, with a 58%/42% CPU/GPU split and heavy swap, so I did not run the suite on it.

That changes my 8 GB Mac pick to qwen3.5:4b with thinking off instead of qwen3.5:9b, because the 9B model was too slow to use there and the 4B passed the most tasks. I have not tested a dedicated 8GB GPU, where the 9B weights do not share memory with macOS, so the 8GB VRAM rows in the matrix stay as they are.

Why context length decides more than the model

Ollama sizes the default context from your VRAM: 4k tokens below 24 GiB, 32k from 24 to 48 GiB, and 256k at 48 GiB or more. The same documentation says tasks such as agents and coding tools "should be set to at least 64000 tokens".

That gap is where most "this model is bad at coding" complaints start. A coding agent sends a system prompt, tool schemas, and file contents before it writes a line. On an 8GB or 16GB card, all of that has to fit in 4k tokens unless you change the setting, and the oldest turns get dropped.

The fix is one environment variable on the server:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve
ollama ps

Check the CONTEXT and PROCESSOR columns in ollama ps. You want your chosen context and 100% GPU; a CPU split means the model plus cache no longer fit, and speed drops sharply.

The editors disagree slightly on the floor. Ollama's Cline guide asks for at least 32K, its Claude Code guide asks for 64k or more, and Aider's Ollama page has Aider size the window per request on its own. That Aider page still says Ollama defaults to 2k, which predates the VRAM-based defaults; trust the Ollama figure. Open reports also show Claude Code (Ollama issue 15316) and the Cline CLI (Cline issue 13989) failing to auto-compact when the local window fills, so long sessions may still need a manual /compact or a restart.

Does a 64k context fit on 8GB or 16GB?

Not always, and the model's config file tells you why. Qwen3.5 9B has 32 layers, but only every fourth one uses full attention; the other 24 keep a fixed-size linear-attention state. The 8 full-attention layers each cache keys and values for 4 KV heads of 256 dimensions, which at 16-bit precision is 8 x 2 x 4 x 256 x 2 bytes, or 32 KiB per token (Qwen3.5-9B config).

The gpt-oss row uses the same method: 12 of its 24 layers use full attention with 8 KV heads of 64 dimensions, and the other 12 use a 128-token sliding window (gpt-oss-20b config).

By that math, qwen3.5:9b at 64k does not fit an 8GB card, so I would use 32k there, or set OLLAMA_KV_CACHE_TYPE=q8_0 to roughly halve the cache. Ollama only quantizes the K/V cache when Flash Attention is active. gpt-oss:20b at 64k leaves well under 1GB of headroom on a 16GB card before runtime overhead, so drop to 32k if ollama ps shows any CPU split.

If you run Ollama in a container, the Ollama Docker GPU setup covers passing the variable through. Since most picks above are Qwen builds, the Ollama Qwen guide covers every Qwen family on Ollama, including vision and thinking controls.

Which Ollama models handle tool calls for agentic coding

A tools badge on ollama.com means the model template declares tool support. It does not guarantee your editor receives a structured tool call. In an open Cline report from September 23, 2026, qwen2.5-coder:14b on Ollama 0.34.2 listed tools under capabilities, yet the raw /api/chat response put the tool call in message.content with no tool_calls field.

The same pattern appears across trackers:

• Continue: an open issue from July 29, 2026 reports Qwen3-Coder 30B on Ollama returning tool calls as plain text instead of executing them (Continue issue 13057).
• Ollama: a report on Qwen 3.5 27B tool calling, open since February 27, 2026, was still being confirmed on August 31, 2026 (Ollama issue 14493).
• Claude Code: a user running gemma4 on two 12GB RTX 3060 cards got looping "Invalid tool parameters" errors (Ollama issue 15390).

This is why the matrix separates "Yes" from "Tagged, parsing bugs reported". Qwen2.5-Coder is still a solid choice for chat, single-file edits, and Aider, which connects through its ollama_chat/ provider. I expect Aider to be less exposed to this bug, because it asks for edits in its own text formats rather than relying on native tool calls. For agent loops, prefer the newer tags that Ollama and the model vendors describe as agent-trained: Qwen3.8, Qwen3.6 coding, gpt-oss, and Qwen3-Coder-Next, whose card says it "works with coding agents like Claude Code, Qwen Code, Cline, and OpenCode out of the box".

Qwen3.8 reached Ollama a day before the September 27 library check, so its tool calling has no public track record yet, and it inherits the Qwen3.5 architecture whose Ollama parser issue is still open. If it misbehaves in your agent, qwen3.6:27b-coding (18GB) is the same-size fallback.

Before blaming the model, run ollama show <model> and confirm tools appears under Capabilities, then watch your editor's log for a real tool call rather than JSON printed into the chat.

What the published coding benchmarks say

Vendor model cards publish coding scores, but each vendor runs its own harness, so compare rows within one table rather than across tables. The numbers below are copied from the primary cards.

The Qwen3.8 27B card places it ahead of its predecessor on every coding row it reports. Qwen3.6's own card, hosted on the Qwen3.6-27B page, lists 77.2 on SWE-bench Verified against 52.0 for Gemma 4 31B under Qwen's harness. The Laguna and Gemma rows come from their Ollama model cards.

Treat these as a shortlist filter, not a ranking. An independent 16GB test on the Hugging Face forum found that repeat runs flipped single-shot rankings among six Ollama models, and the most-cited score belonged to a sampling path that was not the common one. Your own repository is the benchmark that counts.

Apple Silicon and unified memory

On a Mac, the model shares one memory pool with macOS and your editor, so a 32GB Mac behaves more like a 24GB GPU than a 32GB one. Vendor cards on Ollama give the clearest guidance: Devstral says it fits "a Mac with 32GB RAM", Laguna XS 2.1 targets "a Mac with 36 GB of RAM", and the Qwen3-Coder 480B card asks for at least 250GB of memory or unified memory.

Two notes follow from the tag data. Qwen3.8 ships a qwen3.8:27b-mlx tag at 18GB for Apple's MLX runtime, and Laguna XS 2.1's card currently warns of an issue on macOS that its team is investigating.

By tier, my read is that a 16GB Mac should run qwen3.5:9b or qwen2.5-coder:7b, since macOS shares that memory; a 32GB to 36GB Mac can run qwen3.8:27b or qwen3.6:35b-a3b-coding with a 64k window; 64GB and up opens qwen3-coder-next. On an 8GB Mac, my coding run above points to qwen3.5:4b with thinking off; read the 8GB RAM test before pulling anything larger than 4B.

How to connect Claude Code, OpenCode, VS Code, Continue, Cline, and Aider

Each tool talks to Ollama at http://localhost:11434, but each expects a slightly different setup. The table gives the shortest working path and the model fit for each.

Claude Code reaches Ollama through its Anthropic-compatible API, and Ollama's guide adds that basic chat and file edits work with compatible models while hosted web search is not fully supported. Continue's Ollama guide warns that some models still show "Agent mode is not supported" even with tool_use set, which usually means the model lacks working tool calls. Aider recommends the ollama_chat/ prefix over ollama/. The Ollama OpenCode guide states that OpenCode requires a context length of 64k or higher, and the Ollama VS Code guide warns that the editor may display a model's maximum context even when Ollama allocated a smaller one at runtime.

Choosing a runtime is a separate question: see LM Studio vs Ollama, Ollama vs llama.cpp, or the broader Ollama alternatives guide. To pull, pin, and inspect these tags, or to set OLLAMA_CONTEXT_LENGTH on each OS, see the Ollama commands reference.

Older coding models you can skip

Two names still top old "best Ollama coding model" lists but fall behind on the two things agents need. codestral (22B, 13GB) has a 32K context, no tools badge, and was last updated two years ago. deepseek-coder-v2 (16B lite, 8.9GB) also carries no tools badge, and most of its quantized tags list only a 4K context.

Both remain fine for fill-in-the-middle completion or plain chat. For anything that edits files through an agent, the Qwen3.5 through Qwen3.8 generation, gpt-oss, and Gemma 4 give you tool support plus 128K to 256K of maximum context at similar or smaller sizes.

How I tested this

• Machine: a MacBook Air with an Apple M1 and 8 GB of unified memory, with a browser, an editor, and a Claude Code session open during every run.
• Versions and dates: Ollama 0.35.1 from the official ollama-darwin.tgz, at its default 4k context, and Python 3.13.5 for the tests. The runs took place on October 3 and 4, 2026.
• Models: qwen3.5:4b with thinking off (two sessions) and with thinking on, qwen3.5:2b with thinking off, and qwen2.5-coder:7b. qwen3.5:9b got only two short speed probes.
• Suite: five Python tasks, each a prompt plus a test file written before any model ran: log-line parsing, an off-by-one fix, duration parsing with edge cases, an invoice refactor compared with the original on 400 randomized inputs, and interval merging.
• Protocol: a small script sent each prompt to Ollama's /api/chat with a fixed system prompt asking for one Python code block, at temperature 0 and seed 42, once per task per setup. It saved the first Python block from each answer and ran the task's tests on it. A second script re-tested every saved answer under both the default and the strict refactor test.
• Not tested: tool calling, agent loops, and the editor integrations described above (Claude Code, OpenCode, VS Code, Continue, Cline, Aider); contexts above the 4k default; dedicated GPUs; qwen2.5-coder:1.5b for autocomplete; every model above the 8GB tier; and repeat attempts per task beyond the one qwen3.5:4b repeat session.
• Raw record: every pass, failure, token count, and speed is in the results.json run record, next to the tasks and the scripts.

Related coverage

• LLM VRAM Calculator: RAM, Quantization, and Model Fit
• KV Cache Size: How Much VRAM It Uses and How to Cut It
• Can You Run a Local LLM on 8GB RAM? M1 Mac Test
• Ollama vs llama.cpp: Which Is Faster for Local LLMs?

References

• Aider docs - https://aider.chat/docs/llms/ollama.html
• Cline issue 14453 - https://github.com/cline/cline/issues/14453
• Continue docs - https://docs.continue.dev/guides/ollama-guide
• Ollama docs - https://docs.ollama.com/context-length
• Ollama library - https://ollama.com/library
• Qwen model cards - https://huggingface.co/Qwen/Qwen3.8-27B