Launched this week
Memmy Agent
Let every AI remember the same you.
924 followers
Let every AI remember the same you.
924 followers
🍙 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.
Triforce Todos
Been waiting for something like this, honestly.
BTW, does it work well with Claude Code specifically, or is that still early days?
Memmy Agent
@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.
Memmy Agent
@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.
Memmy Agent
@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.
Memmy Agent
@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.
Memmy Agent
@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
Memmy Agent
@abod_rehman @zolani_matebese huge thks ♥️
Memmy Agent
@abod_rehman @zolani_matebese 🌹🌹🌹🌹
Memmy Agent
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 🫶🏻
Memmy Agent
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
Memmy Agent
@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!
Memmy Agent
@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.
Memmy Agent
@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!
Memmy Agent
@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 🙌
Memmy Agent
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.
Memmy Agent
@zhiqi_xu Go Go Go
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)?
Memmy Agent
@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.
Memmy Agent
@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.
Memmy Agent
@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.
Memmy Agent
@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.
Memmy Agent
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.”
Does commercial use of the GitHub version have any licensing restrictions that companies should know about?
Memmy Agent
@sky_heartfly Memmy is MIT-licensed, so yes, commercial use is allowed. You’re free to use, modify, and distribute it, as long as you keep the original copyright and license notice. No extra commercial restrictions from us.
Memmy Agent
@sky_heartflyMemmy is MIT-licensed, so yes, commercial use is allowed. You’re free to use, modify, and distribute it, as long as you keep the original copyright and license notice. No extra commercial restrictions from us. As usual with open source, third-party dependencies keep their own licenses — worth a quick check if your company has a compliance process. Happy to clarify further!
@sky_heartfly The MIT answer you got is correct, and there is a second question underneath yours that matters more for a company.
MIT covers the code. It says nothing about where your data goes. For a memory layer that is the part legal will actually ask about, because the whole product is a store of everything your team has said to its tools. Self-hosted from the repo and the hosted version with free tokens are very different answers to that question, even though both sit under the same licence.
The other thing the makers flagged themselves: third-party dependencies keep their own licences. That is the bit that trips people up. A permissive top-level licence with a copyleft dependency buried three levels down is a real situation, and it only surfaces during diligence when it is expensive.
If your company has any review process, running a dependency licence scan on the repo takes minutes and answers the question properly rather than by assumption.
Memmy Agent
@sky_heartfly @rabnoor_s Great add — you’re right that MIT answers the code question, not the data question.
For the GitHub / self-hosted path: memory stays local by default (SQLite on the machine). Scanning and ingestion don’t upload your memory store. If you use account-mode free tokens, model calls still go through the model provider like any BYOK/API setup — that’s separate from where the memory database lives. There’s also an optional memory-improvement toggle in privacy settings; it’s off unless you turn it on.
And yes on dependencies: a license scan on the repo is the right company diligence step. Appreciate you spelling that out for folks reading this thread.
Memmy Agent
@sky_heartfly Quick add: the top-level GitHub license is MIT, so commercial use is fine as long as you keep the copyright and license notice. Third-party dependencies still keep their own licenses, so a dependency scan is the safe move for company diligence.
If your team wants a cleaner commercial path — deployment help, compliance questions, or working directly with us as the vendor — happy to talk. Ping us anytime.
local-first with no cloud is exactly why i clicked too, but what happens on a new machine? does the memory pool migrate somehow or does a laptop swap just reset you to zero. that tradeoff between local-only and continuity feels like the real design fork here
Memmy Agent
@sabber_ahamed Yep, that’s the real tradeoff. There’s no automatic cloud sync today, so a brand-new machine won’t magically have your memory.
The memory pool is a local SQLite database, though, and you can export it and move it over. So a laptop swap only resets you if you leave the local store behind.
Right now it’s portable, but not seamlessly synced — the user controls the move.
Memmy Agent
@sabber_ahamed Exactly this tradeoff. Curious — for you, is “I move the DB myself” fine for now, or is seamless sync a must-have before you’d trust it day to day?
Memmy Agent
@sabber_ahamed Yeah, that’s the real fork. For now we bias local control + manual export/import; whether seamless sync should come next is exactly the feedback we want 🙌
Memmy Agent
That’s exactly the tradeoff. Local-first is great for privacy and control, but continuity cannot depend on one laptop forever.
The ideal model is user-controlled portability: encrypted export/import or an end-to-end encrypted sync option, where the user—not the platform—controls the memory pool and its keys. A new machine should be able to restore continuity without turning “local-first” into “we silently keep your memory in the cloud.”
Otherwise, a hardware refresh becomes an accidental memory wipe, which is too high a price for privacy.
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?
Memmy Agent
@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!
Memmy Agent
@quantumwhisker reaaaally thks a lot 🙏
Memmy Agent
@yunn_chen @quantumwhisker Thanks so much — really appreciate you following along.
Memmy Agent
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.
Memmy Agent
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.
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?
Memmy Agent
@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
Memmy Agent
@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?