Aider

Aider is the AI coding pair-programmer that took the early-2024 lead and held it. It runs in your terminal, watches your git repo, and applies edits as commits — a workflow that maps cleanly onto how working developers already use git. The local-AI angle: Aider is one of the most-deployed front-ends for Ollama + llama.cpp + LM Studio once you point it at a local model via the OpenAI-compatible base URL. The operator-grade question is "which model should I run behind Aider," not "should I use Aider," because at this point Aider is the default and the alternatives (Continue, Cursor cloud-only, OpenCode) all assume different operator preferences.

Architecture and what Aider actually is

Aider is a Python CLI tool (github.com/Aider-AI/aider, 25k+ stars and growing fast through 2025-2026). The operational model: Aider tracks the files you've added to the chat, sends them as context to an LLM, parses the LLM's edit instructions (in one of several diff formats), applies the edits to disk, and creates a git commit. Multiple file edits per turn are routine; full repo understanding via tree-sitter-based "repo map" is the killer feature.

It speaks the OpenAI-compatible API natively — point it at http://localhost:11434/v1 (Ollama), http://localhost:1234/v1 (LM Studio), http://localhost:8080/v1 (llama-server), or any other compatible endpoint and you're using a local model. Aider also speaks Claude API, OpenAI API, Gemini API, OpenRouter, etc. natively — many operators run cloud + local in the same workflow.

The architectural choice that matters most: Aider doesn't try to be an IDE. There's no editor UI, no panel, no chat sidebar. It's a terminal that talks to your repo. That means it doesn't fight your existing tooling (VS Code, Neovim, JetBrains) — you keep editing where you edit, Aider just makes commits.

Local stack compatibility

Aider works with any OpenAI-compatible local model server. The operator-grade question becomes "which local model produces correct multi-file edits?" Most 7-13B models can't reliably produce diffs in Aider's expected formats; the workflow demands ≥30B-class capability for serious refactor work, with Qwen 2.5 Coder 32B + DeepSeek Coder V3 33B as the current-default recommendations. The compatibility matrix below covers the runtime + hardware combinations operators actually use.

For runtime selection see /compare/engines/ollama-vs-lm-studio (the two most-common local backends Aider users pick). The agent-loop framing is in /guides/local-ai-for-coding-agents.

Setup + day-1 reality

pip install aider-chat (or pipx for isolated install) is the canonical path. The CLI is aider after install. Configuration via environment variables or .aider.conf.yml in your project root.

For local-model use:

# With Ollama (most common)
OPENAI_API_BASE=http://localhost:11434/v1 \
OPENAI_API_KEY=ollama \
aider --model openai/qwen2.5-coder:32b

The OPENAI_API_KEY value doesn't matter for local servers but Aider's libraries require it to be set. Use any non-empty string.

