How to Use Aider From the Terminal With a Local Model

April 29, 2026 · Editorial Team · 6 min read · aider local-model ollama

Aider is a terminal-based coding agent that has a strong following among developers who prefer command-line tools and want full control over their AI setup. The ability to pair it with a local model via Ollama is one of its more compelling features: no API costs, no data leaving your machine, and it still handles git commits, multi-file edits, and conversation-based coding sessions.

Getting this combination working takes about 20 minutes. Here's a precise walkthrough.

Install Aider and Ollama

Aider is a Python package. Install it with pip:

pip install aider-chat

If you're on macOS and prefer to keep things isolated, use pipx:

pipx install aider-chat

Verify the install:

aider --version

For Ollama, download the installer from ollama.com (macOS app or Linux binary). On macOS, it runs as a menu bar app. On Linux:

curl -fsSL https://ollama.com/install.sh | sh

Once Ollama is installed and running, pull a model that works well for coding. As of early 2026, good choices are:

ollama pull codestral:22b
ollama pull deepseek-coder-v2:16b
ollama pull llama3.1:70b

The 70b models are better but require 40+ GB of RAM or a capable GPU. For most machines, a 16b or 22b model is the practical choice. codestral:22b has shown good results for multi-file code tasks specifically.

Connect Aider to your Ollama model

Aider can connect to Ollama via OpenAI-compatible API calls. Ollama exposes a local API server at http://localhost:11434.

The command to start Aider with an Ollama model:

aider --model ollama/codestral:22b

The ollama/ prefix tells Aider to use Ollama's API endpoint rather than OpenAI or Anthropic. Make sure Ollama is running before you start Aider (on macOS, the menu bar icon should show green; on Linux, check with systemctl status ollama).

If you want to set this as your default model so you don't have to specify it every time, add it to ~/.aider.conf.yml:

model: ollama/codestral:22b

You can also set per-project configs by placing .aider.conf.yml in the project root. This is useful if you use a lighter model for quick tasks and a heavier one for refactors.

Starting a session: /add files and the chat interface

Navigate to your project directory and run:

aider

Aider starts in the project root and has awareness of your git repository. It doesn't load all files into context by default; you explicitly add the ones you want it to work with using the /add command:

/add src/utils/pricing.ts src/utils/pricing.test.ts

You can add multiple files at once. Aider loads them into the conversation context. The files you add are the ones Aider can read and edit in the current session.

To see what's currently in context:

/files

To remove a file from context (to free up context window for local models, which are context-limited):

/drop src/utils/pricing.test.ts

Context management matters more with local models than with API models. A 22b model running on consumer hardware typically has a 4k-8k effective context window before quality degrades. Keep the active file list focused: 3-5 files is a good target.

How git auto-commits work

This is Aider's most useful feature and the one that catches people off guard the first time: every time Aider makes a code change, it automatically commits it to your git repo with a descriptive message.

After asking Aider to refactor a function, you'll see something like:

Applying changes to src/utils/pricing.ts...
Commit a3f2b1c feat: extract applyDiscount into separate function

This means you have a clean audit trail of every AI-suggested change. If a change made things worse, git revert a3f2b1c and you're back. You can also view the full diff of what the model changed:

git show a3f2b1c

If you want to review before committing (to batch changes manually), start Aider with:

aider --no-auto-commits

In practice, auto-commits are more useful. The fine-grained commit history makes it easy to see exactly what each prompt produced.

Architect mode for multi-file changes

Aider's architect mode is designed for changes that span multiple files. Normal mode is good for focused edits to 1-2 files. Architect mode uses a two-step approach: a "thinking" pass to plan the changes, then an "editing" pass to apply them.

Enable architect mode:

aider --architect

Or in an existing session:

/architect

In architect mode, when you make a request, Aider first describes the planned changes across all relevant files, then asks for confirmation before applying. This is the right mode for:

Extracting a module and updating all imports.
Renaming an interface and all its usages.
Adding a new dependency and updating all call sites.

For a local model, architect mode is also slightly cheaper on context: the planning pass is smaller, and the editing pass is more focused. This can improve output quality on a constrained model.

A practical architect mode session:

/add src/services/auth.ts src/hooks/useAuth.ts src/pages/login.tsx src/pages/signup.tsx
Refactor the auth service to use async/await throughout. Currently it mixes callbacks and promises.

Aider will describe the plan, you confirm, and it applies the changes. Each changed file gets its own commit.

Model quality: what to expect from local models

Local models are genuinely good at focused, well-scoped tasks. Where they fall short compared to frontier API models:

Complex reasoning. A 22b local model will sometimes produce a structurally correct refactor that misses a subtle semantic issue. A 70b model handles this better but at higher hardware cost.

Long file context. If you add a 500-line file to context, a local 16b model may produce lower quality suggestions for code near the end of the file. Keep files under 200-300 lines if you can, or break the task into smaller pieces.

Type-aware edits. Local models sometimes break TypeScript types in ways that only show up when you run tsc. Always run type checking after an Aider session: npx tsc --noEmit.

That said, for the 80% of tasks that are straightforward: adding a function, writing tests, updating error handling, fixing a bug in a well-understood file, a local 22b model is fast and free. The latency for a response is 5-15 seconds on modern hardware, which is slower than API calls but fast enough to be productive.

Practical tips for a working setup

A few things that improve the local model experience:

Use .aiderignore to exclude large directories. Create a .aiderignore file in your project root (same syntax as .gitignore) to tell Aider not to read node_modules, dist, .next, etc. Without this, Aider might accidentally pick up build artifacts.

Set a reasonable context limit. For local models, add --max-chat-history-tokens 4000 to your Aider config. This prevents context from growing until it degrades the model's output.

Watch the token display. Aider shows the current context token count at each prompt. If it climbs above your model's comfortable limit, use /drop to remove files you're done with.

For code review tasks, use the /read command to add a file as read-only context (Aider will reference it but not modify it): /read src/types/index.ts. This is useful for type definition files that provide context but shouldn't be edited in the current session.

Running Aider with a local model is genuinely viable for daily coding work. The setup takes 20 minutes and the ongoing cost is electricity. For teams working with proprietary codebases where sending code to external APIs is a compliance concern, it's often the only option worth considering.