Choose an Open-Weight Cline Model by the Work, Not the Parameter Count

For most Cline users running locally, start with qwen3-coder:30b if you have 32–64GB of RAM or unified memory available and want one general-purpose default. If you’re constrained to a 16GB-class GPU or you mostly ask for contained edits, try gpt-oss:20b first; it’s a smaller 14GB Ollama download, supports tools, and is the less painful way to find out whether local inference is fast enough for your day.

Don’t choose from a parameter-count chart, and don’t treat the model download size as a hardware requirement. Cline needs room for the runtime, your editor, the model’s context cache, and whatever else is using the GPU or unified memory. A model that loads at 14GB may technically fit and still become unbearable after Cline has read a pile of files.

Pick a model for the job Cline is about to do

The practical split is between a model that can work through a multi-step agent loop and a model that can cheaply help with the next small thing. Cline is not a completion box: it reads files, proposes or executes terminal commands, edits, checks results, then keeps going. Weak tool use is more damaging here than merely getting a slightly worse explanation. It causes retries, malformed tool calls, and a task that looks busy while making no useful progress.

• Use qwen3-coder:30b as the default for repository exploration, changes that cross several files, test-fix loops, and tasks where Cline must keep a plan in its head. Ollama’s Q4 build is a 19GB download with a 256K advertised context window; the underlying Qwen model is explicitly packaged for agentic coding and Cline-compatible function calling.
• Use gpt-oss:20b for review comments, test additions, localized refactors, shell-heavy debugging, and private codebases where you want a model on a 16GB-capable setup. Its Ollama package is 14GB with 128K context. It supports tools and configurable reasoning effort, but don’t mistake accessible reasoning traces for proof that the edits are correct.
• Use devstral:24b when tool-driven code navigation is the point of the task and you have roughly the same local budget as gpt-oss. The Q4 Ollama package is also 14GB and has 128K context. It is coding-agent-focused, but it is text-only, so it is not the pick when screenshots, design images, or browser visual inspection are part of the task.
• Consider larger local models only when the machine is effectively a shared inference box. qwen3-coder-next is a 52GB Q4 download, and devstral-2 is 75GB. Those sizes can make sense on a dedicated host; on a developer laptop they often trade a better answer for an agent loop slow enough that you stop delegating work.

Make hardware the first filter

If you have 16GB of VRAM, or a machine with modest unified memory, begin with gpt-oss:20b or devstral:24b, not a 30B model you hope will squeeze in. OpenAI’s gpt-oss packaging is specifically designed to run the 20B model on systems with as little as 16GB of memory, but that is a floor for loading the model, not a promise of a pleasant 128K-token agent session.

With 24GB VRAM or 32–64GB unified memory, Qwen3-Coder 30B is the sensible next experiment. Pull it with ollama pull qwen3-coder:30b, then use Cline’s Ollama provider at http://localhost:11434. In Cline, turn on Use Compact Prompt before judging the result. Cline recommends that setting for local inference because it reduces the recurring prompt burden; it is usually a more meaningful speed improvement than shaving a little off the model’s stated context window.

ollama pull qwen3-coder:30b
ollama run qwen3-coder:30b

With 64GB or more, resist setting the maximum context just because the model advertises 128K, 198K, or 256K. Long context consumes memory and makes prompt evaluation slower. Start Cline at 16K or 32K context for normal feature work. Raise it only after you have a task that genuinely needs the repository history in one conversation—say, tracing an authorization flow across services—and after you verify the machine still has headroom.

Budget means more than zero API spend

A local model removes per-token provider billing, which is useful when Cline iterates through tests or reads sensitive code. It does not make the run free. You are paying in hardware, power, fan noise, setup time, and the opportunity cost of waiting 45 seconds for an agent to decide to open the next file.

That’s why a two-model setup is usually more honest than declaring one winner. Keep gpt-oss:20b or Devstral as the cheap, always-on model for bounded tasks. Keep Qwen3-Coder 30B for changes where a failed first pass would cost more than an extra minute of inference. If neither model can sustain the task—large migration, unfamiliar monorepo, repeated tool-call failures—send only that task to a cloud model rather than buying a bigger model download out of frustration.

Run a 20-minute acceptance test before standardizing

Use your code, not a public benchmark. Give each candidate the same three tasks: add a test for a real bug, make a small change across two or three files, and investigate a failing command without being told which file is wrong. Use a new Cline task for each run. Record wall-clock time, whether it selected sensible files, how many tool calls it wasted, and whether its diff passed your existing checks.

Also inspect the failure mode. A model that says it needs more information and asks to read one file can still be useful. A model that repeatedly re-reads the same directory, writes a plausible patch without running the relevant test, or emits broken tool syntax is not saved by having a larger advertised context window. Demote it to chat or autocomplete work rather than trusting it with Cline’s edit loop.

One final setting matters more than it should: keep the task narrow. Local agents improve noticeably when you ask for “update this parser, add the two regression cases, run pnpm test parser” instead of “clean up the parsing subsystem.” Cline’s own local-model guidance says to keep tasks focused and start a new task as context grows. Do that first; model shopping comes second.