The verdict up front

No — it is not “the most mature on the internet,” because there is no absolute most-mature; it depends on which problem you are solving. But placed against the 2026 open-source ecosystem, my system sits firmly in the top tier of self-built setups, with one strength almost no open-source project has: a single-source-of-truth architecture spanning 6 harnesses.

I also have to be honest: the industry is productizing this exact capability. The highest-starred project, claude-mem (93.5k stars, renamed Grok Mem), does what I built by hand — persistent context across Claude Code / Codex / Gemini / Hermes / Copilot / OpenCode / OpenClaw — except it is an off-the-shelf product, and mine is a craftsman’s build.

This article does three things: first, clarifies what layers my system is actually made of (answering a common confusion — is ECC my memory system?); then inventories it against the open-source memory landscape; finally gives 7 improvement suggestions.

1. Three layers, often conflated: native mechanism / my cross-harness layer / the ECC config layer

People (including me, at first) conflate these three. They are three distinct layers:

Layer one: Claude Code’s native file-memory mechanism. This is Anthropic’s built-in feature (official docs code.claude.com/docs/en/memory, confirmed this round via 3-vote adversarial verification). The mechanics: CLAUDE.md loads at session start across four scope layers (system / user ~/.claude/CLAUDE.md / project ./CLAUDE.md / local ./CLAUDE.local.md), concatenated (not overridden); @path/to/import recursive imports up to 4 hops; the auto-memory directory ~/.claude/projects/<project>/memory/ has MEMORY.md as an index, loading only the first 200 lines or 25KB (whichever comes first), with specific memory files read on demand. After /compact, the project-root CLAUDE.md is re-read from disk and re-injected.

This layer is the foundation; everyone (including me) stands on it.

Layer two: my self-built cross-harness shared architecture (designed 2026-07-24, iterated since). This is the real subject — “my memory system” — and I designed and built it myself. The core is single authoritative library + pointer access:

• The authoritative library = Claude Code’s memory directory; CC auto-loads its index every session at zero extra cost.
• Every other harness (Hermes / OpenClaw / Codex / Kimi / OpenCode) holds one pointer entry and reads the authoritative library on demand when it needs to recall (read MEMORY.md index first, then the relevant file).
• No bidirectional sync, no symlink — a decision I reached after empirical testing: Hermes’s MemoryStore has a 3500-character limit, and an atomic full-file rewrite after symlinking would truncate and corrupt the CC index; OpenClaw’s full-file rewrite trips a drift guard. So I chose “pointers” over “sync” — single source of truth, no conflicts, no staleness.

Layer three: the ECC config-management system. ECC is not a memory system; it is the “butler” that manages Claude Code configuration — the rules pack (~/.claude/rules/ecc/), managed files (auto-overwritten every Monday at 04:02), and an ecc-memory-vault MCP backend. It has one point of friction with my memory architecture: ECC-managed files (~/.codex/AGENTS.md, ~/.kimi-code/AGENTS.md) get overwritten by the weekly update, so I deliberately place cross-harness pointers in ~/.agents/AGENTS.md, which ECC cannot manage — on 2026-09-09 I migrated Kimi’s pointer there specifically to escape ECC’s overwrite.

In one sentence: I built the memory architecture; ECC is a side-channel config butler. They intersect but are not the same thing.

2. Auditing my system (measured numbers)

I had a sub-agent audit the memory directory; all numbers verified:

Note: the categories above sum to 507; another 15 index/non-standard files (MEMORY.md and miscellaneous ecc/github/blog prefixes) are uncategorized, totaling 522.

A few notes worth flagging: the largest file, project_lynxhouse, is 79KB, violating the “one fact per file” principle; 4 files lack a type field (index and non-standard files); there are no automated memory-write/extract hooks — it relies on the model’s discipline.

3. The landscape: five architectural schools

Sweeping the open-source projects (stars verified via authenticated GitHub API, 2026-09-10 snapshot), they cluster into five architectural patterns (3-vote verified; “which is best” has no public benchmark and is reasoned inference):

1. Pure file / Markdown (Claude Code CLAUDE.md, Cline .clinerules) — simplest, zero-dependency, git-friendly; but token bloat on large projects, content rots easily.
2. Pure vector DB (Memorizer’s pgvector, Phantom’s Qdrant) — strong semantic retrieval; but noisy without reranking.
3. Pure knowledge graph (relationship graph as the core store) — strong relationship expression, but query latency dominates without pruning. Memento’s Neo4j leans this way but also carries vectors, not a pure KG.
4. Embedded hybrid (codebase-memory-mcp’s SQLite+Nomic, graph-memory’s SQLite+LPA/PageRank, mcp-memory-keeper’s SQLite+KG+lightweight vectors) — balances performance with zero-dependency; highest share within this survey’s sample.
5. Cloud hybrid (mem0’s vector+BM25+entity linking, mcp-memory-service local-first ONNX + optional Cloudflare sync) — supports multi-device sync; but introduces external dependencies and privacy concerns.

