Cline With a Local Model: Ollama and LM Studio Setup, Context and Permissions

Cline is an open-source coding agent that reads your project, edits files and runs terminal commands from a chat panel. It ships as a VS Code and JetBrains extension, a desktop app and a command-line tool, and all of them can run on a model served by Ollama or LM Studio on your own machine instead of a paid API.

This guide covers the provider settings for both runtimes, the context window Cline asks for and why it differs from Ollama’s own advice, the memory each model needs at that context, and what Cline does without asking. BFWR has not run Cline. The steps and defaults below come from Cline’s documentation and source code, Ollama’s and LM Studio’s documentation, and the memory figures are computed with our own VRAM calculator’s data.

Quick answer

• Ollama: in Cline’s settings choose the Ollama provider, keep the base URL http://localhost:11434 and pick a model. For the CLI, ollama launch cline does the setup.
• LM Studio: start its server, choose the LM Studio provider and keep http://localhost:1234.
• Context: Cline requests 32,768 tokens from Ollama unless you change it, so Ollama’s 4K default does not apply. Cline Desktop gives most of its recommended models 64K. Set the Model Context Window field to 65536 if the model fits.
• Model: Cline’s own pick is Qwen3.8 27B. At 64K we compute 22.5 GB, so a 24GB card just holds it; gpt-oss-20b (17.1 GB) suits 16 to 24GB machines.
• Permissions: in the VS Code extension, file reads, file edits, web fetches and MCP tools are auto-approved by default; only terminal commands ask. The CLI auto-approves every tool unless you pass --auto-approve false.
• Telemetry is on by default in every Cline product.

What Cline is in late 2026

The project is cline/cline on GitHub, Apache-2.0, with about 71,000 stars. It is busy: 904 commits on the main branch in the 90 days to 1 November and a push on 31 October. The VS Code extension (saoudrizwan.claude-dev) is at version 4.1.26, released on 26 October 2026, with about 5.8 million installs on the Marketplace. The same day brought CLI 3.0.74 and Cline Desktop 0.0.49.

Version 4 moved the extension onto the same SDK as the CLI, and some settings older guides describe have gone. Two are still in Cline’s own local-model docs, covered below.

The licence is the standard Apache License 2.0 text, copyright Cline Bot Inc., so commercial use and modification are allowed under its usual notice and attribution terms. That is our reading of the published file, not legal advice.

Setting it up with Ollama

VS Code or JetBrains extension

ollama pull qwen3.8:27b

Cline’s local-models page gives the steps: open Cline Settings, select provider Ollama, set the base URL to http://localhost:11434 and pick your model from the dropdown. The provider form has three fields worth knowing: the optional custom base URL, the model picker, and Model Context Window, whose placeholder reads “Default: 32768”. An API key field appears only for a custom base URL, for Ollama’s cloud or an authenticated server.

The form also warns: “Cline uses complex prompts, so behavior can vary across models. Less capable models may not work as expected.”

Cline Desktop

Cline Desktop (macOS, with Windows in beta) has a Local Models page under Settings → Provider → Local. It detects Ollama or LM Studio, can start either, recommends models that fit the machine, downloads them and, when you click Use with Cline, will “Save the model’s recommended context window to that provider’s settings.” It is the only route that sets the context for you.

Cline CLI

npm install -g cline
ollama launch cline --model qwen3.5

Ollama’s documentation says that ollama launch cline sets Cline’s provider to Ollama, points it at the local endpoint and selects your model, and offers to install the CLI if npm is present. The manual route is cline auth, choosing Ollama and http://localhost:11434. Install from npm and check the version: in February 2026 a compromised publish token was used to push cline@2.3.0 with an extra install script, according to Cline’s own advisory.

Setting it up with LM Studio

