Last updated
Aider is an open-source AI pair programmer that lives in a terminal REPL and edits files in a git repository directly. There is no editor plugin, no browser tab, and no inline autocomplete. You run it inside a repo, describe a change in plain English, and it rewrites the relevant files and commits the result. The commit is not an afterthought — it is the design.
Most AI coding tools hand you a pile of modified files and leave the bookkeeping to you. Aider commits after each successful exchange, with a generated message describing what it just did, so an AI-authored change becomes a normal object in your history: you can git show it, diff it, revert it, or cherry-pick it like any other commit. Aider ships an /undo command that drops its most recent commit when a change goes wrong, and auto-committing can be switched off entirely if your team prefers to stage everything by hand. It can also be configured to mark its commits so AI-authored work stays distinguishable from yours in git log or git blame months later.
The practical consequence is that Aider expects a reasonably clean working tree when it starts. If you have half-finished edits lying around uncommitted, Aider's commits will swallow them and the clean-history benefit disappears. Commit or stash first — that habit is the price of admission, and it is the single most common reason a first session with Aider feels messy.
Aider ships no model of its own. You supply an API key for Anthropic, OpenAI, Google, DeepSeek, an aggregator like OpenRouter, or a local endpoint served by Ollama, and Aider handles the parts that are actually hard: assembling repository context, prompting the model to emit edits in a parseable format, and applying those edits to disk without mangling the file. That makes Aider closer to infrastructure than to a branded assistant — output quality tracks whichever model you pointed it at, and a disappointing session is often a model choice rather than a tool problem.
Because you pay the provider directly, Aider reports token usage and cost back to you after each exchange instead of hiding it behind a subscription. That readout is what makes its cost-control features worth using: an architect mode that lets an expensive reasoning model plan a change while a cheaper model writes the actual diff, a context budget you can inspect and clear mid-session, and prompt caching where the provider supports it. Developers who think about what inference actually costs tend to like this arrangement. Developers who want one predictable monthly line item on a corporate card do not.
Naively stuffing a repository into a context window stops working almost immediately. Aider instead builds a repo map: a parsed structural summary of the codebase — function and class signatures and how files reference one another — rather than the full text of every file. It ranks which parts of that graph matter for the request at hand and sends only those, within a token budget you can tune. You then explicitly add the handful of files you want editable, and can mark reference material read-only so the model can see it without rewriting it.
This is a different bet than the embedding-based codebase indexes Cursor and GitHub Copilot build, and it has a different failure mode. Aider is unusually good at reasoning about structure it can parse and unusually blind to anything that is not code: a convention that only exists in a Notion page, a schema implied by a migration, a rule nobody ever wrote down. The standard workaround is a conventions file committed to the repo and loaded read-only every session, which is effectively hand-written context engineering — cheap, but it is work you have to remember to do.
The pure REPL is not the only way to drive Aider. In watch mode it monitors your files while you work in whatever editor you prefer; you leave a comment ending in AI! where you want a change, save the file, and Aider picks it up, acts on it, and commits. That recovers much of the ergonomics of an IDE assistant without Aider needing an IDE plugin at all, and it is the feature most likely to change a skeptic's mind about a terminal-only tool.
Aider can also run your linter and your test suite after it edits, read the failures, and attempt to fix them itself — a loop that turns a vague request into something closer to a verified change. It can pull a URL into context, run a shell command and read the output, and accept a single instruction non-interactively from a script, which is what makes a batch refactor across many repositories practical rather than theoretical. There is also a copy-and-paste mode for people who hold a chat subscription but no API budget, at the cost of the automation everything else here depends on.
Aider fits badly in more situations than its advocates usually concede:
Who it fits: git-fluent developers who already spend the day in a terminal, want no vendor lock-in, and would rather tune a tool than be shepherded by one. See Copilot versus Aider for the head-to-head, or running models locally if the real appeal is keeping source code off other people's servers entirely.
Developers working in tmux or a bare shell describe a change once and have Aider edit several related files together — a new endpoint plus its route, handler, and test — without leaving the terminal or hand-opening each file.
Because each exchange produces its own commit with a generated message, teams that care about reviewable history can revert or cherry-pick a single AI-authored change months later without untangling it from hand-written work in the same branch.
Architect mode lets a strong reasoning model decide what the change should be while a cheaper, faster model writes the diff. For repetitive edits across many files this materially changes what a session costs, and Aider shows the running total so the tradeoff is visible rather than guessed at.
Pointed at a local model served by Ollama, Aider works with no outbound network call at all. Capability drops compared to a frontier API, but for a codebase under an exfiltration policy the question is whether the tool works offline, not whether it works best.
Aider accepts a single instruction non-interactively, so the same migration — swapping a deprecated helper, updating a config format — can be applied repo by repo from a shell loop, with each result landing as its own reviewable commit.
After editing, Aider can run the project linter and test suite, read the failures, and attempt repairs on its own. The result is a change that has at least been executed rather than one that merely looks right in a diff.
Aider is free and open source with no paid tier, no seats, and no subscription. What you actually pay is API usage billed directly by whichever model provider you connect — or nothing at all beyond electricity if you run a local model through Ollama. That makes the cost entirely usage-shaped: light work against an inexpensive model can be close to free, while sustained work against a frontier model is a real recurring expense that looks nothing like a flat monthly fee. Aider prints token counts and cost after each exchange, and its architect mode and context controls exist specifically so you can push that number down, but budgeting for it is your job rather than the vendor's.
The tool is free and open source with no paid tier. You pay your model provider directly for API usage, so the real cost depends on which model you pick and how hard you use it. Run a local model through Ollama and the marginal cost is your own hardware.
No. It runs as a terminal REPL, and there is no built-in GUI, visual diff viewer, or IDE panel. Most users review changes in their normal editor or with git diff. Watch mode narrows the gap by letting you trigger Aider from a comment in your editor, but the tool itself stays in the terminal.
Yes — auto-commit can be disabled if your team wants to stage everything by hand. Most people leave it on, because the commit-per-change history is the main reason to prefer Aider, and the undo command makes a bad commit cheap to discard.
That is what the repo map is for. Instead of sending file contents, Aider sends a ranked structural summary — signatures and cross-references — within a token budget you control, and you explicitly add the specific files you want it to edit. It holds up well on large repositories, though it cannot see conventions that live outside the code.
Yes, by pointing it at a locally served model. Expect a capability drop relative to a hosted frontier model, but no source code leaves the machine, which is the deciding factor for some codebases regardless of quality.
Not strictly, but you should. Running Aider outside git discards its commit hygiene, undo behavior, and most of the reason to choose it over an editor-integrated assistant. Start from a clean working tree so its commits do not absorb your uncommitted edits.
Different shapes. Aider is free, terminal-native, model-agnostic, git-centric, and unmanaged. Cursor and Copilot give you inline completion, a GUI, and a single predictable bill, plus the admin controls an employer usually wants. Plenty of terminal-first developers run both: an IDE assistant for typing-speed work, Aider for larger scripted changes where clean commits matter.
Full review coming soon.