Recall — open MCP memory pattern that survives across Cursor sessions

Showcase Built for Cursor
,
1

Sharing something I’ve been running with Cursor for a few months that solved
a real annoyance for me — the morning context-reset problem.

The setup: a small MCP server (~600 lines, Python) that gives Cursor a
persistent “brain” it can write to and read from across sessions. Plus a
tiered file-memory convention so routing rules and preferences auto-load
on cold start, while detailed reference material stays on-demand.

Why I bothered: every morning I was losing 20-40 minutes re-explaining
the same project context to Cursor. With this, the agent walks in already
knowing what we worked on yesterday, what we tried, what worked. It’s not
magic — it’s just a project log the agent writes to and reads from
deliberately.

What you get:

  • MCP server (compose file, runs locally or in any container host)
  • A tiered /memories/ convention you wire into your agent customization
  • Cold-start protocol: ~3 KB brief that pulls everything else on demand
  • Brand stamp + audit trail discipline (this part is convention, not
    enforced — gap I’m honest about)

Six pillars total documented in the whitepaper. MIT licensed.

Site (whitepaper, architecture, hardware reality, comparison): https://www.recall.works/
Repo: https://github.com/RecallWorks/Recall

Curious if anyone here has solved the cross-session memory problem
differently — I haven’t seen many open patterns for it that aren’t
locked into a SaaS.

Is anyone else tired of re-explaining who you are every time you switch between GPT, Claude, Cursor, etc.?
3

I am building an extension for Cursor (VibeRaven) around that second layer: local repo scan, stack map, launch gaps, and next prompt for the coding agent. It is less “memory” and more “current production-readiness snapshot.”

5

This resonates — the morning re-explain tax was exactly what pushed us to build something here too (piia-engram). We landed on a slightly different answer to your “solved differently” question: the axis that mattered most for us wasn’t surviving across sessions, it was surviving across tools. I bounce between Cursor, Claude Code, and Codex in a day, and memory that lives inside one client’s convention doesn’t follow me to the next — so the context loss just moves from “new session” to “new tool.”

So we kept the store completely outside any client: one folder of plain JSON/Markdown the user owns, that any MCP client points at. Same cold-start idea as your ~3 KB brief — a small resume brief loads first, heavier material on demand — but because the folder isn’t tied to Cursor, the same brief comes up in Claude Code or Codex unchanged.

The “not locked into a SaaS” point is the part I’d double down on: once memory is a local file the user owns rather than a service, tool-portability basically falls out for free. Did you consider making Recall’s /memories/ convention client-agnostic, or was staying Cursor-native a deliberate scope call?