Aider is a terminal-based AI pair programmer that edits files in your actual git repo, and unlike a cloud chatbot, you can point it at a model running entirely on your own machine. That means no API key, no per-token bill, and no copy of your proprietary codebase sitting on someone else’s servers. This guide walks through getting an aider local model working end to end via Ollama: installing both tools, the exact environment variable and model name Aider expects, the one context-window setting that quietly breaks everything if you skip it, and an honest read on which local coding models are actually good enough, and where a local setup still loses to a frontier cloud model. The good news is the wiring is genuinely simple. The catch is in the details.
Why run Aider locally at all
Aider’s whole appeal is that it works on your real files. You run it inside a git repository, it reads the files you add to the chat, proposes edits as diffs, and commits them with sensible messages. That’s powerful, and it’s exactly why you might not want to hand the whole flow to a cloud provider.
When Aider talks to a cloud model, every file you add to the chat, every diff, and every instruction gets shipped to that provider’s API. For a hobby project that’s a shrug. For a private codebase, a client’s repo, or anything under an NDA, it’s a real exposure. Running the model locally collapses that risk to zero: the prompt never leaves 127.0.0.1. The trade-offs, covered honestly below, are speed and raw capability, not privacy. If you want the full cost-and-control argument, we lay it out in local AI vs cloud AI.
The other reason is simply cost. A capable cloud coding model can burn through real money on a long refactor session. A local model costs electricity. Once the hardware is paid for, ai pair programming offline is free per token, forever.
Step 1: Get Ollama running
Aider doesn’t run models itself, it talks to a model server. The simplest local server is Ollama, which exposes an OpenAI-compatible API on 127.0.0.1:11434 and handles model downloads, quantization, and GPU offload for you. If you haven’t installed it yet, follow our how to install Ollama walkthrough first; it’s a single installer on macOS, Linux, and Windows.
Once Ollama is installed, pull a coding model. Start with something your hardware can comfortably hold, more on sizing in a moment:
ollama pull qwen2.5-coder:7b
# verify it answers
ollama run qwen2.5-coder:7bOllama is the easiest on-ramp, but it’s not the only local server Aider can use, anything that speaks the OpenAI API works. If you’d rather use a GUI-driven backend, our Ollama vs LM Studio vs Jan comparison covers the alternatives; the Aider-side config is similar in spirit but the exact env vars differ.
Step 2: Install Aider
Aider is a Python tool. The maintainers recommend installing it with their dedicated installer so it gets its own isolated environment and doesn’t collide with your project’s dependencies:
python -m pip install aider-install
aider-installA pipx install aider-chat (or a plain pip install aider-chat inside a virtualenv) also works if you prefer to manage the environment yourself. Whichever route you take, confirm it landed:
aider --versionAider updates frequently and some behavior described here is version-dependent, so if a flag doesn’t behave as expected, check aider --help and the official docs rather than assuming. That’s a general rule for fast-moving tools, not a knock on Aider.
Step 3: Point Aider at your local model
This is the part people get wrong, so here’s the exact pattern. Aider finds your Ollama server through an environment variable, and addresses the model with a provider prefix.
First, tell Aider where Ollama lives:
export OLLAMA_API_BASE=http://127.0.0.1:11434
# Windows (PowerShell/cmd): setx OLLAMA_API_BASE http://127.0.0.1:11434Then launch Aider against your model. The important detail: Aider’s docs recommend the ollama_chat/ prefix over the older ollama/ prefix, because it uses Ollama’s chat endpoint and produces noticeably better edits.
aider --model ollama_chat/qwen2.5-coder:7bThe model name after the prefix is exactly the tag you pulled with Ollama, qwen2.5-coder:7b, qwen2.5-coder:32b, qwen3-coder:30b, devstral, whatever you have locally. Run that command from inside a git repository and Aider drops you into its chat prompt, ready to /add files and start editing. If Ollama is running and the model name matches, that’s the entire setup.
If your Ollama instance sits behind authentication (some remote or shared setups do), Aider also reads an OLLAMA_API_KEY environment variable. For a standard local install on your own machine, you won’t need it.
Step 4: Fix the context window, do not skip this
Here is the single setting that determines whether your local Aider feels competent or brain-damaged.
Ollama historically defaults to a 2,048-token context window. Aider, meanwhile, routinely builds prompts far larger than that: system instructions, a repo map, the full text of every file you’ve added, plus the conversation. When the prompt blows past the context limit, Ollama doesn’t raise an error, it silently discards the overflow. The result is an agent that “forgets” the file you just showed it, edits the wrong thing, or invents code that doesn’t match what’s actually on disk. It looks like the model is stupid. It’s really just half-blind.
Recent Aider versions mitigate this automatically: by default Aider sizes Ollama’s context window to fit each request plus roughly 8k tokens for the reply, so the prompt isn’t silently truncated out from under you. That handles most cases, but a window that grows with every request can also surprise your VRAM, so for predictable memory use it’s worth pinning a fixed size yourself. The robust way is a per-model settings file. Create .aider.model.settings.yml in your project root (or home directory):
- name: ollama_chat/qwen2.5-coder:7b
extra_params:
num_ctx: 32768That num_ctx value tells Ollama how big a window to actually allocate for this model. You can also raise the server-side default when you start Ollama:
OLLAMA_CONTEXT_LENGTH=32768 ollama serveOne caveat worth stating plainly: context is not free. A bigger num_ctx consumes more VRAM on top of the model weights, and pushing it too high can spill onto system RAM and tank your speed, or trigger an out-of-memory error. Pick a window your card can actually back. If you’re unsure how high you can go, our deep dive on how to increase the Ollama context window explains the memory math and how to find your ceiling without guesswork.
Which local models are realistic for Aider
Aider leans hard on two model abilities: writing correct edits in its diff format, and following instructions over multiple turns without drifting. Small chat models flunk both. You want a coding-specialized model, and you want as much of it as your VRAM allows.
A rough, honest mapping by hardware tier:
| Your VRAM | Realistic local model class | What to expect with Aider |
|---|---|---|
| 8GB | ~7B coder (e.g. Qwen2.5-Coder 7B) | Single-file edits, small functions, explanations. Stalls on multi-file work. |
| 12-16GB | 14B-class coder | Reliable single-file refactors and tests; usable but not tireless. |
| 24GB | 32B-class coder (Qwen2.5-Coder 32B), the newer Qwen3-Coder 30B-A3B, or an agent-tuned ~24B (Devstral) | The first tier where Aider feels like a real pair, with room for context. |
These are model classes, not a leaderboard, treat them as a starting point and run your own test on a real task from your repo. Worth a look at the 24GB tier is Qwen3-Coder 30B-A3B, a newer mixture-of-experts coder that fits 24GB at Q4_K_M and was explicitly trained for agentic, tool-driven workflows, exactly the loop Aider runs. Because only a few billion parameters activate per token it generates quickly for its size, so it’s a natural pairing with a harness that streams edits at you turn after turn. The older Qwen2.5-Coder 32B and Devstral remain perfectly good picks; try them side by side on your own repo. For the full breakdown of which coding model fits which card, including quantization trade-offs, see best local coding model by VRAM tier; if you’re specifically on a 24GB card and want the most out of it, best local LLM for 24GB VRAM covers the sweet-spot setups.
A blunt point on quantization: Aider’s maintainers have noted that heavily quantized local models can produce meaningfully worse edits than the same model at a higher precision. If your edits keep coming back malformed, the model may be too aggressively compressed for the job, not too small. Try a less-quantized variant before you give up on a model.
Speed: what “usable” actually feels like
A local model on a single consumer GPU is slower than a frontier cloud endpoint, and Aider makes you feel it because you’re watching edits stream into your terminal. The relevant number is generation speed in tokens per second, and your tolerance depends on the task.
For interactive back-and-forth, anything in the rough ballpark of 20-40 tokens/second feels fine, comparable to reading speed. Drop much below ~10 tok/s and a multi-file edit becomes a coffee-break affair. The variables are model size, quantization, and how full your context window is: a near-full 32k context is slower to process than an empty one, every turn. We get into what counts as comfortable in tokens per second: what’s actually usable.
The practical move is to match model size to task urgency. Keep a fast 7B-14B coder for quick, interactive edits where latency matters, and reach for a slower 32B only when you’ve got a hard problem worth waiting on. There’s no rule that says you must use one model for everything, switch with --model per session.
Honest expectations vs frontier cloud models
This is where you deserve a straight answer rather than a sales pitch. A good local coding model wired into Aider is genuinely useful for the daily 80%: scoped refactors, writing tests, translating a snippet between languages, explaining an error, scaffolding a file, renaming across a file. For that work, local is fast enough, free per token, and completely private.
Where local still loses:
- Hard, sprawling, many-file reasoning. The biggest frontier models hold more of a large codebase in their head and reason across it better. A “understand this 200-file legacy system and re-architect it” task still favors cloud.
- Very long single contexts. No 24GB consumer card can hold the enormous context windows the top cloud models offer. If your task genuinely needs 200k tokens of context, local can’t match it today.
- Peak instruction-following and tool reliability. Frontier models drift less and emit cleaner diffs over long sessions. Local models need shorter, better-scoped tasks to stay on the rails.
The honest framing: a local Aider setup isn’t a strictly-better replacement for a frontier cloud model, it’s a different trade. You give up some ceiling on the hardest tasks and some speed, and in exchange you get privacy by construction, zero marginal cost, and a tool that never refuses, rate-limits you, or changes its terms mid-project. For a developer who simply doesn’t want their codebase leaving their machine, that trade is usually worth making, and you can always keep a cloud key around for the rare task that genuinely needs it.
Quick reference
The whole local setup, start to finish:
# 1. pull a coding model in Ollama
ollama pull qwen2.5-coder:7b
# 2. tell Aider where Ollama is
export OLLAMA_API_BASE=http://127.0.0.1:11434
# 3. launch Aider against the local model (note the ollama_chat/ prefix)
aider --model ollama_chat/qwen2.5-coder:7b…plus a .aider.model.settings.yml raising num_ctx to something your VRAM can hold. Get those four things right, the prefix, the API base, the model size, and the context window, and you have a private, offline AI pair programmer that never sends a line of your code to anyone. Start with a model your hardware holds comfortably, prove it on a real task from your own repo, and scale up only when you hit its limits.