Skip to main content

Guides

The Complete Guide to Local AI Coding: Setting Up Cline, Continue.dev, and Aider with Local Models

By 15 min read

Running the model on your own computer can avoid per-token API charges and support offline coding after the software and models are downloaded. Your code stays on the machine only when the assistant uses local model endpoints and its telemetry, tools, and integrations do not send it elsewhere. However, getting reliable results from local coding models requires matching the right tool to the right task, configuring memory and context windows correctly, and understanding security boundaries when agents execute commands on your workstation.

A functional local coding environment relies on three distinct interaction primitives:

  1. In-editor autocomplete and conversational assistance for low-latency line completions and code queries.
  2. Autonomous agent loops that inspect files, write multi-file edits, and run terminal commands to resolve complex tasks.
  3. Terminal-first git workflows that create structured repository maps and generate automated commits for every applied change.

Here is how each workflow primitive works, how to configure Continue.dev, Cline, and Aider with Ollama and LM Studio, and how to avoid common pitfalls with context window exhaustion and VRAM sizing.


1. The Three Local Coding Workflow Primitives

Local coding tools are not interchangeable. Attempting to use an autonomous agent for tab-completion or a lightweight autocomplete model for multi-file architectural refactoring will lead to frustrating results.

Workflow PrimitiveRepresentative ToolTypical Interaction StyleRecommended Model TierPrimary Resource Bottleneck
Autocomplete & ChatContinue.devInline suggestions; sidebar explanations and editsSmall completion model for autocomplete; supported instruction model for chatWhether suggestions arrive at a pace that helps you type
Autonomous Agent LoopsCline / Roo CodeInspects files, requests commands, and applies editsExact model supported by the tool’s current provider and calling formatFull memory requirement, valid tool calls, and task correctness
Git-Native Terminal CLIAiderInteractive terminal session; builds AST repository map; edits files and auto-commits14B–32B parameters with diff or whole-file editing supportContext window size and structured diff formatting stability

In-Editor Autocomplete and Sidebar Chat (Continue.dev)

Tab autocomplete requires immediate responsiveness. When you pause typing, your editor must return a continuation within a fraction of a second. If generation takes two or three seconds, the completion interrupts your train of thought rather than speeding it up.

For this reason, tab autocomplete uses specialized small base models such as Qwen 2.5-Coder 1.5B or StarCoder2 3B. These models specialize in Fill-in-the-Middle (FIM) operations, taking the prefix and suffix around your cursor and predicting the code in between. Because these models are small, they fit into a few gigabytes of VRAM or execute swiftly on CPU, returning completions with minimal latency.

The sidebar chat panel serves a different purpose. It handles conversational tasks: explaining an obscure error message, generating unit tests for an active function, or refactoring a highlighted block. Here, latency can be higher (several seconds), allowing you to run larger 7B, 14B, or 32B instruct models that possess deeper architectural reasoning.

Autonomous Agent Loops with Multi-File Edits (Cline and Roo Code)

Autonomous agent extensions like Cline and Roo Code transform the model from a passive responder into an active operator. Instead of answering a single prompt, the agent executes an iterative feedback loop:

  1. Task Planning: The agent analyzes the user's objective and requests repository information.
  2. Environment Inspection: The agent lists files, searches directory structures, and reads relevant code files using tool calls.
  3. Execution & Editing: The agent proposes discrete file modifications or creates new files using unified diffs or file replacement tools.
  4. Validation: The agent executes terminal commands (such as running test suites, linters, or compilers) to observe the outcome.
  5. Correction: If the compiler or test runner emits an error, the agent ingests the error trace and attempts another correction cycle.

This workflow requires the exact model and template to follow the agent’s calling and edit formats across turns. Parameter count does not establish that capability. Begin with a disposable project and a small change with a known check. Qwen2.5-Coder is a coding-focused family to investigate, but a successful chat response does not establish reliable agent behavior. Use the tool’s current supported-model guidance rather than treating 14B or 32B as a universal threshold.

Git-Native Terminal CLI (Aider)

Aider approaches coding assistance from the terminal command line, tightly coupling model completions to git source control.

Rather than sending entire codebases to the language model—which quickly exhausts available context windows—Aider constructs a repository map using Tree-sitter abstract syntax tree (AST) parsing. This map extracts symbol definitions, class structures, and function signatures across your entire repository, giving the model an accurate structural overview using only a modest token budget.

