Memmy Agent - Let every AI remember the same you.
🍙 Memmy Agent is a personal memory hub and local AI agent for all AI Agent and tools like Claude Code, Codex, OpenClaw and Hermes. Gives every AI one shared, full-controlled memory — they all remember the same you.
Memmy turns chats, decisions, prefs, progresses, and experiences into long-term memory, brings the right context into matching task, also can take on work directly.
Local-first by default. Your memory stay under your control: manage them anytime. Free start with 2M ChatGPT tokens.
Replies
Hey Product Hunters 👋
I'm Zhiqi, one of the makers behind Memmy.
If you bounce between Cursor, Claude Code, Codex, and other AI tools like me, you know the pain: every new chat starts from zero. Prefs, decisions, project context — you HAVE TO re-explain to them again and again.
Finally we get rid of it, and we're excited to introduce Memmy 🍙
Memmy is a local-first memory layer those tools can share. Auth once, and it turns messy chat history into structured memory — prefs, decisions, project context. Switch tools, and Memmy carries what matters with you. No re-explaining anymore. You can search it, control who uses it, or delete anytime. And it stays on your device, never uploaded to a remote server.
Also an agent itself: you can hand it tasks, not just manage memories.
We're open source, free to start, and would love to hear your thought — "What tool should we support next, and what should memory never forget?"
We gonna be here all day to answer questions and would genuinely appreciate your feedback 🫶🏻
Thanks for checking us out 🙏
→ https://memmy.bot
For the PH Community, 2M ChatGPT Luna tokens free credit, come get it 😎
@zhiqi_xu GitHub next! Would be great if Memmy could remember what we’ve already tried, so every new agent doesn’t send us down the same dead ends again
@zhiqi_xu @luke_pioneero Yes, exactly 😄 The real win is when the next agent says, “We already tried that — don’t go there again.” GitHub sounds like the perfect next test. Keep us posted!
@luke_pioneero Love this — and you’re pointing at the core job. Memmy can already connect to GitHub as a tool, but the bigger win is shared failure memory: when an approach dead-ends, we capture that trail and distill avoidance guidance, so the next agent (Cursor, Claude Code, etc.) can skip the same rabbit hole. Exactly the loop we want to keep strengthening. Thanks for the push!
@zhiqi_xu Notion would be a great next integration. A lot of project context and decisions already live there, so connecting that knowledge with AI conversations could be really powerful. Memmy should never forget confirmed decisions, but it should also know when they’ve been replaced by newer ones.
@jody_l_wyatt Great suggestion! Memmy can already connect to Notion as an Agent tool, so it can pull project context into conversations today.
On the memory side, we distill experience into four layers and keep evolving them over time: newer, higher-value memories rise, outdated ones decay or get archived. Confirmed decisions stick, but fresher ones can take priority when the context changes.
Turning Notion into a deeper living knowledge source for that loop is a natural next step — appreciate the push!
@zhiqi_xu @jody_l_wyatt Notion is such a natural fit — already usable as a tool for pulling project context in; making it a deeper living source for the memory loop is the exciting next step 🙌
Absolutely. Notion is where a lot of the durable project context already lives—PRDs, meeting notes, decisions, and changing priorities—so it’s a natural next integration.
The key is not just importing that knowledge, but preserving its lifecycle: which decisions are confirmed, what evidence supports them, and when a newer decision has superseded an older one. “Never forget” should not mean “never update.” It should mean retaining the decision history while making the current source of truth unambiguous.
@zhiqi_xu Go Go Go
@zhiqi_xu are there plans to expand this to cloud host MCP server? I have this exact situation but the problem occurs mostly between my cloud and local agents; not between multiple local agents. For example, I would love to be able to use "/memmy-resume" with cloud agent services (like a slack agent, or cloud hosted Hermes or OpenClaw on different machines, for example).
@zhiqi_xu @curtastrophe this is a very real gap in the current setup. Memmy works best when the agent can reach the same local memory service, so cloud ↔ local handoffs are still awkward.
A hosted MCP or optional remote memory endpoint would make the setup you described possible. We haven’t locked the design or timeline yet, but we’re going to evaluate it seriously — especially around auth, isolation, and keeping remote storage optional rather than replacing local-first.
The Slack + hosted Hermes/OpenClaw example is a really useful concrete case. Which one would you want to connect first? And would really appreciate your upvote if this direction clicks.
Been waiting for something like this, honestly.
BTW, does it work well with Claude Code specifically, or is that still early days?
@abod_rehman
Yes—Claude Code is one of the key workflows Memmy is designed for. It helps preserve the project context, decisions, and task progress that can otherwise get lost when you start a new Claude Code session, switch projects, or move between tools.
The cross-agent long-term-memory experience is still evolving, but if Claude Code is already part of your daily workflow, Memmy is well worth trying—especially for long-running development work, frequent session switching, or workflows that also involve Codex or Cursor.
@abod_rehman Claude Code is a big one for us too, so I’d be really curious to hear how it works on your actual setup. Let us know where the handoff still feels rough.
@abod_rehman Thanks — glad it’s landing. Claude Code is a first-class integration (not early days): memmy auto-recalls + captures memory each turn during your chat within Claude.
@abod_rehman jumping on your question because the answers in this thread don't quite line up. The four-layer split is the most interesting thing in this launch — L2 policies crystallising into reusable Skills is the step most memory tools skip entirely, so I want this to work.
But on "does it work with Claude Code" I count three different confidence levels from three makers in this one thread: "the cross-agent long-term-memory experience is still evolving", "one of the key workflows Memmy is designed for", and "first-class, not early days". Not a gotcha — I know launch day is chaotic and you're all answering in parallel. It just makes it hard to know what I'm signing up for.
Concretely, the thing that would settle it: on a fresh Claude Code session in an existing project, what does Memmy inject on turn one before I've typed anything? L3 world model only, or L2 preferences too? And is that budgeted to a token ceiling, or does it grow with the project?
Context I didn't ask for and can't see is the thing that makes me switch memory tools back off. Being able to answer that clearly would be a real differentiator.
@abod_rehman @rabnoor_s 🙏 Fair call — the three replies used different maturity labels, and we should’ve answered with the actual behavior instead.
In a fresh Claude Code session, Memmy doesn’t preload any retrieved memory before you type. After the first non-empty prompt, the UserPromptSubmit hook calls turns/start and adds the selected memories to that turn through additionalContext. The Stop hook captures the completed turn afterward.
It’s not L3-only. Memmy classifies the prompt first: normal tasks can retrieve from Skill, L2, L1, and L3; explicit memory-recall requests use Skill, L2, and L1; chitchat and Memmy meta commands skip retrieval. Ranking and the final LLM filter decide what actually gets injected.
There isn’t a hard total token ceiling today. Injection is bounded by retrieval limits and per-item truncation, so it doesn’t grow with the size of the project. In Memory Management → Logs, you can see the candidates, what got filtered out, and what was ultimately injected.
So the precise answer is: the Claude Code integration is live and automatic. We just should’ve described it this way the first time. Thanks for pushing us to be specific.🥹
@abod_rehman @yunn_chen This is a much better answer than the one I asked for, thank you.
The classification step is the part I did not expect, and it is the right call. Skipping retrieval entirely on chitchat and meta commands is what keeps a memory layer from becoming a tax on every keystroke.
One follow up on the ceiling, since that is the bit I would actually hit. "Bounded by retrieval limits and per item truncation" is a real bound, but it is an emergent one. Two projects with very different memory densities can both sit inside those limits and still inject wildly different amounts. What I would want is a number I set, not a number I discover. Even a soft budget with a log line saying what got dropped to fit would change how much I trust it on a long running session.
Possibly the same question from another angle: does the UserPromptSubmit hook add measurable latency to first token on every turn, or is retrieval fast enough that it disappears into the model call?
And genuinely, thanks for engaging with the pushback instead of defending the copy. That is rarer than it should be.
@abod_rehman @rabnoor_s Right on the ceiling. Today it’s still an emergent bound, not a number you can set. The Logs show what was considered, filtered, and ultimately injected, but we don’t yet have a user-defined token budget with a clear “dropped to fit” trace.
On latency, we’ve measured it. With the current local SQLite backend, retrieval averages around 3 seconds in our tests, and it gets slower as the memory pool grows. So yes, that delay sits directly on the path to first token.
In an internal hosted deployment using a higher-performance database, we’ve seen that drop to around 300ms. That hosted option isn’t available internationally today, so I don’t want to imply it’s something you can turn on right now. We are planning an optional hosted database path for Memmy, but today the actual experience is still local-first with SQLite and its current performance tradeoff.
That tradeoff should be explicit: local storage gives you control, but larger memory pools currently add latency. Thanks for pushing us to put real numbers on it.
@abod_rehman Congrats on the launch Abod and team
@abod_rehman @zolani_matebese huge thks ♥️
@abod_rehman @zolani_matebese 🌹🌹🌹🌹
Love the pitch! How do you handle conflict resolution when a user exhibits different personalities or prompt styles on different tools? (e.g., coding on Cursor vs. creative writing on Claude)?
@spark_zhang We don’t treat everything as one flat, global personality profile.
Memmy retrieves memories based on the current task and context, so coding preferences from Cursor and writing preferences from Claude can remain relevant in their own scenarios instead of constantly overriding each other.
For genuinely conflicting memories, we’re still improving the resolution and user-control layer, but the core principle is contextual relevance rather than blindly merging everything into one profile.
@spark_zhang Great question! Shared memory doesn’t mean one voice everywhere. Memmy keeps your durable facts shared, while tool-specific styles stay tied to their context — coding habits surface in Cursor, creative tone in Claude. The current task decides what gets recalled.
@spark_zhang I’d add: durable facts can be shared across tools, but style/persona should follow the current task — not get mashed into one universal voice 👍
@spark_zhang Spark, your question is the one that decides whether a shared memory layer is useful or actively harmful, and I think the answer you got is right but only for the easy half.
Retrieving by task context handles style. Coding preferences surface in Cursor, writing preferences surface in Claude, and they stay out of each other's way. Fine.
The half that is harder is when the two contexts hold contradictory facts rather than contradictory styles. You decide something while writing that quietly invalidates a decision you made while coding. Neither context knows about the other, both memories look valid, and retrieval by relevance will happily serve whichever one matches the current prompt better.
Style conflicts produce a slightly odd tone. Fact conflicts produce confidently wrong work, and you do not find out until later.
Grace mentioned decision repair records and a conflict layer they are still improving. That is the piece I would watch, more than the personality question.
@spark_zhang @rabnoor_s You’re right — style vs fact conflicts are different problems. Style can mostly follow task context; contradictory decisions across tools are the dangerous ones.
Today, when Memmy gets an explicit correction / clear failure signal, it can create a decision-repair record and update derived guidance, while keeping the original trace for provenance.
What we don’t claim yet is automatically detecting silent fact conflicts across agents with no user signal. That’s the harder layer we’re still hardening — happy to dig into a concrete example if you have one.
Absolutely—this is the real failure mode to solve.
Context-aware retrieval is enough for preferences and style, but not for decisions that affect shared reality. A memory layer needs to track decisions with scope, provenance, and supersession—not just retrieve the most relevant statement.
When a new decision conflicts with an earlier one, the system should surface the conflict explicitly, ask for resolution when needed, and write a repair record that says what changed, why, and which prior assumption is no longer valid.
Otherwise, you get exactly the dangerous behavior you describe: two internally coherent contexts producing confident but incompatible work. That’s much more important than whether every tool shares the same “personality.”
Memmy is a long-term memory assistant for individuals and developers, built to break down the memory silos created when working across AI coding agents such as Cursor, Claude Code, and Codex.
It consolidates historical conversations, task progress, and key decisions from multiple agents. Powered by the memory capabilities of MemOS, Memmy turns fragmented context into persistent, searchable, updatable, and reusable long-term memory. This means that when you switch tools, start a new session, or hand work off to another agent, your project context does not have to start from scratch.
Memmy is especially useful for:
Developers and teams using multiple coding agents;
Engineers who want to preserve architectural decisions, technical investigations, and debugging history;
Users who want AI to continuously understand their preferences, workflows, and long-running goals;
Teams exploring long-running agents, multi-agent collaboration, and AI-native development workflows.
In one sentence: Memmy helps AI go beyond remembering a single conversation—it helps AI continue your work with persistent context.
GitHub: https://github.com/MemTensor/memmy-agent
@zongyue Welcome everyone to try it out!
Interesting idea, you have my upvote. What are the current limitations?
@martin_yochev1 Thanks for the upvote! A few honest limitations right now:
Desktop is macOS / Windows — Linux desktop isn’t there yet (CLI/from source can still work on Node).
Local-first — memory lives on your machine by default; multi-device sync isn’t a built-in cloud product yet.
Free trial tokens are limited — great for getting started; heavier daily use usually means switching to BYOK.
If you hit a specific workflow limit, tell us — that’s the best way we prioritize.
@martin_yochev1 Appreciate the upvote! Those are the main current limits — if a specific workflow is blocked for you, shout and we’ll prioritize from real usage 🙌
Thank you for the upvote! The main limitations today are around the parts we’re still actively refining: more granular memory spaces, per-agent access controls, and richer conflict handling when newer decisions replace older ones.
For now, separate Memmy instances are the safest way to keep unrelated contexts isolated. We’d also love for you to try the TUI—it’s already quite capable, and we put a lot of care into making the interface feel friendly and fun to use. Feedback from real workflows would be incredibly helpful.
@hannesh
Thanks! Yes.
Once Claude Code and Codex both have the Memmy hooks installed, they read and write the same local memory store. When a turn finishes on one side, it gets captured automatically; the next time you ask something on the other side, relevant memory can be recalled. It’s not separate silos per agent, and it’s not cloud push between them.
The key is that both sides need Memmy’s live integration. If you only scan history and don’t install the hooks, new conversations won’t share automatically.
@hannesh Anytime — feel free to ping if anything else comes up~
This is awesome. I think the whole community been waiting for something like this.
BTW does it work with any AI tool already??? Like Antigravity, Grok build, etc...
@tuliosousapro Yep — both Antigravity and Grok Build can use Memmy through the CLI. They can run local shell commands, so they’re able to search, read, and write the Memmy memory pool with memmy-memory.
They’re not native one-click integrations yet, though, so automatic recall and capture would need some extra Skill or Hook setup. The built-in integrations just have that wiring done already.
Which one are you using more?
@yunn_chen I am using more Antigravity right now.
@tuliosousapro Quick add: if a tool can run local commands, you can usually hook into Memmy via CLI first — native one-click support is what we’re expanding next ✨
@tuliosousapro Yep — CLI gets you in now; native one-click is what we’re growing. Excited for you to try it with whichever you already live in!
Are decisions, preferences, project state, and lessons stored as different memory types with separate update rules?
Does the OpenAI-compatible API provide a way to inspect the memories used for each response?
@jun_wong2
Yes. Memmy uses a four-layer memory architecture, and each layer has its own write path, evolution pipeline, and retrieval rules:
L1 Trace — Raw conversation turns (requests, replies, tool calls). Captured automatically at turn end, then summarized and embedded asynchronously.
L2 Policy — Experiences distilled from L1 (success patterns, preferences, failure avoidance). Generated automatically by background induction jobs.
L3 World Model — Declarative knowledge about projects, environments, and constraints. Abstracted from L2 via clustering.
Skill — Reusable standard operating procedures. Crystallized from qualified L2 policies.
Mapping to the concepts you mentioned:
Decisions → L1 + decision repair records + L2 decision guidance
Preferences → L2 subtype `preference`
Project state → L3 world models
Lessons → L2 policies, which can further crystallize into Skills
The OpenAI-compatible API response body does not currently return memory IDs or citation details directly.
You can check this in Memmy under Memory Management → Logs by filtering for `memory_search`. There you’ll see the candidate memories for that request, which ones were kept and injected into context, and which ones were filtered out.
Our full stack is open source — feel free to take a look if you’re interested. Thanks for the support!
https://github.com/MemTensor/memmy-agent?ref=producthunt
@jun_wong2 The logs are especially useful when you’re tuning retrieval — you can see what was considered, kept, and filtered out instead of guessing what happened behind the scenes.
We’ve also been thinking about exposing more of that trace directly through the API. Curious what would be most useful for you there: memory IDs, relevance scores, or full provenance?
This solves one of the most frustrating parts of using multiple AI tools: having to explain the same preferences and project context over and over again. A shared memory layer feels like a missing piece in the AI stack. Congrats on the launch!
@sandy_liusy Thanks so much, Sandy! You nailed the exact problem we’re solving — repeating the same preferences and project context across tools is such a drag. We built Memmy as that shared memory layer so every AI you use can remember the same you.
Appreciate the kind words, and congrats energy right back — would love to hear how it feels once you try it!
@zhiqi_xu Thanks so much! I’m excited to try Memmy. Having one consistent memory across different AI tools would make switching between them so much easier. Congrats again on the launch 🙌
@sandy_liusy You’re so welcome! Can’t wait for you to try it. That’s exactly the feeling we’re going for: switch tools, keep the same you ✨ Would love any feedback once you’re in. 🙌
@sandy_liusy Yep, once you notice the context-reset problem, it’s hard to unsee... What tools are you switching between most?
@yunn_chen Mostly ChatGPT and Claude. I use them for research, writing, and building, so I often end up repeating the same background and preferences. That’s why Memmy caught my attention!
@sandy_liusy got it, we r also excited to hear more about your typically user experience to help mommy get better! Pls be free to try and feedback
@yunn_chen @sandy_liusy ChatGPT + Claude is such a classic split — research/writing/building, same context on repeat. Memmy’s built for exactly that hop 🙌
@sandy_liusy Excited for you to try it — hope switching tools finally stops feeling like starting over ✨
oh this is a very clever one. AI not remembering anything about me when i switch (even between claude web and claude code, for example,.. same company...) is one of the most frustrating things I've dealt with.
Do you also have any ideas on how to make memory "better", i.e. have it be more comprehensive?
@quantumwhisker Totally agree. We don’t think “better memory” simply means storing more conversations.
For us, it comes down to three things: covering more of the tools you already use, turning raw conversations into structured and deduplicated memories, and retrieving the right memory for the current task. New decisions and lessons can also be written back, so the memory keeps improving as you work.
The goal is a useful, evolving memory—not an infinitely growing chat archive.
@yunn_chen very interesting. I'll be sure to follow your product's development!
@quantumwhisker reaaaally thks a lot 🙏
@yunn_chen @quantumwhisker Thanks so much — really appreciate you following along.
Thank you — that frustration is exactly what makes cross-tool memory feel so important.
I think “better” memory is less about storing everything and more about remembering the right things well: durable preferences, confirmed decisions, active goals, and the reasoning behind them. Each memory should also carry context—where it came from, which project it applies to, how confident it is, and whether it has been superseded.
The other half is user control: easy ways to review, correct, pin, or delete memories. Comprehensive memory without curation quickly becomes noisy; useful memory should stay current, scoped, and explainable.
Thank you — that frustration is exactly what makes cross-tool memory feel so important.
I think “better” memory is less about storing everything and more about remembering the right things well: durable preferences, confirmed decisions, active goals, and the reasoning behind them. Each memory should also carry context—where it came from, which project it applies to, how confident it is, and whether it has been superseded.
The other half is user control: easy ways to review, correct, pin, or delete memories. Comprehensive memory without curation quickly becomes noisy; useful memory should stay current, scoped, and explainable.