Hybrid has the highest share within this survey’s sample, but no public benchmark proves a single approach wins at all project scales.

4. Key players

By positioning, in three tiers (stars are the 2026-09-10 authenticated snapshot):

Productized cross-harness (closest to my route)

• thedotmack/claude-mem (Grok Mem) — 93,580★: highest-starred in the field. Captures session → AI-compresses → injects into future sessions; spans CC/Codex/Gemini/Hermes/Copilot/OpenCode/OpenClaw. The productized version of my cross-harness idea.

General memory infrastructure

• mem0ai/mem0 — 65,009★: YC S24, Apache 2.0, vector+BM25+entity-linking hybrid; explicitly integrates CC/Codex/Cursor/Windsurf/OpenCode/OpenClaw.
• DeusData/codebase-memory-mcp — 42,782★: highest-starred among code-graph memory tools. Indexes the codebase into a persistent knowledge graph (SQLite WAL + built-in Nomic 768-dim embeddings, no Neo4j, no external vector DB), deeply integrated with CC (hooks + Scout/Verify/Auditor three-layer agents). I use this MCP myself — my ECC project has 48,168 nodes / 62,589 edges.
• getzep/graphiti — 30,736★: temporal knowledge graphs (arXiv paper), nodes/edges carry time, bi-temporal. Zep’s open-source core.
• topoteretes/cognee — 30,608★: self-hosted KG memory platform.
• supermemoryai/supermemory — 29,573★: memory + context engine, fast and scalable.
• oraios/serena — 29,099★: MCP semantic code-retrieval toolkit, with memories.
• letta-ai/letta (f.k.a. MemGPT) — 24,677★: OS-inspired memory hierarchy (core memory = RAM, archive = disk, self-editing), stateful agents.
• cline/cline — 67,746★: highest-starred within this section but no dedicated memory system — relies on .clinerules files loaded across CLI/VSCode/JetBrains.
• getzep/zep — 4,902★: managed agent memory (Graphiti-powered).

Claude-specific mid-tier (each with a trick)

• basicmachines-co/basic-memory — 3,908★: pure Markdown + wiki links + MCP knowledge graph — philosophically closest to mine.
• lucasrosati/claude-code-memory-setup — 969★: Obsidian Zettelkasten + Graphify code graph + chat import; claims 71.5× token savings.
• debugtheworldbot/msync — 54★: syncs CC memory to claude.ai / Claude App.
• Durafen/Claude-code-memory — 74★: Tree-sitter + Qdrant vectors + “Memory Guard” code-quality gate.
• kuitos/opencode-claude-memory — 59★: OpenCode plugin, CC Markdown-format-compatible, auto-dream consolidation (merge/prune/rewrite).
• WhenMoon-afk/claude-memory-mcp (Mooncite) — 68★: citation verification — recalls from local histories of various tools, mooncite_inspect verifies a citation still matches its source file (proves “the source is right,” not “the content is true”).
• mycelium-hq/ai-brain-starter — 36★: vault + hooks + bi-temporal rule lineage (every rule carries two clocks: written-time + last-verified-time) + weekly drift scan.
• hudrazine/claude-code-memory-bank — 41★: Cline Memory Bank methodology, hierarchical docs.
• LARIkoz/eidetic — 12★: Markdown + FTS5/vector hybrid, drift detection down-ranks stale memories, session-end auto-extraction, topic bases attached on demand.
• d2a8k3u/claude-code-memory — 7★: autonomous hook loop — searches memory before every prompt/edit/Bash, type-aware decay (patterns decay slowly / episodics fade fast), auto-merges ≥95%-similar duplicates, relation graph evolves with use.
• serkansmg/smg-claude-memory-mcp — 33★: DuckDB + embeddings, per-project isolation, team git sharing.
• nwiizo/ccat — 33★ (archived): CLAUDE.md context analyzer, import-chain diagnostics (circular deps / missing files / oversized contexts).

MCP memory servers

• doobidoo/mcp-memory-service — 1,933★: local-first — SQLite-vec + ONNX local embeddings, optional Cloudflare Vectorize/Milvus sync, actively maintained.
• ghostwright/Phantom — 1,467★: built on Claude Agent SDK, Qdrant + Ollama three-layer vectors.
• adoresever/graph-memory — 609★: DSH/OpenClaw plugin, SQLite + LPA community detection + PageRank.
• gannonh/memento-mcp — 424★: Neo4j unified graph+vector, but last push 2025-10, activity doubtful.
• petabridge/memorizer — 196★: .NET, PostgreSQL+pgvector.
• mkreyman/mcp-memory-keeper — 134★: SQLite + KG + character n-gram hash vectors (non-neural embeddings).

