The obvious way to pick a coding model is to read a leaderboard and take the higher number. By that test the choice looks easy: on pure coding ability, models like DeepSeek and the Qwen coder line sit at the top, and that is not really in dispute.
But the leaderboard is measuring the wrong thing for this job. A benchmark tests a model answering a coding question in isolation. An agent like OpenCode asks a different question: can the model read files, plan a change, edit, run a command, read the result, and stay coherent across all of that without going off the rails? Those are not the same skill, and the gap between them is the whole article. If you are choosing one model for a whole team’s coding agent, this is the question to settle first. We run our coding model fully local in OpenCode, and what we have learned is that the model that wins the leaderboard is often not the model that wins the day.
What is the difference between a coding benchmark and an agent loop?
A benchmark asks: write the function. An agent asks: read this codebase, find where the function should go, write it, add a test, run the test, and fix it if it fails. The second is a loop, and the loop punishes different weaknesses than a one-shot prompt does.
A strong pure coder like DeepSeek or a Qwen coder model tends to produce better code on a self-contained problem. A model tuned for agentic and instruction-following behaviour tends to do something less glamorous but more useful inside an agent: it stays in the tool-use loop, follows the format, and does what you asked rather than what it would rather do. For a chat window you want the first kind of model. For an agent, the second earns its place more often than the leaderboard predicts.
Why does agent behaviour beat raw coding here?
The failure mode that actually wastes your time in an agent is not “the function was slightly worse.” It is the model that ignores the tool format, hallucinates a file that does not exist, edits the wrong block, or narrates a plan instead of executing it. A model can be a better coder in the abstract and still be a worse agent because it does not respect the agent around it.
A concrete version: ask an agent to add a test to one file. The leaderboard champion writes a beautiful test, then helpfully refactors three unrelated files you did not ask it to touch, breaks the build, and explains why its version is better. The duller, instruction-following model writes a slightly plainer test in the one file you named and stops. The second model just saved you twenty minutes, and it will keep saving them every day.
This is the whole reason we choose our daily coding model on loop behaviour, not chart position. When we say “only touch this file,” we want a model that only touches that file. We want it to read, edit, run, and report in the loop OpenCode expects, rather than breaking format and forcing us to babysit. That reliability inside the loop is worth more on a normal workday than a few points of standalone coding skill we would only feel on the hardest single problems.
How much does RAM decide the choice?
The leaderboard never asks what fits on your machine, and that question quietly decides a lot. Every one of these models comes in different sizes, and the size you can actually load depends on your RAM. A model that does not fit is a model that does not run, and a model that barely fits will swap, crawl, and bump everything else out of memory. An agent loaded alongside your editor, your browser, and the project itself eats into that fast.
So the real comparison is not “model A versus model B” in the abstract. It is “the largest A we can comfortably run versus the largest B we can comfortably run, with headroom left for OpenCode and the rest of our desktop.” On a tighter machine, the model that fits with room to spare beats the model that technically loads and then makes the whole laptop stutter. Right-size to your RAM before you argue about quality.
Which coding models fit each Mac memory tier?
Unified memory is the binding constraint on a Mac. Our guide to what each tier of hardware can run covers the general case; for coding, the shortlist by tier looks like this.
On an 8 GB Mac, such as a MacBook Air, Phi-4 Mini at Q4 is the only practical coding model. It is good for autocomplete and simple function generation, and not suitable for debugging or refactoring.
On a 16 GB Mac, Qwen 3.5-9B at Q4 is the best option, and it can handle most single-file edits and code explanations. For lighter work, Gemma 4 E4B handles quick questions and single-file tasks. Neither will handle complex refactors.
On a 24 GB Mac, Qwen 3.6-27B at Q4 lands at roughly 16.8 GB of memory, leaving room for KV cache and system overhead and for 32K or more of context. The 35B-A3B mixture-of-experts model fits at Q4 with similar headroom and runs faster.
On a 32 to 48 GB Mac, either Qwen variant runs with generous context budgets. The 35B-A3B can stretch to 64K to 128K of context for repo-level analysis, and Gemma 4 26B-A4B becomes a viable second model for agent tasks and function calling.
On a 64 GB or larger Mac, Qwen3-Coder-Next becomes practical at approximately 46 GB at Q4. It is built for agentic coding workflows such as multi-file refactors, autonomous debugging and tool use. Qwen 3.6-35B-A3B can run alongside it at Q6 or Q8 for general reasoning.
The mixture-of-experts models are why the middle tiers work. Qwen 3.6-35B-A3B and Gemma 4 26B-A4B activate only 3 to 4 billion parameters per token despite having 26 to 35 billion in total, which keeps generation fast on Apple silicon. The Qwen 3.6 family arrived with the 35B-A3B model on 16 April and the 27B dense model on 22 April, both under the Apache 2.0 licence.
How should a team choose a local model for OpenCode before rolling it out?
A team choosing one model for everyone’s agent has a different problem from one developer trying models on a Saturday. The model you pick sets the RAM every laptop needs, and the RAM sets the hardware budget. So the trial comes before the purchase order.
What do the vendor SWE-bench scores say?
Start with the vendor numbers, then set them aside. SWE-bench Verified tests whether a model can fix real GitHub issues in real repositories. Alibaba’s Qwen3.6-27B model card reports these scores. They are Alibaba’s figures, not our measurements:
| Model | Architecture | SWE-bench Verified (Alibaba’s figures) |
|---|---|---|
| Claude 4.5 Opus | Closed model | 80.9% |
| Qwen3.6-27B | 27B dense | 77.2% |
| Qwen3.5-397B-A17B | 397B MoE (17B active) | 76.2% |
| Qwen3.5-27B | 27B dense | 75.0% |
| Qwen3.6-35B-A3B | 35B MoE (3B active) | 73.4% |
| Gemma 4 31B | 31B dense | 52.0% |
On Alibaba’s figures, Qwen 3.6-27B sits within 4 percentage points of Claude 4.5 Opus and ahead of the 397B Qwen 3.5 model. Use the table to shortlist two models that fit the machines your team actually has. Do not use it to pick the winner, for the reason this article gives: a benchmark scores one answer, and an agent lives or dies in the loop.
What have we measured ourselves?
We have not yet measured a fix rate for any of these models on real repository tasks, so we do not rank them on coding quality. What we have measured on our test machine, an M4 Pro with 48 GB of unified memory, is speed, and speed sets how long a developer waits.
In our LM Studio parallel request test on 12 October 2026, Qwen3.6 35B-A3B wrote 49.4 tokens a second on LM Studio’s llama.cpp engine and 61.5 on its MLX engine. Gemma 4 31B wrote 11.7 and 12.6. For a 500-token reply, that is about 8 seconds on Qwen3.6 35B-A3B under MLX and about 40 seconds on Gemma 4 31B (500 divided by each rate). Two developers sharing the MLX Qwen build each got about 65 tokens a second, so a shared machine did not slow either of them. We have not measured Qwen 3.6-27B.
The engine matters as well as the model. When Ollama moved its Apple silicon backend from llama.cpp to MLX, its own testing of Qwen3.5-35B-A3B showed decode speed rising from 58 to 112 tokens a second. That is Ollama’s figure, not ours. Ollama is the easier start, since it handles model management and chat templates; llama.cpp supports GGUF builds of every model and runs on Linux and Windows as well as macOS.
How do you run the trial?
Run the trial this article describes, on your own code: one multi-step task from your real backlog, run in OpenCode with each model in turn, with a tally per run of format breaks, edits to the wrong file, invented files, and the corrections a person had to make. Have the developer who knows that code mark the result, and run ollama ps during each run to see how much memory the model holds while the editor and the project are open.
We have not run that trial ourselves on our test machine with two local models on the same task in a real repository, so we publish no tallies and no decision rule from it. Nor have we measured whether any model’s fixes are right. Ten closed issues with tests from a real repository, run through each model one at a time on our test machine, with fix rate and minutes per fix recorded, is the test that would settle it, and both runs are on our list. OpenCode does let a team route hard jobs to a cloud provider and routine ones to the local model per task, so a mixed arrangement is available if neither model passes.
Which local model should you run in OpenCode?
Reach for a strong pure coder (DeepSeek, a Qwen coder model) if your work is coding-heavy in the pure sense: hard, self-contained problems where raw code quality on each step matters more than smooth loop behaviour, and you have the RAM to run a capable size.
Reach for an agent-tuned model if you are doing agentic work in OpenCode all day: reading real codebases, making multi-step changes, running tests, and you value a model that stays in the loop, follows instructions, and does not need supervision to respect the agent around it.
Here that second role is currently filled by glm-4.7-flash, run locally through Ollama. We did not pick it off the top of a coding chart; we picked the model that behaves best inside the agent we actually use, follows instructions, and fits our machines with room left for the editor and the project. The privacy story stays intact because nothing leaves the building, the bill stays zero, and on the rare task that genuinely needs more raw coding muscle, OpenCode lets us point at something stronger for that one job and switch straight back. The reasoning behind keeping the everyday model local is its own argument.
Do not copy our pick blindly. Models change every few months, so test two on your own machine with your own tasks before you decide, and watch how each behaves across a real multi-step change, not just how it answers a single question. The number on a leaderboard is one data point. How the model acts inside the loop is the job.
If you do run your own test, keep it boring and repeatable: the same multi-step task, the same repo, each model in turn, and count the times it broke format, edited the wrong file, or needed a correction. That tally tells you more than any single answer’s quality, and it is the number nobody publishes.
