Aider, AI coding in the terminal

Aider, AI coding in the terminal

Aider is a command line tool that changes files in your repository based on what you type, committing after each change with a written description. It replaces no editor, needs no extension, and ties you to no single model provider.

That last point separates it from most of its competition. You supply a key for any provider or point it at a locally running model, and the tool handles the rest: picking files, applying changes, and recording them in history.

Installation and first run

pip install aider-chat
cd my-repository
aider --model sonnet

After starting you are in a conversation. You describe what should change, the tool proposes edits, applies them, and records them in version history.

The current release carries version 0.86.2 and was published on the twelfth of February 2026, with required Python between 3.10 and 3.12. That date deserves attention and I return to it below, since it matters when deciding.

You add the files you are working on to the conversation:

/add src/services/orders.py src/tests/test_orders.py
/ask how does order cancellation work
/code add partial refund handling

Separating questions from instructions helps here. Ask mode reads and answers without touching files; code mode writes. Starting with a question on unfamiliar code saves reverting unnecessary changes.

When a change goes the wrong way, undoing it is one command, since the tool records its own changes separately.

/undo
/diff
/drop src/tests/test_orders.py
/tokens

That last command shows how much context the added files and the conversation history occupy. It is the simplest way to notice that a conversation has grown to a size where every further step costs many times more than the first, and answers start losing the thread.

The repo map

This is the element separating this tool most from simpler assistants, and worth understanding.

A whole project does not fit in a model's context, so the tool builds a condensed representation of it: file names, function signatures, class definitions, imports. The model therefore sees the overall structure, while holding the contents only of files added to the conversation.

The practical effect is that a change made in one file uses existing functions from others rather than inventing new ones doing the same thing. That is the most common flaw in tools without such a map: correct code that duplicates something already in the project.

The map has limits. In a very large repository it starts consuming considerable context itself, so naming files explicitly beats hoping the model lands on them. Naming a directory in the instruction helps too, since it narrows the search area more effectively than a more precise task description.

Architect mode

By default one model plans and writes. Architect mode splits that into two: one model lays out a plan of changes, another turns it into concrete file edits.

The gain is measurable on tasks spanning several files. A model that reasons longer plans better while erring more often on the exact edit format, and a faster model does the opposite. Splitting the roles uses both strengths.

The price is equally simple: two calls instead of one at every step, and a higher cost since the planning model works longer. On a small fix that is waste; on a change touching six files it usually pays.

A practical rule emerges after a few days. Base mode for changes you can describe in one sentence. Architect mode when you yourself have to think for a moment about what order to do things in.

Version history integration

Every change lands in a separate commit with an automatically written description, and that is the feature drawing the most conflicting opinions.

The advantage is obvious: every step can be reverted separately, and reviewing what the tool did reduces to reading the history. The command undoing the last change takes one word.

So is the drawback: the history fills with small commits nobody wants on the main branch. The answer is working on a separate branch and squashing on merge, or disabling automatic commits and making them yourself.

One rule holds regardless: start with a clean working tree. Otherwise the tool's changes mix with your own, and separating them afterwards is a task of its own.

Release pace and what follows

The most recent release published in the package registry dates from February 2026. Nearly six months have passed since, which for a tool in this category is a long stretch.

Worth saying plainly, since it matters practically. The tool works and remains one of the better options in its niche, while support for new models, performance fixes, and changes keeping pace with providers stopped arriving at the old rate. For a tool whose value depends on how well it talks to current models, that is a real factor.

What to do about it. Before deciding, look at the repository and check when the last activity was and whether newer releases appeared after that date, since the situation may have changed since this text was written. Check too whether the models you intend to use are supported in the version you install.

This is not a reason to walk away. It is a reason to know what you are signing up for and not to build a process around this tool that cannot be reproduced with another. Fortunately with a terminal tool that is easy, since it changes neither your code nor how the team works.

Working with a local model

This is the scenario some people reach for the tool for at all, and it deserves separate treatment, since it turns out differently from what promotional material suggests.

The starting point is a requirement: code cannot leave the company. With tools carrying a built in model provider there is no route here, since sending file contents outside is built into how they work. Here you point at the address of a model server running on your own hardware and the rest behaves the same.

The reality, though, is that a smaller local model handles this task worse, and the gap is wider than in ordinary conversation. The reason lies in the edit format: the tool expects changes written in a fixed shape, and a weaker model breaks that format so the change fails to apply. You see it as repeated attempts and messages about a fragment failing to match.

Three practical conclusions follow. The model for this task needs choosing deliberately, since not every model good at conversation is good at editing files. Tasks are worth phrasing more finely than with a cloud model, since a shorter change breaks the format less often. And: architect mode with a local model planning and another editing often beats one model in both roles.