Download a model in LM Studio’s Discover tab, start the server from the Developer tab (default http://localhost:1234), then select provider LM Studio in Cline and pick the model. If you turned on LM Studio’s server authentication, add the token in Cline’s LM Studio settings. Keep LM Studio’s Serve on Local Network switch off unless you mean to share the server.

Cline does not set the context with LM Studio. It reads the context length of the loaded model, so set it when you load. LM Studio’s CLI takes a flag for this:

lms load qwen/qwen3.8-27b --context-length 65536

Cline Desktop’s docs warn that when LM Studio loads a model on its own “it uses the context length set for that model in LM Studio instead of the one Cline recommends”, so load it yourself first.

The context window: 32K by default, 64K recommended

Ollama defaults to 4,096 tokens on GPUs with less than 24 GiB of memory, the usual reason agents fail on local models (our OpenCode guide spends a section on it). Cline avoids that trap. The current release talks to Ollama’s native API, not the OpenAI-compatible one, and sends a context size (num_ctx) with every request. The value comes from the Model Context Window field, and when that is empty Cline requests 32,768 tokens. A comment in Cline’s SDK explains the choice: it is “deliberately larger than Ollama’s 4096 server default, which cannot fit Cline’s agentic prompts.” Ollama’s FAQ treats OLLAMA_CONTEXT_LENGTH as the server default and num_ctx as the per-request setting, so with Cline it is Cline’s field that decides.

The sources then disagree on how much is enough:

• Ollama’s Cline page says “Use a context window of at least 32K tokens for coding.”
• Ollama’s context-length page says “Tasks which require large context like web search, agents, and coding tools should be set to at least 64000 tokens.”
• Cline Desktop assigns 64K to five of its seven recommended models and 32K to the other two (Devstral Small 2 and Qwen3 8B).

32K works, but a long task fills it quickly and Cline starts compacting the conversation. If your model fits at 64K, type 65536 into Model Context Window.

How much memory each model needs

Computed with our VRAM calculator‘s formula and data: Q4_K_M weights, a 16-bit cache, plus 1.8 GB of runtime overhead. The last column is Cline Desktop’s own estimate where it lists the same model.

Where the two overlap, our figures land within about 1.3 GB of Cline’s, which is a useful cross-check from two independent methods. Cline’s docs describe theirs plainly: “Memory needed is an estimate of the model plus its context window.”

The step from 32K to 64K costs Qwen3.8 27B 2 GB and Qwen3-Coder 30B-A3B 3 GB, but Qwen3.6 35B-A3B and the Gemma 4 models under 1 GB, because most of their layers keep a short or compressed cache. Our guide to context windows and VRAM explains why. Ollama’s q8_0 cache halves the cache part: Qwen3-Coder 30B-A3B drops to 23.1 GB at 64K.

Which local models can drive it

Cline works through tool calls, and its Ollama route sends tool definitions and results over Ollama’s native chat API. Pick a model Ollama marks with the tools capability. Every model in Cline Desktop’s list below carries it on Ollama’s library pages as of 1 November.

Cline Desktop’s recommendations, with the Ollama tags its docs give:

Cline describes Qwen3.8 27B as “The best all-round local model for agentic coding”. Our guide to local coding models compares the wider field by memory and licence.

Two settings in Cline’s docs that no longer exist

Cline’s local-models page still tells you to “Enable Use Compact Prompt in Cline Settings” under Features. That option was added in version 3.26.3 for windows of 8K or less, but the 4.x settings schema marks the field as removed, with the note “compact prompt setting no longer supported”. You will not find the checkbox, and you do not need it with a 32K or 64K window.

The auto-approve page still describes a YOLO Mode checkbox under Features. Version 4.1.8 removed it from the extension. Its changelog explains that the toggle “was cosmetic: nothing in the approval path read it”, and anyone who had it on was migrated to auto-approving every action. The CLI still has a --yolo flag.

What Cline does without asking

The extension’s approval menu has five toggles. Their defaults in the 4.1.26 source:

That is looser than Cline’s own advice. The same docs page recommends enabling only reads and says “Leave edits, commands, browser, and MCP off until you have a specific reason”. The 4.0.0 changelog says command auto-approval “is now disabled by default for safer new and reset configurations”, and that part holds; edits, web fetches and MCP did not get the same treatment.

A local model is more likely than a frontier model to misread an instruction or follow one planted in a fetched page, so we would turn off Edit files, Fetch web content and Use MCP servers until you trust the setup. Two things soften the risk:

• Checkpoints are on by default. The docs say “Every time Cline modifies a file or runs a command, it saves a snapshot of your project files”, in a shadow Git repository separate from yours.
• Plan mode is read-only: Cline “can read your codebase, run searches, and discuss strategy, but cannot modify any files or execute commands.”

The CLI goes further. Its help text says --auto-approve means “Set tool auto-approval for all tools (default: true)”, and the source sets every tool to auto-approve unless a flag or saved setting says otherwise. Run cline --auto-approve false when you want to review actions, and use a clean branch or --worktree otherwise. Cline’s advisory list also has two 2026 entries for local servers started by the CLI side, its Kanban board (critical, May) and the Hub dashboard (high, June), both allowing any web page you visit to reach a 127.0.0.1 WebSocket. Keep the CLI updated. Our guide to securing a local LLM covers why an agent that reads the web needs these limits.

Telemetry and what stays local

With Ollama or LM Studio, prompts stay on your machine, but usage reporting is separate. Cline’s telemetry page says: “Telemetry is on by default in the VS Code and JetBrains extensions, Cline Desktop and the CLI, whether you sign in to a Cline account or use your own API keys.” It records features, errors, token counts and model names with a device identifier, and “Cline’s telemetry doesn’t include your code, file contents or prompts, except for requests to the Cline and ClinePass providers.”

To turn it off in the extension, clear Allow error and usage reporting under Settings → General. In the CLI, set "telemetryOptOut": true in ~/.cline/data/settings/global-settings.json. Even then, “Cline still contacts its servers for other purposes: to sign you in, to check feature flags, and to run requests on the Cline and ClinePass providers.”

FAQ

Does Cline work with Ollama’s default 4K context?

It does not use it. Cline sends its own context size, 32,768 tokens unless you change the Model Context Window field, so Ollama’s 4K default for smaller GPUs does not apply.

What is the best local model for Cline?

Cline recommends Qwen3.8 27B, which we compute needs 22.5 GB at 64K context. On 16 to 24 GB, gpt-oss-20b or Gemma 4 26B-A4B fit with room for the context.

Can Cline run commands without asking?

In the extension, commands ask by default, but file edits do not. The CLI auto-approves everything unless you pass --auto-approve false.

Related guides and tools

• OpenCode with a local LLM
• Claude Code with a local model
• Local AI pair programming: which tools are still maintained
• Best local LLMs for coding
• Ollama models and VRAM
• LM Studio models

Sources

• cline/cline on GitHub (README, LICENSE, CHANGELOG, auto-approval defaults, Ollama context default) and its security advisories
• Cline docs: local models, Local Models in Cline Desktop, auto approve, checkpoints, Plan and Act, CLI reference and telemetry
• Ollama: Cline, Cline CLI and context length
• LM Studio: lms load
• Cline on the VS Code Marketplace

Updated 1 November 2026. Versions, defaults, docs and advisories were read on that date; memory figures are computed from the BFWR VRAM calculator’s data.