· 7 min read
How to Use Open-Source Models With Cline
By W. Marchetti
- guides
Yes: Cline can use open-weight models locally through Ollama or LM Studio, or remotely through providers such as OpenRouter and other OpenAI-compatible APIs. The most practical first setup is Cline plus Ollama: it keeps prompts and code on your machine, costs nothing per request, and gives you a real coding-agent workflow rather than a chat box.
One terminology note before you start: a model with downloadable weights is not automatically “open source.” Its license may restrict commercial use, redistribution, or training. For day-to-day Cline setup, what matters is that the model can run through your chosen runtime; for company use, read the particular model’s license before treating it as an approved dependency.
Pick the right route before you install anything
Local inference is the right default when privacy, offline access, or predictable cost matter most. Cline sends its working context, requests to inspect files, and tool results to the selected model. When Ollama is local, that traffic stays between Cline and a service on your machine. That does not make the model magically safe to give production credentials, but it removes a third-party inference API from the path.
Hosted open-weight models are the better choice when you have a thin laptop, need fast responses, or want to try several models without downloading tens of gigabytes. In that setup, the weights may be open, but your prompts still leave your machine for the inference provider. Don’t confuse “open model” with “local model.”
For a first local agent, use a coding model with demonstrated tool-use behavior rather than grabbing the smallest general chat model you can fit in RAM. Cline’s current local-model guide recommends Qwen3 Coder 30B as its baseline sub-70B choice. That is a useful starting point, not a law: the model that is responsive enough on your hardware and reliably follows edits and command results will beat a theoretically stronger model that takes two minutes per turn.
Set up Cline with Ollama
Install the Cline extension in your editor, then install Ollama and make sure its local server is running. Ollama normally exposes its API at localhost on port 11434. Pull a model from your terminal; if your Ollama catalog offers Qwen3 Coder under a more specific tag, use that tag instead.
ollama pull qwen3-coder
ollama run qwen3-coder "Reply with exactly: local model ready"
ollama psThat second command does more than test that the download finished. It proves the runtime can load the model and generate a response. The final command tells you whether the model is using GPU, CPU, or both. If it is mostly on CPU when you expected GPU acceleration, solve that before judging Cline. An agent that can make a good plan but emits a token every second will feel broken.
- Open the Cline panel and click the settings gear.
- Set API Provider to “Ollama.” Local providers do not need an API key.
- Confirm the base URL is your Ollama server, typically
http://localhost:11434. If Ollama runs in Docker, on another machine, or in a VM, use the reachable host address instead. - Choose the model name you pulled. If it does not appear, restart the local server, refresh Cline, and check
ollama lsin a terminal. - Enable Cline’s compact prompt option. Local agents benefit disproportionately because the agent’s tool instructions and repository context can otherwise consume a large portion of the context window.
- Start in Plan mode for the first task. Ask Cline to inspect the repository and name the files it would change, then switch to acting only after the plan makes sense.
Give the agent enough context without exhausting your machine
Context window is the setting most likely to turn a promising local setup into a disappointing one. Cline needs room for your request, code excerpts, tool definitions, terminal output, its own running summary, and the next response. Ollama’s documentation specifically calls out agents and coding tools as workloads that should use at least 64,000 tokens. Larger contexts also consume substantially more memory, so don’t blindly set a huge number on a machine that can barely fit the model.
A good first target is 64K context if your available memory supports it. Create a small Ollama Modelfile so the setting follows the model instead of relying on a one-off command-line session:
FROM qwen3-coder
PARAMETER num_ctx 65536
PARAMETER temperature 0.2Save that as Modelfile, then create a named variant and select it in Cline:
ollama create cline-coder -f Modelfile
ollama run cline-coderUse a low temperature for coding-agent work. You are usually asking the model to preserve constraints, interpret compiler errors, and make a minimal correct patch—not brainstorm five novel architectures. If responses start becoming incomplete or the machine begins swapping memory, lower the context size first. If the model repeatedly misunderstands command output or loses track of the task, try a higher-quality quantization or a larger model before endlessly rewriting your prompts.
Work with a local agent differently than a frontier API
Cline’s value is not that it produces a code block. It can inspect files, propose diffs, execute commands, and iterate on errors. That means your job is to give it an observable, bounded task. “Fix authentication” is vague. “Trace why POST /sessions returns 401 in the staging configuration, add a regression test, and do not change the token format” gives the model a path and constraints.
Keep approval turned on for destructive operations, especially while learning a model’s habits. Review shell commands that modify files outside the repository, package-manager commands, migrations, generated lockfile churn, and anything involving credentials. An open-weight model running locally reduces data exposure; it does not make an incorrect rm, a bad migration, or an invented configuration value harmless.
Use a small, repeatable evaluation task before trusting a model on a large refactor. Pick a bug with an existing test, ask Cline to explain the failure, make the minimal fix, and run the targeted test. If it passes, inspect the diff yourself. Repeat this with a task involving search across several files and one involving a failing command. You are measuring tool use, restraint, and recovery—not just whether the final prose sounds confident.
Use a hosted open-weight model when local isn’t worth the wait
Cline also supports OpenRouter and a general OpenAI-compatible provider mode. The setup pattern is the same: choose the provider in Cline settings, add its API key, and select a model. This is useful for comparing an inexpensive hosted open-weight coding model with your local baseline, or for running a long repository task that needs more context or throughput than your computer can provide.
Treat that as an explicit operational choice. Confirm the provider’s data-retention terms, set a spending limit where available, and use a project-specific API key rather than a personal master key. Then keep the same workflow: plan first, constrain the change, run tests, and review the diff. Switching models changes latency, cost, privacy, and raw capability. It does not remove the need for engineering judgment.