Measure the time too. A model running on a typical workstation answers slowly enough that the work changes rhythm: it stops resembling a conversation and becomes assigning tasks. At that rhythm other tools are sometimes more comfortable, so a decision for a local model should follow from a requirement rather than from curiosity.

The guidelines file and repeatability

The tool reads a guidelines file placed in the repository, and that is the cheapest way to improve results available with it.

Without one the model sees the code and draws conclusions from it, which works on a coherent project and fails on one with history. A convention departed from over two years will be read as both versions at once and the result becomes arbitrary.

What belongs there: the libraries in use and those the team deliberately avoids, naming conventions, where tests live and how they run, the language version, and rules that do not follow from code.

# Project conventions

Python 3.12, dependencies through uv, formatting with ruff.
Tests: pytest, run via `make test`.

We use:
- pydantic for input validation
- httpx for network calls

We do not use:
- requests, we are migrating to httpx
- the service layer never reaches the database directly, only through repositories

A task is finished when `make check` passes.

That last line matters most. A tool able to run one command gathering every check fixes its own mistakes rather than handing back code that does not compile.

The effect shows from the first task, since the most common category of corrections disappears: code that is technically correct and does not match the rest of the project. Instead of fixing the same thing on every change, you write the rule once.

It also pays to keep a record of instructions that worked. A phrasing after which the tool landed on the first attempt is repeatedly useful in the same project.

Record settings meant to be repeatable across the team in a configuration file next to the conventions, rather than typing flags at every launch.

model: sonnet
auto-commits: false
test-cmd: make check
auto-test: true
read:
  - CONVENTIONS.md

Turning off automatic commits is a decision worth taking deliberately. By default every change enters history immediately, which is convenient on a good result and leaves an entry to undo on a bad one. When working on unfamiliar code, reviewing the change before it is recorded is more comfortable.

Aider against the alternatives

The first row's main advantage is independence. A terminal tool plugs into any stack, requires abandoning no editor configuration built over years, and lets you choose the model, including one running on your own hardware if code cannot leave the company.

Its main drawback is equally clear: no completion while typing. This is a different way of working, where you describe a task and review the result rather than writing code alongside a model line by line. Some people prefer one, some the other, and that is a matter of habit rather than superiority.

Note also that these tools do not exclude each other. An extension for editor completion and a terminal tool for larger changes coexist without conflict, since they operate at different moments.

Costs and how to steer them

You pay the model provider directly, so the bill depends on how you work rather than on a subscription.

The largest factor is the number of files in the conversation. Every added file enters the context on every subsequent instruction, so a conversation with fifteen files costs several times more than one with three. The command removing files from the conversation once you are done with them is the simplest saving there is.

The second factor is conversation length. Context grows with every turn, so the tenth instruction in one session costs considerably more than the first. Closing a session and starting a new one once a task finishes is often cheaper than continuing to refine.

The third is model choice. Renaming a variable across five files does not demand what designing a new module does. Switching models mid work is one command here and worth using.

The fourth, in architect mode, is a deliberate model pairing. A strong planner with a fast editor usually gives a better result to cost ratio than a strong model in both roles.

Common mistakes

The first is running on a dirty working tree. The tool's changes mix with yours, and reverting one without the other becomes awkward.

The second is keeping files in the conversation you no longer need. Each costs on every instruction.

The third is tasks touching too many files at once. A change that cannot be reviewed enters the history unreviewed.

The fourth is working without tests. A tool that sees red after a change corrects itself. Without that, all checking stays with you.

The fifth is skipping ask mode on unfamiliar code. Asking how a fragment works before changing it costs pennies and saves reverting.

The sixth is assuming the tool knows the project's rules. Conventions invisible in the files added to the conversation will be broken, so whatever must hold belongs in a guidelines file.

FAQ

Is Aider free?

The tool itself is, being an open project. You pay only for model calls at your chosen provider, and with a model running on your own hardware the token cost disappears entirely, at the price of quality and speed.

Which model should I use?

Any whose key you supply, the Claude family and local models included. Mechanical changes suit a cheaper model, design work a stronger one, and switching mid work is one command.

Is Aider still being developed?

The most recent release in the package registry dates from February 2026, so the release pace has clearly slowed. The tool works and is used, while before adopting it, check current repository activity and whether your models are supported.

How does it differ from Cursor?

In form and independence. Cursor is a separate editor with a built in model provider and completion while typing. Aider runs in a terminal, changes nothing about your environment, and lets you pick any model, including a local one.

Do I have to use git?

Yes, the tool is built around version history and commits after every change. Automatic commits can be disabled, while the repository itself is required, since reverting rests on it.

Documentation sits on the project site, and the code and releases in the GitHub repository.