Open on ProductHunt

Agentmemory

Persistent memory for Claude Code, Codex & coding agents

Open SourceDeveloper ToolsArtificial IntelligenceGitHub
339votes44commentsLaunched 55d agoWebsite

By Rohit Ghumare

Claude-Zusammenfassung

Agentmemory ist eine Open-Source-Lösung, die KI-Coding-Agenten wie Claude Code oder Codex sitzungsübergreifendes Gedächtnis verleiht, indem vergangene Entscheidungen, Architekturmuster und Debug-Erkenntnisse komprimiert und abrufbar gespeichert werden. Der technische Kern ist eine drastische Token-Reduktion (laut Benchmark bis zu 92 %), was bedeutet, dass der Kontext länger nutzbar bleibt ohne Informationsverlust. Für jemanden, der KI-Tools in Workshops oder Beratungskontexten einsetzt, ist das nur begrenzt relevant – das Produkt zielt klar auf Entwickler mit wiederkehrenden Coding-Sessions, nicht auf gesprächsbasierte oder konzeptionelle Arbeitskontexte. Die Kommentare mischen echte Begeisterung von Early Adopters mit gezielter technischer Skepsis rund um Staleness-Probleme und Retrieval-Qualität – ein Zeichen, dass die Community das Produkt ernst nimmt, aber noch kritisch beobachtet.

About

You can now give Hermes, Claude Code, and Codex infinite memory. Agentmemory is trending on GitHub with 5,000+ Stars. CLAUDE md dumps 22,000+ tokens into context at 240 observations agentmemory: 1,900 tokens. same observations. 92% less. At 1,000 observations, 80% of your built-in memories become invisible. agentmemory keeps 100% searchable. benchmarked on 240 real coding sessions → Up to 95% fewer tokens per session → 200x more tool calls before hitting context limits → 100% open source