Grok’s gap analysis also flagged, but not deeply verified this round: continuedev/continue (~28k★), paul-gauthier/aider (~28k★, repo-map as implicit memory), microsoft/autogen (~22k★), langchain-ai/langgraph (~18k★), RooVet/RooCode (~1.4k★, built-in layered memory). These are the broader agent ecosystem, not dedicated memory systems.

5. My DIY system vs. the industry (one table)

My strengths: cross-harness single-source, provenance field, interconnect density, using the strongest code-graph MCP. My gaps: no auto-write, no drift detection, no semantic retrieval, no auto-consolidation.

6. Seven improvement suggestions

Each maps to a point where the industry does better; all are actionable:

1. Add a semantic/vector retrieval layer. My 522 files rely on [[links]] and keywords; recall precision degrades as scale grows. The most on-target option is eidetic’s FTS5+vector hybrid (designed for Markdown memory) or mem0’s vector+BM25+entity linking, adding a semantic-recall layer. context-mode already has FTS5; what’s missing is a cross-library semantic layer. (codebase-memory-mcp indexes the code graph; semantic retrieval over Markdown memory isn’t plug-and-play and needs adaptation or a different tool.)
2. Introduce drift detection / staleness auditing. Among 522 files there are surely stale memories. eidetic’s “detect-stale-then-down-rank” and mycelium’s bi-temporal clocks (written-time + last-verified-time) + weekly drift scan are ready-made templates. Add a periodic job scanning high-edit files for cumulative semantic drift.
3. Automate memory extraction + consolidation. I rely entirely on the model writing inline; if it forgets, the memory is lost. Add a Stop/SessionEnd hook: at session end, a small model extracts decisions/rules/lessons from the transcript into cards (eidetic and d2a8k3u both do this), plus periodic auto-dream to merge/prune/rewrite-dedupe.
4. Citation / verification mechanism. I have originSessionId but never verify whether a memory is still true. Borrow Mooncite: before citing a memory, verify it against ground truth (proves “the source is right,” not “the content is true”) — at minimum in research/blog scenarios that go public.
5. Index-scale governance. MEMORY.md is at 87% utilization (118/200 lines, ~21.7/25KB; beyond 25KB CC loads only the first 25KB and the rest is invisible). Mitigate with hierarchical indexes (sub-indexes per category) or semantic retrieval.
6. Atomize large files. project_lynxhouse at 79KB violates “one fact per file” and wastes tokens when the whole file is pulled into context on retrieval. Split into multiple small memories + index lines.
7. Productization decision: coexist or migrate? claude-mem (93.5k★) is the productized version of my cross-harness build. Decide: keep hand-building (full control, zero-dependency, privacy-local), or bring in claude-mem for the session-capture/compress/inject layer (saves manual work, but black-box, external dependency). My recommendation is coexist — keep my authoritative library for long-term memory, let claude-mem complement with session-level short-term context; two layers, each doing its job.

7. Honest limitations

This research has boundaries, stated here to avoid overconfidence:

• Star counts are a 2026-09-10 snapshot with normal fluctuation;
• Grok’s gap analysis flagged projects (continue/aider/autogen/langgraph/RooCode etc.) only to star count, not deeply verified for implementation;
• Anthropic has not released a native persistent-memory API or /recall, /checkpoint commands — Grok once claimed they exist (Claude Projects persistent memory API, Claude Code v2.3 checkpoint storage, 2M prompt caching); 3-vote adversarial verification found no trace in official docs, judged them hallucinations, and excluded them entirely — they are not in the conclusions above;
• This verification mainly covers the English-ecosystem projects; Chinese-community CLAUDE.md best-practice collections were not systematically covered;
• “Which architecture is best” is reasoned inference, with no public benchmark.

Conclusion

Placed against the 2026 open-source memory ecosystem, my system is not “the most mature” (no such absolute exists), but a solid top-tier self-built setup, whose unique value is the single-source-of-truth architecture spanning 6 harnesses — something even the highest-starred claude-mem pursues via a similar route, just productized. My gaps cluster in three directions: semantic retrieval, drift detection, auto-extraction/consolidation — precisely where eidetic / d2a8k3u / mycelium, the small projects, do best. Fill those three, and my DIY system moves from “top tier” one step closer to “self-evolving.”

Memory is not about having more; it is about self-maintaining better.

Method: local sub-agent audit + authenticated gh API star verification + a grok-deep-research workflow (5 parallel searches → fetch 29 sources → gap analysis → 3-vote adversarial verification of 25 claims → Chinese synthesis).