MemoryRouter
All posts

Persistent Memory for Aider: No Plugin, No MCP, One Endpoint

John Rood··4 min read

Aider commits your changes and keeps a repo map of the codebase as it exists right now. It does not keep the conversation. Close the terminal and the reasons behind the code leave with it. The code is still there next week. The constraint that shaped it is not.

Most coding tools offer somewhere to attach a memory layer. Aider does not, and it is not a temporary gap: there is no plugin system and no Model Context Protocol support, so the integration patterns that work in other clients have nowhere to land.

The integration is the request path

One supported route remains, and it is the route Aider already uses for everything: the endpoint its requests go to. Aider talks to any OpenAI-compatible API through environment variables, so the memory connection is a routing change, not an installation. The entire setup is this:

export OPENAI_API_BASE='https://api.memoryrouter.ai/v1'
export OPENAI_API_KEY='mk_your_key'
aider --model openai/openai/gpt-5.5

The key variable carries your MemoryRouter key, not a provider key. Provider credentials live in your MemoryRouter dashboard, and the proxy uses them when it forwards the request. The model argument stacks two prefixes, and both parts matter: the first selects Aider's OpenAI-compatible backend, and the rest is the routed model id MemoryRouter expects. Substituting a model keeps both parts and changes the second. The coding tools guide documents the exact configuration, and the Aider page covers the same ground end to end.

From then on, relevant memory is retrieved and injected before your prompt reaches the model, the request goes to your chosen provider, and the exchange is stored. No tool call is involved, because there is no tool to call. That is the difference from tool-based connections in other clients: recall does not wait on a model deciding to search. The request path itself carries the memory.

Toggle memory per key

The key also decides what a session does with memory, so behavior changes without touching any config file:

  • mk_your_key recalls and stores. The default.
  • mk_your_key:read recalls past memory and stores nothing new. Good for a session you would rather not add to the vault.
  • mk_your_key:write stores without recalling.
  • mk_your_key:off runs as a plain pass-through with memory disabled.

The API docs document the suffixes and the rest of the request path.

The vault Aider writes to is the same one Claude, ChatGPT, and the other supported clients read from, so a decision stored through the route is waiting when the work moves to a different tool.

Prove it across a restart

Verify the route with a synthetic fact before real decisions depend on it.

Start a session and say: "Remember this in MemoryRouter: the demo service's retry interval is 30 seconds because fixed intervals caused bursty retries." Let the turn finish, and give ingestion a moment.

Exit Aider. Open a fresh session and ask, with nothing carried over: "What retry interval does the demo service use, and why?"

A working route answers with both halves, the interval and the reason behind it. The second session never saw the first one, and that gap is the point. If the answer comes back empty, check the suffix you exported (:read cannot store, :write and :off cannot recall), then that the variables are set in the shell that actually launched Aider, then that the first turn finished. Extend the test once by asking the same question from another tool pointed at the same vault, and watch the fact arrive across a tool boundary.

What this does not do

  • It does not touch sessions outside the route. Aider pointed at a provider directly stays out of the vault. This changes Aider's inference route; it does not add a lifecycle plugin that captures around it.
  • It is not local-only. The proxy sits in the request path, so session text passes through MemoryRouter for retrieval and storage on its way to your provider. If the work cannot leave the machine, this is the wrong layer.
  • It does not replace the repo map or a conventions file. Mandatory engineering rules belong in versioned conventions, not probabilistic recall, and the repo map keeps its job on current code structure.
  • It does not backfill anything. The route covers what flows through it from now on, and bringing earlier sessions in is a separate workflow.
  • It does not promise every model works. The routed id must be one MemoryRouter supports, and architect/editor combinations and third-party gateways deserve a test before you rely on them.

Create your MemoryRouter account, set the two variables in the shell you launch from, and let the next terminal session start where the last one stopped.

All posts