I open sourced IronMem: persistent memory for AI coding assistants
AI coding tools are great inside a session and terrible across sessions.
That is the problem IronMem exists to solve.
You make progress with Claude Code, Cursor, Copilot, or Windsurf. You figure something out. You refactor a messy part of the codebase. You finally isolate the bug. You make a few important architecture decisions.
Then the session ends.
The next time you open a fresh session, the assistant starts from zero again.
It does not know what you changed yesterday.
It does not know what already failed.
It does not know which trade-offs you already made.
It does not know the path you took to get where you are.
So you do the same thing most people using AI coding tools do right now: you rebuild context by hand.
You paste notes.
You rewrite the same explanation.
You try to compress an entire debugging trail into a few paragraphs.
You waste momentum at exactly the point where you should be moving fastest.
IronMem is my attempt to fix that handoff.
What IronMem does
IronMem gives AI coding tools persistent memory across sessions.
It records session activity, compresses it into concise memory, and injects that context into the next session automatically.
The goal is simple: when you come back, your assistant should not feel like it has amnesia.
A few design choices mattered a lot to me:
- local-first
- SQLite storage
- no telemetry
- plain markdown output
- single Rust binary
- works across Claude Code, Cursor, Copilot, and Windsurf
I did not want this to become a giant hosted platform, a dashboard-heavy product, or another abstraction layer that creates more work than it saves.
I wanted something focused.
One job.
Done well.
Why local-first matters
A lot of developer tooling gets worse the moment it tries to become a cloud service for everything.
For something this close to the coding workflow, I think local-first is the right default.
It is simpler.
It is easier to trust.
It keeps the failure modes clearer.
It avoids turning a workflow primitive into another account, another sync system, and another place your context lives.
IronMem stores memory locally in SQLite and generates plain markdown context for the next session.
That also means it is not trapped inside one product surface.
Why not just use CLAUDE.md?
CLAUDE.md is useful for static guidance.
It is good for project rules, coding conventions, and instructions that do not change often.
But static guidance is not the same thing as session memory.
Static guidance does not tell the assistant what changed yesterday.
It does not capture the debugging trail.
It does not summarize the last hour of real work.
IronMem is not a replacement for static project context.
It is the missing dynamic layer beside it.
What I think is missing in AI coding right now
A lot of attention goes to bigger context windows, better reasoning, and better tool use.
Those things matter.
But one of the biggest workflow problems is much more ordinary: continuity.
A tool can be excellent inside a session and still feel broken across sessions.
That session boundary is where a lot of momentum gets lost.
That is the gap I wanted to close.
Open source now
I open sourced IronMem because I think this problem is real, obvious, and worth solving in public.
If you use AI coding tools heavily, I would love feedback on a few things:
- what should persist
- what should never persist
- where the current memory feels useful
- where it becomes noise
- how you would want this to fit into your workflow
Repo:
https://github.com/BMC-INC/Iron-mem
If it looks useful, star it.
If it looks wrong, tell me why.
That is the point of open sourcing it.
#execlayer✈️ #IronMem🧠