Top comments10 of 44

  • [REDACTED]·58d ago8

    Hey Product Hunt 👋

    I built AgentMemory because coding agents still have one painful limitation: they forget between sessions.

    • You explain your architecture once.

    • You debug a production issue once.

    • You decide on a library or pattern once.

    Then the next session starts from zero again.

    AgentMemory gives AI coding agents persistent memory across sessions, so they can actually build on what they’ve already learned about your codebase. It automatically captures what your agent does, compresses it into structured memories, indexes them with hybrid search, and injects the right context back into future sessions.

    It works with Claude Code, Cursor, Codex CLI, Gemini CLI, Windsurf, Kilo Code, OpenCode, Cline, Roo, Goose, Aider, Hermes, OpenClaw, and basically any MCP or REST-capable agent.

    From day one, I wanted it to be:

    • 100% open source

    • Free to run locally

    • No external database required

    • Works via MCP, REST, and simple hooks

    • Built for real coding workflows, not toy “chat history” memory

    On benchmarks, AgentMemory gets 95.2% R@5 and 98.6% R@10 on the LongMemEval-S retrieval suite using BM25 + vector search, while cutting context usage by around 92%.

    Quick start:

    Run: npx @agentmemory/agentmemory

    • Open: http://localhost:3113

    • Or try the demo: npx @agentmemory/agentmemory demo

    If you live in your coding agents every day, this is for the moment you think: “Wait, I already explained this yesterday.”

    Would love feedback from builders, heavy agent users, and open‑source maintainers.

    GitHub: https://github.com/rohitg00/agentmemory

  • [REDACTED]·54d ago4

    Persistent memory for coding agents is a harder problem than it sounds. You're not just storing conversation history, you're storing codebase context, decisions made, patterns established. The benchmark claim is what I'd want to dig into. Memory that's fast to write is useless if retrieval is noisy. How does it handle context that's become stale after a refactor?

  • [REDACTED]·54d ago2

    Congrats on the launch.

    2 questions:

    1. Will this impact more usage on tokens? since the agent need looking around and search on newer chats?

    2. Will the memory be persistent only in CLI agents or also on their desktop application as Codex, Claude, Cursor

  • [REDACTED]·54d ago2

    Really interesting, can it pick up past sessions or does it start only once i integrate? On another side note is there a way to not use an agentic db and maybe postgres?

    Great traction! I will give it a try on my current project and see if it brings down hallucination. I like the graph view so you can easily see whats going on.

    Just wondering how long did this take to make? The database side is very interesting and i think has a lot of potential to many other things. Good luck!

  • [REDACTED]·54d ago2

    Well done team! How do you detect when a stored memory contradicts current code state or is pruning still manual?

  • [REDACTED]·54d ago2

    well done @rohit_ghumare i'd love to know what's the business model you intend to persue? looks like everything is free and opensource. just wondering would u be making this a hobby project or building it seriously or something else?

  • [REDACTED]·54d ago2

    Wonderful project. Already used it locally with Claude Code and it provides an amazing developer experience. Absolutely love the underlying architecture powered by iii = very scalable. very efficient and hands down the best memory solution otu there

  • [REDACTED]·49d ago1

    Having trouble with large data sets. Just spent a few days stress-testing agentmemory on a real-world workload.


    Dataset: ~674 Claude Code sessions / ~370K observations / ~108 hand-curated memories, imported from 1.5 GB of jsonl history across 24 projects.

    Graph extracted to ~75K nodes / ~6K edges. All running locally with OpenRouter (Gemini 2.5 Flash Lite for LLM, OpenAI text-embedding-3-small for embeddings).

    Bugs hit, all confirmed as open GitHub issues:

    - #502 — Graph auto-trigger never fires on session end (the session.stopped topic has no publisher in shipped code)

    - #544 — /memories and /export endpoints return 500 on large corpus

    - #587/584 — Buffer pool corruption causing worker crash loops (filed today!)

    - #474 — agentmemory stop leaves iii engine running with stale function registrations

    - #538 — Viewer's "Rebuild Graph" button calls /graph/build which doesn't exist server-side

    - #455 — No dimension override means switching embedding models requires AGENTMEMORY_DROP_STALE_INDEX=true (which I learned the hard way actually persisted on every restart in my hacked-together approach)

    Workarounds I built: custom hourly LaunchAgent calling /agentmemory/graph/extract directly to compensate for #502; chunked batching (50 obs/request, file-based payload via --data-binary @file) for /graph/extract to avoid "Argument list too long"

    Net result: Sessions API + Memories tab work fine, live capture works, recall context injection works at session start (~1300 tokens of project history). The graph viz endpoint times out at our size and the worker crash loop makes things unstable when querying graph-heavy endpoints. LaunchAgent workarounds just caused more chaos, so reverted to started terminal frontend launch/operations to simplify. But the issues remain.

    Fortunately, even after wiping and starting over halfway through, the total OpenRouter spend across all this was only about ~$15. The concept and the architecture are solid; the scale-handling needs another iteration or two before it's production-stable for a real coding workflow. Watching the GitHub issues.

    Great work, excited to see this puppy land with the kinks worked out! Pausing usage until its a bit further along.

  • [REDACTED]·54d ago1

    The cross-session forgetting problem is real. The deeper one you'll hit at scale: when an agent makes a wrong call in week 4 because it remembered a misleading decision from week 1, where does ownership of that mistake sit? Two questions worth thinking about: 1. Can memory be exported in an open format so agents move with their user, not their runtime? 2. Is there a way to mark a memory entry as disputed or superseded? Without those, an agent's persistent memory becomes a liability dressed as a feature.

  • [REDACTED]·54d ago1

    Persistent memory across sessions is one of those things that sounds like a dev tool problem but actually changes how useful AI agents are in practice. Right now every session with Claude Code starts from scratch — re-explaining context, re-loading preferences. Curious how Agentmemory handles conflicts when the same context gets updated across sessions. Does it merge, overwrite, or flag it for review?