Aider

Last reviewed Aug 26, 2026 · 882 words

There is nothing to host with Aider. It is a Python CLI that runs in your terminal, reads your git repository, and sends pieces of it to whichever LLM you configure. The "self-hosted" decision is entirely about that model: a frontier API model costs money per request and writes correct multi-file edits, while a local model through Ollama costs nothing and, below roughly the 30B-parameter class, produces malformed edits often enough to be irritating. Everything else in this guide exists to make that choice cheap to reverse.

Install with the installer, not pip into your project

Aider drags in a long dependency tree (tree-sitter grammars, LiteLLM, a dozen provider SDKs). Installing it inside a project's virtualenv is the reliable way to break the project. Use the standalone installer, which gives Aider its own isolated environment and a aider command on your PATH:

python -m pip install aider-install
aider-install

Then run aider from the root of any git repository. It refuses to start outside git, and that refusal is the product's whole design rather than a limitation.

Every edit is a commit, so every edit is undoable

Each change Aider makes lands as its own commit with a generated message. If the change is wrong, /undo reverts exactly that commit and nothing else. This is the practical difference from IDE assistants that hold edits in an unsaved buffer: you can let Aider touch 6 files, run the test suite, and unwind the whole thing with one command. Two habits keep this clean. Commit your own work before a session starts, so Aider's commits never mix with yours, and only switch off auto-commits when you are deliberately batching several instructions into one logical change:

aider --no-auto-commits

The repository map is the second reason to use it. Aider parses the codebase with tree-sitter and sends the model a compressed outline of class and function signatures, so the model knows what UserRepo.find_by_email looks like without you pasting the file. You still /add the files you want edited; the map supplies the surrounding context.

The model choice is the entire cost equation

Aider speaks to nearly any provider through LiteLLM. Three configurations cover most people:

The local route is two lines:

export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/qwen2.5-coder:32b

Confirm the model fits before you blame Aider for slowness; the VRAM math post covers what a 32B model at Q4 needs. On the API side, the "costs add up" warning is real because every request re-sends the repo map plus every added file. Keep the added-file list short, /drop files when you move on, and assign a cheap model with --weak-model for commit messages and summaries. Architect mode (/architect) goes further: a strong model plans the change and a cheaper editor model writes it, which cuts the bill on long sessions.

Terminal-only is a real constraint, and watch mode is the workaround

There is no sidebar, no inline ghost text, no click-to-accept. If that matters, Cline lives in VS Code and the Aider vs Cline comparison lays out the split honestly. Aider's own answer is --watch-files: leave it running in a terminal, write a comment ending in AI plus an exclamation mark in any editor you like, save, and Aider picks up the instruction and makes the edit. It feels alien on day 1 and indispensable by day 3 for people who live in Vim or Emacs.

Put the settings in the repo, keep the keys out

A .aider.conf.yml at the repository root is read automatically and is safe to commit:

model: anthropic/claude-sonnet-4-5
weak-model: ollama_chat/qwen2.5-coder:7b
auto-commits: true
lint-cmd: ruff check --fix
auto-test: true
test-cmd: pytest -q

Keep API keys in environment variables or a .env file that is git-ignored, never in that YAML. auto-test is the underrated line: Aider runs your tests after each edit and feeds failures back to the model, which turns a mediocre model into a reasonable one on well-tested code.

What I'd do

Frontier model over the API for edits, with a local Ollama model on --weak-model and for /ask questions about the codebase. That combination costs a few dollars on a heavy day and nothing on a quiet one. Go local-only if the code genuinely cannot leave the building, but budget for a 24 GB GPU and expect to babysit the edit format. Either way, commit before every session, use /undo without hesitation, and read the AI pair programming workflow post for how this fits alongside a proper review process.