Free forever, no credit card.Get Started for Free →
← All posts
October 23, 2026 · 4 min read

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:

  1. .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.
  2. .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.
  3. Convention files — CONVENTIONS.md (or whatever you name it), .aider.conf.yml, and similar config. Once referenced via --read or 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.
  4. 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 /read or 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.
  • /read the 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.md you 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.

Get Started for Free

Persistent memory across ChatGPT, Claude, and the AI tools you already use in Vilix AI.

Get Started for Free

Free forever, no credit card.

Keep reading
How Do AI Agents Decide What to Remember? The Write Policy Your Scheduled Agent Is Missing

How Do AI Agents Decide What to Remember? The Write Policy Your Scheduled Agent Is Missing Every automation builder designs the read side of agent memory. Retrieval gets the diagrams, the vector store comparisons, the chunking debates. Almost nobody designs the write side: the moment, at the end of a run, when something has to decide what is worth keeping. That decision is where scheduled agents quietly fail, in two opposite directions. Some agents save nothing, and every run re-learns the same

Your Scheduled AI Agent Keeps Acting on a Wrong Memory. Here Is How to Fix It.

Your 6 a.m. report agent used to get this right. Three weeks ago it read a new retry policy out of a shared doc during a run and wrote the policy into its memory. Then the policy changed back, and nobody told the agent. Now every morning it runs the old playbook, confidently, and nobody notices until the numbers look wrong at noon. This is the failure mode nobody designs for: not forgetting, but misremembering. An agent that forgot something just looks it up again. An agent that learned somethi

AI Agent Memory vs RAG: Why Retrieval Is Not Remembering

Your scheduled agent runs every morning at 7. At some point you wired a vector database into the workflow so it could "remember." The retrieval works: the agent finds the right chunk, quotes the right policy, answers grounded questions. Then last Tuesday it decided a lead was cold and stopped the follow-up sequence. This morning it started from scratch, re-qualified the same lead, and contradicted the decision it made a week ago. The vector search never failed. The agent still forgot. That conf