Does Aider Remember Between Sessions? What Actually Carries Over
Does Aider Remember Between Sessions? What Actually Carries Over Direct answer: no. Aider does not remember anything between sessions on its own. Every time you launch it, the model starts with no knowledge of your previous sessions. Nothing you explained, decided, or taught it last week is loaded back into its context automatically. But that is not the whole story, because Aider leaves artifacts behind. After a few weeks of use, your project directory accumulates files that look like memory:
Does Aider Remember Between Sessions? What Actually Carries Over
Direct answer: no. Aider does not remember anything between sessions on its own. Every time you launch it, the model starts with no knowledge of your previous sessions. Nothing you explained, decided, or taught it last week is loaded back into its context automatically.
But that is not the whole story, because Aider leaves artifacts behind. After a few weeks of use, your project directory accumulates files that look like memory: a full transcript of every session, your input history, convention files, and a git log of everything the pair programming produced. The honest question is not whether those files exist. It is whether they function as memory. Most of them do not, and the difference matters.
What Aider actually keeps
Aider writes four kinds of residue into your project directory:
.aider.chat.history.md— a complete Markdown transcript of every session, maintained automatically. This is the closest thing Aider has to a memory organ, and it is really an audit log: every message, every diff, preserved in order. Great for traceability. But it is a file sitting on disk, not something the model reads..aider.input.history— your past prompts, so the up-arrow key scrolls through earlier inputs even across sessions. Convenient for re-running a command. Not knowledge.- Convention files —
CONVENTIONS.md(or whatever you name it),.aider.conf.yml, and similar config. Once referenced via--reador your config file, your coding rules and project conventions travel with every request. This is persistent guidance, and the closest Aider comes to real memory. But it is static: you curate it by hand, and it never updates itself based on what happened in a session. - The repo itself — Aider commits its changes with sensible commit messages, so the git history records what was done. The code remembers; the reasoning behind the code does not.
What does not carry over
Now the part that bites. Close Aider on Monday, reopen it on Friday:
- The transcript file is not loaded into the new session. The model cannot see last week's conversation unless you explicitly feed it back in with
/reador paste it. - Nothing you taught Aider about your architecture, your constraints, or your rejected approaches survives. The decisions are gone; only the diffs remain.
- The conventions file does not learn. If you discovered a new rule on Tuesday, it is not in there until you add it yourself.
- There is no semantic recall. No "last time we tried X and it broke because of Y." No tracking of entities, no accumulated judgment.
This is the same shape as every other recurring-agent failure: the tool wakes up blind and you pay the re-briefing tax. You re-explain the stack, re-litigate decisions you thought were settled, and re-teach conventions you already taught it twice.
The manual options, honestly assessed
You can fight this with files, and plenty of Aider users do:
- Curate CONVENTIONS.md aggressively. Capture every durable rule the moment you discover it. This works, but it is manual labor, and the file goes stale the moment the project shifts.
/readthe chat history back in. Possible, and occasionally worth it for a gnarly debugging thread. The cost is tokens: you pay full price to re-read an entire transcript, most of which is irrelevant to the current task.- Keep a decisions log by hand. A
DECISIONS.mdyou update at the end of each session. Effective, and also a second job.
All three share one property: the memory system is you. The agent learns nothing; the human maintains the prosthesis.
What a real memory layer changes
The alternative is to give Aider somewhere to put what it learns, outside the model and outside the repo: a hosted memory layer it can read from and write to over MCP.
That is what Vilix AI is built for. It is cloud-hosted, so there is no database to run and nothing to maintain. It stores full conversation history, not just extracted facts, so the reasoning behind a decision survives alongside the decision itself. And because it connects over MCP, the same memory follows you across tools: Aider in the terminal, Claude Code in the editor, ChatGPT and Claude in the browser, Codex and Cursor when you switch contexts. One memory, every tool.
With a memory layer in place, the Friday session opens differently. The agent reads what it learned on Monday before it plans anything: the architecture, the constraints, the approaches that already failed, the conventions that are actually enforced. You start from the state of the world instead of from zero.
Vilix AI is free forever, with a 7-day Pro trial that needs no credit card, and you can export or delete everything at any time. The point is not to add another tool to maintain. It is to stop being your agent's external hard drive.
The bottom line
Aider remembers the way a filing cabinet remembers: the papers are all there, but nobody reads them unless you pull the drawer open yourself. The transcript, the conventions, the git log — these are evidence of past work, not memory of it. Real memory means the agent wakes up already knowing. Until your tooling does that on its own, give it a layer that does.