Aider then applies requested changes using specialized edit formats (such as unified diffs or targeted block replacements) and automatically commits the resulting changes to git with a descriptive commit message. If an applied edit breaks tests or fails syntax validation, you can immediately roll back using standard git operations.


2. Preparing Local Inference: Ollama and LM Studio

Before configuring your editor extensions or CLI tools, you must have an inference backend running locally and serving models over HTTP.

Setting Up Ollama

Ollama serves models on http://localhost:11434 with both a native /api endpoint and an OpenAI-compatible /v1 endpoint.

Pick the relevant download below rather than downloading all three. Confirm the exact file and intended context in the memory calculator first:

# Fast model for tab autocomplete
ollama pull qwen2.5-coder:1.5b-base

# Balanced model for in-editor chat and light refactoring
ollama pull qwen2.5-coder:7b-instruct

# Larger coding candidate, only if the complete workload fits
ollama pull qwen2.5-coder:32b-instruct

Configuring the Context Window in Ollama

Ollama’s default context depends on available graphics memory: 4K below 24 GiB, 32K from 24 to under 48 GiB, and 256K at 48 GiB or more, subject to the model and runtime. Check the actual allocation with ollama ps; model settings and explicit overrides can change it. Coding tasks need room for instructions, source files, tool results, and the response, so choose context deliberately rather than assuming a fixed default.

To run agentic coding tasks effectively, create a custom model variant with an expanded context window (such as 32,768 tokens):

  1. Create a plain text file named Modelfile:
FROM qwen2.5-coder:32b-instruct
PARAMETER num_ctx 32768
PARAMETER temperature 0.2
  1. Build your customized model inside Ollama:
ollama create qwen2.5-coder-32k -f Modelfile

Confirm that the model appears in your local catalog:

ollama list

Setting Up LM Studio

LM Studio provides a desktop graphical interface and a local inference server running on http://localhost:1234/v1.

  1. Open LM Studio and search for qwen2.5-coder-32b-instruct or qwen2.5-coder-7b-instruct in GGUF format (Q4_K_M is the standard quantization balance).
  2. Navigate to the Developer / Local Server tab.
  3. In the right-hand configuration panel:
    • Set Context Length to 16384 or 32768.
    • Set GPU Acceleration to Max to offload all model layers to VRAM if memory permits.
    • Set Temperature to 0.2 for code generation.
  4. Click Start Server. Confirm that the server is listening on http://localhost:1234.

3. Step-by-Step Setup Guides

1. Continue.dev Setup (VS Code and JetBrains)

Continue.dev integrates directly into your editor sidebar while providing background tab autocomplete.

  1. Install the Continue extension from the VS Code Marketplace or JetBrains Plugin Repository.
  2. Open Continue’s local configuration editor and edit ~/.continue/config.yaml (on Windows, under your user folder).
  3. Use the current YAML configuration format below. Select the Ollama model for chat and edits; the small base model handles autocomplete. The optional LM Studio entry must use the exact loaded model identifier from its server.
name: Local coding
version: 1.0.0
schema: v1
models:
  - name: Ollama coder
    provider: ollama
    model: qwen2.5-coder-32k
    apiBase: http://localhost:11434
    roles: [chat, edit, apply]
    defaultCompletionOptions:
      contextLength: 32768
      temperature: 0.2
  - name: Ollama autocomplete
    provider: ollama
    model: qwen2.5-coder:1.5b-base
    apiBase: http://localhost:11434
    roles: [autocomplete]

For LM Studio, add a model entry with provider: openai, apiBase: http://localhost:1234/v1, apiKey: lm-studio, and the exact model identifier shown by the local server. Match defaultCompletionOptions.contextLength to the server’s loaded context. If server authentication is enabled, use its actual token.

Save the configuration and select it in Continue. Test a short chat and one autocomplete suggestion before adding project-wide context. Configure telemetry separately in the extension settings; selecting a local model alone does not turn off network features.


2. Cline / Roo Code Setup (VS Code)

Cline and its community fork Roo Code run autonomous multi-file tasks directly in VS Code.

  1. Install Cline from the VS Code Marketplace.
  2. Open the Cline panel on the left sidebar and click the Settings (gear) icon.
  3. Configure the provider connection:

Option A: Connecting Cline to Ollama

  • API Provider: Select Ollama.
  • Base URL: Enter http://localhost:11434.
  • Model ID: Enter qwen2.5-coder-32k (the custom model created earlier) or qwen2.5-coder:32b-instruct.
  • Context Window: Enter 32768.

