Aider Memory: Persistent Context Across Sessions for AI Pair Programming

Aider is one of the most capable AI coding tools available — and one of the most underrated. It runs entirely in your terminal. It works with any editor you already use. It auto-commits with descriptive messages, so your git history actually reflects what happened. And it supports every major model: GPT-4, Claude, Gemini, and more. You're not locked to a provider.

If you do serious development in the terminal, Aider fits the workflow in a way that GUI-first tools don't. It respects how you already work.

But every time you start a new Aider session, it doesn't know who you are, what you're building, or what you worked on yesterday. You start from zero.

What resets at the end of every session

The reset isn't just inconvenient. It erases things that took real time to establish:

• Project decisions. Why you chose this architecture. What alternatives you ruled out and why. What constraints shaped the current structure.
• Debugging history. The three approaches you tried before finding the fix. The root cause of that intermittent failure. The workaround that actually holds.
• Coding conventions. How you like errors handled in this project. The patterns you've settled on. The things that aren't in a linter config.
• What you've already explained. Every session, you re-establish context that Aider had yesterday.

Over weeks of a project, this adds up. Each session begins with re-explanation before it can begin with work.

What Aider gives you natively

Aider has two built-in mechanisms for maintaining context across sessions. Both are worth using.

.aider.conf.yml is a project-level config file that Aider loads automatically. You can set your preferred model, specify files to read by default, configure behavior — and crucially, specify a conventions file to load into every session with read: CONVENTIONS.md. This is the right place for stable configuration.

CONVENTIONS.md (or whatever you name it) is a plain text file you load into each session via --read CONVENTIONS.md or the read: option in your config. It's a briefing document: your project's tech choices, patterns you've standardized on, anything that's worth stating once and reading repeatedly. Aider marks it as read-only and caches it when prompt caching is enabled, which helps with both cost and latency.

If you haven't set these up, you should. They're genuinely useful starting points.

Where static files run into their limits

The gap isn't with .aider.conf.yml or CONVENTIONS.md as tools — it's with what static documents can hold.

They capture the project as you imagined it at the start. They don't capture the project as it evolved through six weeks of real debugging, unexpected constraints, and decisions made under pressure. You have to update them manually. In practice, they drift.

They also don't have search. When you come back to a problem you've seen before — a similar authentication edge case, a familiar class of race condition — there's no way to surface relevant past work automatically. You either remember it was written down and know where to look, or you don't.

And they're per-project. The debugging pattern you worked out in one repo doesn't carry forward when you start the next one.

These are constraints of the approach, not reasons to abandon it. Use CONVENTIONS.md. But understand what it can and can't hold.

The MemNexus approach: CLI-based memory for Aider sessions

Aider doesn't currently have native MCP client support — it can't consume external tool servers the way Cursor or Claude Code can. But the core workflow is straightforward, and it fits naturally into the terminal-first way Aider developers already work.

The pattern is simple: before a session, pull relevant context. After a session, save what matters.

Before starting an Aider session:

# Pull context for the project you're about to work on
mx memories search --query "auth service decisions" --brief

# Or get a full digest if you're resuming after time away
mx memories digest --query "payment API" --digest-format structured

After a session, save what you learned:

# Save an architectural decision with its reasoning
mx memories create \
  --conversation-id "NEW" \
  --content "Chose connection pooling over per-request connections in the auth service.
Peak load was overwhelming the DB. Pool size 10 per pod, validated under load testing.
Docs: see PR #112." \
  --topics "in-progress"

# Save a debugging finding
mx memories create \
  --conversation-id "conv_abc123" \
  --content "Intermittent 401s traced to clock skew between pods. JWT exp validation
was failing when pod clocks drifted by more than 2 seconds. Fix: NTP sync enforced
in k8s node config. Commit: a3f9d1b." \
  --topics "completed"

The CLI is designed for this kind of terminal workflow. Commands complete in under a second. You can run them as naturally as a git commit.

You can also prime Aider directly

Because Aider supports the --message flag and reads from stdin, you can feed memory context into the start of a session programmatically. Before you open Aider, run a search and paste the results into your initial prompt — or pipe them in directly.

# Generate a context briefing, then start Aider
mx memories search --query "checkout flow" --brief > /tmp/context.txt
aider --read /tmp/context.txt src/checkout/

This is a lightweight way to warm up an Aider session with relevant history before you type your first instruction.

What persists across sessions

With MemNexus in the loop, Aider sessions build on each other:

Architectural decisions with reasoning. Not just "we use Redis for caching" but "we chose Redis over Memcached because of sorted set support for the leaderboard feature." The reasoning matters. A year from now, when you're staring at that code wondering why, the answer exists.

Debugging investigations. That two-session investigation into flaky tests becomes a saved memory. When similar symptoms appear later, you can surface what you already found — in this project or another.

Coding conventions with context. Why does every endpoint return a typed Result instead of throwing? There was a decision. MemNexus holds it, with the reasoning intact.

Cross-project learning. The hard-won pattern from one project doesn't stay siloed there. When you start the next project, that history is available.

The compound effect

The value isn't obvious in the first session. It builds over weeks.

After a month of active work, your memory store reflects the actual trajectory of the project — not the idealized version in your README, but the real one: the tricky parts, the non-obvious constraints, the decisions that diverged from the original plan. Each Aider session starts with access to that history.

You stop re-explaining. You stop re-discovering. The things you've already worked out stay worked out.

For a broader look at how all AI coding assistants handle the session-reset problem — and why it's an architectural constraint rather than a product flaw — see How AI Coding Assistants Forget Everything (and Why That's a Hard Problem).

Using a different AI coding tool?

The same persistent memory approach works across the ecosystem:

• How to Give Cursor Persistent Memory Across Sessions
• How to Give Windsurf Persistent Memory Across Sessions
• Cline AI Memory: Persistent Context Across Sessions in VS Code
• VS Code AI Memory: Persistent Context with Continue and MCP

---

MemNexus is currently in invite-only preview. If you want your Aider sessions to build on each other instead of starting over, request access at memnexus.ai/waitlist.