Aider + Ollama: code in the terminal with a 100% agent local

#Why use Aider in the terminal

Where Cline or Continue live in VS Code, Aider embraces the terminal. You stay in your shell, at the root of your Git repository, and converse with the model as if it were a colleague with access to the code. It is a different workflow, closer to the command line, that appeals to people who live in tmux and do not like leaving the keyboard.

Git-focused

Each accepted change becomes a clean commit with a message written by Aider. Your history stays readable, and you can undo any change with a simple git revert.

Automatic repo map

Aider builds a map of your repository (function signatures, classes, structure) and sends it to the model along with the open files. The model understands the context without you loading the entire project.

Editor-agnostic

Aider modifies files on disk. You continue using your usual editor in parallel: Aider sees your changes, and you see its changes.

100% local with Ollama

Connected to Ollama, the model runs on your GPU. Your code and prompts never leave the machine, which makes all the difference for proprietary code or code covered by an NDA.

#Requirements and installation

Three building blocks: Python for Aider, Ollama running with a loaded coding model, and a git repository. Aider requires a git repository to work fully—it is what drives the commits.

1. 01
   Check Ollama

   Ollama must listen on its default port. Run ollama list to confirm that it responds and see which models are already installed.
2. 02
   Install Aider

   The recommended approach uses pipx or the official install script, which isolates Aider in its own environment to avoid Python dependency conflicts.
3. 03
   Navigate to a git repository

   Open a terminal at the root of a version-controlled project. If the project is not yet under git, run git init first: Aider needs it to commit its changes.

# Via pipx (isole Aider, n'encombre pas votre Python système)
python -m pip install --user pipx
pipx install aider-chat

# Vérifier l'installation
aider --version

#Configure Aider for Ollama

Aider talks to Ollama through its OpenAI-compatible endpoint. Two things to configure: the base URL of Ollama (an environment variable) and the model to use. The cleanest approach is to place an .aider.conf.yml file at the project root (or in your home directory for a global setting), so you don't have to re-enter the options each time you launch it.

# Indique à Aider où trouver l'API Ollama
export OLLAMA_API_BASE=http://127.0.0.1:11434

# Lancer Aider avec un modèle Ollama (préfixe ollama/)
aider --model ollama/qwen3.5:9b

To avoid retyping anything, put these settings in a configuration file. Aider automatically reads an .aider.conf.yml found at the repository root or in your home directory.

# Modèle principal servi par Ollama (préfixe ollama/ obligatoire)
model: ollama/devstral:24b

# Modèle léger pour les tâches annexes (messages de commit, résumés)
weak-model: ollama/qwen3.5:9b

# Auto-commit des modifications acceptées (comportement par défaut)
auto-commits: true

# Ne pas committer automatiquement les fichiers que VOUS modifiez
dirty-commits: false

- name: ollama/devstral:24b
  extra_params:
    num_ctx: 8192

#Which model for your VRAM

Aider sends a lot of context (added files + repo-map) and expects a well-formed patch in return. A model that is too small produces broken diffs that Aider cannot apply. Aim for the largest coder model your GPU can load comfortably, while leaving headroom for context.

#The end-to-end workflow

Here’s the typical workflow for a change, from launching Aider to committing. Once you get into this rhythm, you can chain changes together without ever leaving the terminal.

1. 01
   Run Aider from the repository root

   Aider starts, reads the config, builds the repo map, and displays a prompt. It indicates the active model and the number of detected files.
2. 02
   Add the relevant files with /add

   Add only the files the task needs to modify. The fewer files in the context, the more precise the model remains. The repo-map already gives the model a view of the rest of the project.
3. 03
   Describe the modification in French

   Type your request in natural language: “add email validation to the registration form.” Aider thinks it through, then proposes a patch.
4. 04
   Review the proposed diff

   Aider shows the diff before applying it. Check it. If something is wrong, reply to correct it: “non, utilise une regex plus stricte”.
5. 05
   Let Aider commit

   Once the patch is applied, Aider automatically creates a commit with a descriptive message. Your Git history stays clean, and every change is traceable.
6. 06
   Iterate or cancel

   Continue with the next change. If you don't like an Aider commit, /undo cancels the last commit it created without touching anything else.

$ aider
Aider v0.x — model: ollama/devstral:24b
Repo-map: 42 fichiers

> /add src/auth/register.py
Added src/auth/register.py to the chat

> Ajoute la validation de l'email dans le formulaire d'inscription

[Aider propose un diff, l'applique, puis :]
Commit a1b2c3d  feat: valider le format de l'email à l'inscription

#Key commands for everyday use

Aider is controlled with slash commands in its prompt. A handful is enough to cover 90% of use cases.

/add fichier

Adds one or more files to the editing context. Aider will write to these files. Limit yourself to what is strictly necessary.

/drop fichier

Remove a file from the context. Useful when switching tasks to start with a clean context.

/architect

Enables plan-then-code mode: the model first reasons about the approach, then generates the diff. Ideal for nontrivial changes.

/diff

Displays the changes made since the last commit, so you can review what Aider changed before continuing.

/undo

Undo the last commit created by Aider. An immediate safety net if a change goes wrong.

/run commande

It runs a shell command (tests, linter) and feeds the output back into the chat. Aider can then make corrections based on the actual errors.

/ask question

Ask a question about the code WITHOUT triggering a modification or commit. To understand before acting.

#Local limitations compared with the cloud

Let's be honest: a local model on 8 to 16 GB doesn't match a cutting-edge cloud model. Knowing the limitations prevents frustration and helps you choose the right tool for the task.

Sometimes malformed diffs

Small models sometimes produce a patch that Aider cannot apply (broken format). Moving to a larger model or increasing num_ctx significantly reduces this problem.

Shorter context

A cloud model can handle dozens of files. Locally, keep the context tight: add only a few files at a time with /add, and rely on the repo-map instead of loading everything.

Multi-file reasoning

Refactors that touch many files at once remain a weak point for local models. Break them into several small tasks, or switch to /architect to structure them.

GPU-dependent speed

Latency depends on your card. A 32B model on a modest card will be slow. If responsiveness is the priority, a well-tuned 7B or 14B is more pleasant for everyday use.

#Frequently asked questions