Option B: Connecting Cline to LM Studio

  • API Provider: Select OpenAI Compatible.
  • Base URL: Enter http://localhost:1234/v1.
  • API Key: For a server without authentication, use the client’s required placeholder. If LM Studio authentication is enabled, use that server’s actual token.
  • Model ID: Enter the exact model name shown loaded in LM Studio.
  • Context Window: Enter 32768 (matching LM Studio's server setting).
  1. Review Permissions and Auto-Approve Settings:
    • Under the Auto-Approve section, ensure that Execute Terminal Commands and Delete Files remain unchecked.
    • Keep manual approval active for all shell actions so the agent cannot execute destructive scripts without your explicit consent.

3. Aider Setup (Terminal CLI)

Aider runs directly in your terminal and interacts with your git repository.

  1. Install Aider using pipx or standard Python pip:
# Recommended: isolated installation via pipx
pipx install aider-chat

# Or standard pip
pip install -U aider-chat
  1. Open a terminal in the root directory of your project (which must be a git repository).

Connecting Aider to Ollama

Point Aider to your local Ollama instance:

export OLLAMA_API_BASE=http://localhost:11434
aider --model ollama_chat/qwen2.5-coder:32b-instruct --edit-format diff

Note on edit formats: Aider supports multiple edit formats (diff, whole, udiff). While cloud frontier models handle concise unified diffs well, local models are sometimes more reliable with the standard diff format or whole-file rewrites on smaller files.

Connecting Aider to LM Studio

To connect Aider to LM Studio's OpenAI-compatible server:

aider \
  --openai-api-base http://localhost:1234/v1 \
  --openai-api-key not-needed \
  --model openai/LOADED_MODEL_ID \
  --edit-format diff

Replace LOADED_MODEL_ID with the exact model identifier shown by LM Studio's local server. The multiline commands use Bash continuation; in PowerShell, enter each command on one line or use PowerShell's continuation syntax. not-needed is a placeholder for a server without authentication; use the configured key if authentication is enabled.

Running in Architect Mode

For complex tasks, Aider offers an architect mode that decouples system design from diff generation:

aider \
  --model ollama_chat/qwen2.5-coder:32b-instruct \
  --editor-model ollama_chat/qwen2.5-coder:7b-instruct \
  --architect

In this mode, the 32B model produces the implementation plan, while the smaller 7B model translates that plan into concrete code edits.


4. Critical Parameters: Context Windows, VRAM, and Tool Calling

Configuring local coding agents involves managing hardware constraints that standard chat interfaces rarely encounter.

Context Window Sizing (16k to 32k Tokens)

In a typical coding task, the model must simultaneously hold:

  • System prompt instructions and tool definitions (~1,500–2,500 tokens).
  • Repository directory tree and file map (~1,000–3,000 tokens).
  • Active source code files being inspected (~2,000–10,000 tokens).
  • Conversation history and previous terminal command outputs (~2,000–8,000 tokens).

If your configured context is smaller than the instructions, files, tool results, and generated response, the conversation can overflow. When an overflow occurs, the engine drops older messages, causing the agent to lose track of requirements, repeat commands it already executed, or emit broken patches.

For a multi-file workflow, calculate space for the actual instructions, files, tool results, conversation, and answer. A 16K or 32K target can be useful, but is not a universal minimum or a promise of full-repository understanding. Match the client and server settings and check memory before raising either. Preserve the files and requirements the task needs rather than silently dropping them to make a smaller context pass.

VRAM Sizing and Hardware Guidelines

Memory consumption during agentic coding comes from two distinct sources:

  1. Model Weights: The static memory required to store the model parameters.
  2. KV Cache: The dynamic memory required to store key-value attention representations for every token in the active context window.

As context grows, conversation memory can become a substantial additional cost. Its size depends on the exact architecture, context, cache precision, and runtime. Do not reserve an arbitrary 3GB-5GB for every 32B model or assume that about 19GB of weights leaves enough room for 32K context on a 24GB GPU.

Total Memory = Model Weights + KV Cache + Runtime Overhead
Hardware ProfilePractical Model ClassUsable Context WindowSuitability for Coding Tasks
8GB dedicated VRAM plus adequate RAMSmall completion model or selected 7B four-bit chat modelBegin with modest context and calculate larger requestsCompare autocomplete latency and a single-file edit; agent capability needs its own check
12GB–16GB dedicated VRAMSelected 7B–14B four-bit modelCalculate the exact requested contextMore weight headroom, but no guarantee of valid diffs or reliable tools
24GB dedicated VRAMSelected larger coding model after a smaller one works32K can exceed capacity with a 32B modelCalculate weights, cache, and overhead; partial offload may be necessary
Apple Silicon 36GB–64GB+ unified memorySelected larger compressed modelLeave room for macOS and the intended conversationCheck memory amount, engine, context, and speed together

The Impact of CPU Offloading

If a model and its conversation memory exceed available VRAM, the selected runtime may use partial CPU offload if enough RAM is available, or the load can fail. Do not assume offload always makes the requested context usable.

Partial offload can slow generation, but the size of the change depends on the hardware, model, and split. Multiple sequential agent turns can compound that delay. Compare the complete task on your intended setup; no fixed percentage slowdown or completion time applies to every model. A smaller model with correct edits and usable speed can be the better choice.

Tool-Calling and Function-Calling Requirements

Autonomous agents rely heavily on function calling. The model does not merely generate text; it outputs structured commands matching schemas like:

{
  "name": "read_file",
  "arguments": {
    "path": "src/lib/parser.ts"
  }
}

If a model hallucinates brackets, truncates arguments, or embeds conversational text inside JSON attributes, the agent parser will reject the call, forcing another retry.

Check tool requests and edit syntax directly; a parameter threshold does not establish reliability. These are candidates to compare if their files fit:

  • qwen2.5-coder:32b-instruct is a larger coding instruction model; validate the tool’s particular edit and calling format.
  • DeepSeek-R1-Distill-Qwen-32B adds a reasoning workflow, but reasoning output can complicate a client expecting only an edit. Select a supported exact package and template.
  • qwen2.5-coder:14b-instruct is a smaller candidate when the larger model and context do not fit.

5. Privacy, Sandboxing, and Security Boundaries

Selecting a local inference endpoint controls one part of the workflow. The editor, agent tools, dependency installers, web search, and connected services can still make network requests.

Keep Inference and Tools Local

A local setup is only as private as its network configuration:

  1. Verify Interface Bindings: Ensure Ollama and LM Studio bind exclusively to the loopback interface (127.0.0.1 or localhost). If an inference engine binds to 0.0.0.0, any device on your local network (or public internet if port forwarding is configured) could query your model or send inputs to your API.
  2. Check Telemetry Settings: In Continue, turn off Allow Anonymous Telemetry in the editor’s user settings, as its offline guide specifies. This is separate from selecting a local model in config.yaml. Check the editor’s own telemetry and each assistant’s network features as well.
  3. Avoid Cloud Fallbacks: Ensure that your extension configurations do not specify cloud fallback providers that activate when your local server is offline.

Shell Execution and Auto-Approve Permissions

Agents like Cline include tools to run bash or PowerShell commands to run tests and inspect directories. While powerful, allowing an agent to execute shell commands without human confirmation poses significant operational risks:

  • An agent attempting to clean up a failed test may issue commands like rm -rf or git checkout -- ., unintentionally discarding uncommitted work.
  • If a project script triggers unexpected network activity or installs dependencies, unsupervised execution can modify your local environment unexpectedly.

Operational Best Practice: Keep terminal command approvals set to manual. Take two seconds to inspect each command string before clicking Approve.

If you require headless or automated execution, run the coding agent inside a containerized sandbox:

  • Use a disposable container or virtual machine with only the intended workspace mounted. Dev Containers can still expose host folders, credentials, ports, or a Docker socket depending on configuration; inspect those grants before treating the environment as isolated.
  • Ensure sensitive environment variables (such as production API keys or SSH credentials) are excluded from the development container environment.

Mitigating Indirect Prompt Injection in Repositories

Repository files and tool results can enter the model’s context as source material. They are not authorized instructions merely because the model can read them. On an untrusted or newly cloned repository, malicious instructions can be hidden inside:

  • Obscure code comments or test fixture files.
  • Markdown documentation or issue summaries.
  • Compromised third-party packages in node_modules or vendor folders.

These instructions can attempt an indirect prompt injection, instructing the agent to execute unauthorized terminal commands (such as exfiltrating data via curl or altering configuration files).

Defense Strategy:

  • Never run autonomous agents with automated approvals enabled on codebases you have not initially inspected.
  • Do not store sensitive environment credentials (.env files containing production secrets) within the working directory where the agent has read access.
  • Add .env and sensitive credential paths to your extension's ignore list (.continueignore or .clineignore). An ignore file filters the extension's workflow; it does not remove the underlying process's file or shell permissions.


Sources