Aider

The awkward question about AI coding tools is not whether they write usable code. It is what happens to the code they write when you were not watching closely.

Most agents — Cursor and GitHub Copilot included — answer this with a proprietary review panel: a diff view inside their own interface, an undo stack you have to trust, and a history that lives in the tool rather than in your project. That works until you close the tool, or until three of its changes need untangling from two of yours.

Aider's answer is older and considerably better. It commits each change to git as it makes it, with a message describing what it did. The review interface is `git diff`. The undo button is `git revert`. Nothing about the AI's work is special, because it has been converted into ordinary version control history that every tool you already own understands.

What Is Aider, And Who Is It For?

• Aider is an open-source AI pair programmer that runs in your terminal, not in an editor — you point it at a repository and describe the change you want.
• Every edit is committed to git automatically with a written commit message, so you review AI changes with `git diff` and undo them with `git revert`.
• It maps your entire codebase, which is what lets it work in large projects rather than only in the file you happen to have open.
• It is model-agnostic — it works with Claude, GPT, DeepSeek and o-series models, and connects to almost any LLM including local ones.
• It is free software with bring-your-own-key billing: no subscription to Aider, but you pay your model provider for tokens.

Why Does Aider Commit To Git Automatically?

Aider commits each change with a sensible commit message so you can use familiar git tools to diff, manage and undo AI changes. That single design decision resolves the biggest practical problem with agentic coding.

The problem is granularity. An agent asked to add a feature may touch nine files. If it gets seven right and two wrong, you need to keep seven and discard two — and a tool with one undo button forces you to throw away the good work with the bad.

Committing per change turns that into ordinary version control. You revert the two bad commits and keep the seven good ones. You can cherry-pick, rebase, or open a branch and throw the whole session away without losing anything you did yourself.

It also produces something valuable by accident: a readable history of what the AI actually did, in your repository, permanently. Six months later the commit log tells you which changes came from a model and what it was asked for, which is exactly the provenance that matters when you are debugging something odd.

The habit this rewards is working in a branch. Start a branch, let Aider work, review the commits as a set, then merge or discard. That is the same workflow you would use with a junior colleague, and it is the right mental model for the tool.

An AI edit you can review with git diff and undo with git revert is not a special kind of change. That is the point.

The Repo Map Is The Real Engineering

Aider builds a map of your entire codebase, which is what lets it work well in larger projects.

This is the part that separates a serious tool from a chat window with file access. Language models have finite context, and a real repository does not fit. The naive approach — paste in the current file and hope — fails the moment a change requires knowing what a function elsewhere expects.

A repository map is a compressed structural summary: which files exist, what they define, how they relate. The model gets an index of the codebase rather than its full text, then requests the specific files it needs. That is roughly how a human joins an unfamiliar project.

The practical consequence is that Aider degrades gracefully as a codebase grows, where context-window approaches degrade sharply. It also means the quality of its work depends on how legible your code is to a structural reader — clear module boundaries and honest naming help it for the same reasons they help a new colleague.

Which LLMs Work Best With Aider?

Aider states it works best with Claude 3.7 Sonnet, DeepSeek R1 and Chat V3, and OpenAI's o1, o3-mini and GPT-4o, but can connect to almost any LLM including local models.

Model-agnosticism is a more valuable property than it looks, and the reason is timing. Frontier coding ability has changed hands several times in the past two years. A tool welded to one provider inherits that provider's bad quarter; a tool that takes a key and a model name does not.

It also gives you a cost lever no subscription tool offers. You can run an expensive frontier model for a genuinely hard refactor and a cheap one for mechanical edits, deciding per task rather than per month.

Local model support is the option most people overlook and some people require. If your employer forbids sending source code to a third-party API — which is common in finance, defence and healthcare — an agent that runs against a model on your own hardware is the difference between using this technology and not.

Expect a real quality gap when you do that. Local models good enough to run on a workstation are not equivalent to frontier hosted models, and the honest framing is that self-hosting buys you permission rather than parity.

• Frontier hosted model — best results, highest token cost, source code leaves your machine.
• Mid-tier hosted model — usually enough for mechanical edits, test writing and small features.
• Local model — no data leaves your network, materially weaker output, and the only option under some policies.
• Switch per task rather than per subscription; that flexibility is the main advantage of bring-your-own-key.
• Whatever you pick, review the commits — the model choice changes quality, not your responsibility for what ships.

Is A Terminal Agent Better Than An IDE One?

This is the real decision for most people, and the answer genuinely depends on how you work rather than on which tool is better.

A terminal agent composes, which is the shared argument for OpenCode too. It sits alongside your existing editor, whatever that is, and it scripts — you can run it in a loop, in CI, or over SSH on a remote machine. It does not ask you to change editors, and it will still work if your editor's plugin ecosystem moves on.

An IDE agent sees more. It knows what you have selected, what your language server is complaining about, which tests just failed and where your cursor is. That ambient context makes small, local edits faster and more accurate, and it is genuinely useful in a way a terminal cannot replicate.

The dividing line in practice is task size. For a change spanning several files with a clear description, a terminal agent working against a repo map is excellent. For a fiddly fix in a function you are currently looking at, an IDE agent wins easily.

Plenty of developers use both, and there is no penalty for doing so — Aider changes nothing about your repository except its commits, so it coexists with anything.

Getting A Real Answer In Half An Hour

Aider is free and installs with pip, so evaluation costs only tokens and time. This sequence tells you whether the workflow suits you.

The bar is step five. If reviewing the commits feels like less work than making the change yourself, the tool is earning its keep; if not, it is not.

1. Install with `python -m pip install aider-install` and then `aider-install`, and set an API key for a model you already trust.
2. Create a branch first. Never evaluate an agent on your main branch — the whole point is that the work is disposable.
3. Pick a real task you were going to do anyway, spanning two or three files. A toy task tells you nothing about the repo map.
4. Let it work without interrupting, then read the commits with `git log -p` rather than looking at the final state. The sequence shows you how it reasoned.
5. Ask whether reviewing those commits was less work than writing the change. That is the entire value proposition, and it is a yes-or-no answer.
6. Check your provider's token spend for the session, and multiply by a realistic week. Bring-your-own-key means the bill is invisible until you look.

What Aider Costs To Run

There is no subscription. Aider is open source and installed from PyPI; you supply an API key and pay your model provider for the tokens it uses.

That structure has two consequences worth planning for. The good one is that there is no floor: a week you do not use it costs nothing, which no seat-based tool can match. The awkward one is that there is no ceiling either, and an agent working through a large refactor can consume a surprising number of tokens without telling you.

Cost is driven by the model you choose and by how much of the repository ends up in context. The repo map keeps this far lower than pasting whole files would, but a long session on a large project is still real spend.

The discipline that keeps it sane is scoping. Ask for one change at a time, add only the files that are relevant, and start a fresh session between unrelated tasks rather than accumulating context.

We do not publish amounts, since every provider prices differently and rates change. Watch your provider's usage dashboard for the first week; that number, not any published estimate, is what this costs you.

Aider: What The Project Publishes