First-run reality: Aider's git integration auto-commits every successful edit. If you don't want that (working on a branch you don't want to pollute with experiment commits), pass --no-auto-commits. You'll still get the edits; they'll just sit unstaged.

The repo map: Aider builds a tree-sitter-based summary of your repo and sends it as context to the model on every turn. For large repos (10k+ files) this can blow past the model's context window. Solutions: /add only the files you're working on (Aider tracks ≤50 files reliably), use --map-tokens 0 to disable the repo map entirely, or pin to a model with 128k+ context.

Operational concerns

• Diff format choice matters. Aider supports several edit formats (whole, diff, udiff, diff-fenced, etc.). 7-8B models can sometimes handle whole (write entire file) but fail on diff (produce a diff to apply). Larger models handle diff reliably. Aider auto-picks per model but you can override with --edit-format.
• Context cost on local models is real. Each turn sends repo map + open files + chat history. For a 50k-context Qwen Coder 32B run, expect 30-60% of every turn to be context, not new generation. Plan token budget accordingly.
• Auto-commit + git integration assumes a clean repo. Aider warns on uncommitted changes but proceeds. If you mix manual edits with Aider edits without checkpointing, history gets messy.
• Model-switch friction. You can't seamlessly switch models mid-conversation. /exit and restart with a different --model. Aider's chat-history persistence helps but isn't seamless.
• No native multi-repo workflow. Aider operates on one repo at a time. If your work spans multiple repos, you run multiple Aider instances or work sequentially.

Performance reality

Aider's tok/s is whatever the underlying model + runtime delivers. Aider adds modest CPU overhead (tree-sitter, repo map building, diff parsing) but doesn't bottleneck inference. The user-experienced latency is dominated by:

1. First-turn repo-map build (one-time per session, can be 5-20 seconds for 5k-file repos)
2. TTFT on each turn (depends on context size, often 2-10 seconds for local 32B-class models)
3. Decode of the edit instructions + diff (where local-model tok/s matters)

For a Qwen 2.5 Coder 32B at Q4 on a 4090 producing a 5-file refactor: typically 30-60 seconds per turn end-to-end. Cloud Sonnet 4 / GPT-5 on the same task: 15-25 seconds. The gap is real — but cloud cost-per-turn is real too.

Failure modes (what breaks)

Ranked by community-error frequency:

1. Wrong edit format for the model. 7-8B local model + diff format → garbage edits. Workaround: use --edit-format whole for small models, accept that they overwrite whole files.
2. Context window exhausted mid-conversation. Repo map + chat history + open files exceed context. Aider truncates oldest messages but quality degrades. Restart with /clear more often than feels natural.
3. Auto-commit on a dirty repo. Aider commits its edits cleanly but your prior uncommitted changes hitch-hike onto the commit. Always run git status clean before starting Aider.
4. Local model produces invalid diff syntax. The model says it's editing a file but the diff Aider parses doesn't apply. /undo rolls back the failed apply attempt; re-prompt the model with stricter instructions.
5. Model loop on an impossible refactor. Some prompts (e.g., "rewrite this Python module in Rust") send local 30B-class models into incoherent loops. Cloud frontier models handle these; local doesn't reliably. Recognize the limit.
6. Tree-sitter language gaps. Aider's repo map needs tree-sitter grammars for your language. Mainstream languages (Python, JS/TS, Go, Rust, Java, C++) work; obscure languages or DSLs degrade silently.

How Aider compares

Compared to Continue: Continue is an IDE plugin (VS Code / JetBrains) that runs inline in your editor. Aider runs in a terminal, separate from the editor. Continue is better for inline autocomplete + small targeted changes; Aider is better for multi-file refactors + git-flow integration. Different operator preferences; many use both.

Compared to OpenHands: OpenHands is a more autonomous agent — it executes commands, runs tests, browses the web. Aider is more conservative — it only edits files. OpenHands is right for "I want the agent to verify its own work"; Aider is right for "I want the agent to make edits I review before committing." Different scope.

Compared to Cursor (cloud-only): Cursor is a full IDE fork with great UI but no local-model support without proxying. Aider works with local models out of the box. Pick Cursor if cloud frontier models are acceptable; pick Aider if local-only is the requirement.

Compared to OpenCode: OpenCode is conceptually similar — terminal coding agent, local-model-friendly. Aider has more momentum + ecosystem (more YouTube tutorials, more battle-tested edge cases); OpenCode has different UX bets. Try both; most operators settle on one.

Deployment paths

Three operator-grade deployment shapes documented in the structured deployment-paths section below: terminal daily driver, IDE-side complement (Aider in terminal + VS Code in editor — the canonical pair), and air-gapped audit (Aider + local Ollama for code review on offline / private codebases).

Editorial verdict

Aider is the right answer for terminal-comfortable developers who want git-integrated AI edits. The 25k-star + accelerating community is real. The local-model story is solid IF you give it a 30B-class coder model — anything smaller produces unreliable diffs. For developers who prefer in-editor experience, Continue is the better pick; for fully autonomous "agent runs tests + iterates" workflows, OpenHands is closer to fit.

The one operator-grade reservation: Aider's local-model performance gap vs cloud is bigger than the local-AI hype admits. Cloud frontier models still produce noticeably better refactors than local 30B-class models. The right framing: use Aider with local models when privacy / offline / cost matter; use Aider with cloud APIs when refactor quality is the operative constraint.

Last reviewed 2026-05-08 by RunLocalAI editorial. Reproduce or correct: /submit/feedback.