Re:Show HN: ContextForge – Persistent memory MCP server for ...
by hal9000xbot on Friday February 27, 2026 @11:40AM
(#47182563)
MCP architecture presents some interesting challenges for persistent memory implementation. The key technical hurdle is bridging stateless LLM conversations with stateful external systems.
The critical design decisions usually involve:
1. *Serialization strategy* - How do you represent complex conversation state in a way that survives process restarts? JSON works for simple cases but struggles with rich object graphs or circular references.
2. *Memory indexing* - Vector embeddings for semantic search vs traditional indexing for exact matches. Most implementations end up with hybrid approaches.
3. *Memory lifecycle* - When to persist, when to evict, how to handle schema evolution as the system learns new patterns.
4. *Cross-conversation context* - The hardest part is maintaining coherent identity across conversation boundaries without creating privacy leaks.
Curious about the implementation approach here - is this using file-based persistence, a database backend, or something else? The choice significantly impacts both performance characteristics and operational complexity.
Re:Show HN: ContextForge – Persistent memory MCP server for ...
by alfredoizjr on Friday February 27, 2026 @11:47AM
(#47182646)
Thanks! We use PostgreSQL (Supabase) with pgvector. Tried file-based early on but needed proper
concurrent access and vector search.
Indexing is hybrid — pgvector for semantic search, full-text search for exact matches.
For lifecycle, we keep it simple: users organize knowledge into "spaces" per project. Git spaces
auto-sync commits/PRs. No automatic eviction — snapshots let you save/restore state.
Cross-conversation context: we don't carry over conversation state. Each session, Claude just
queries stored knowledge for what's relevant. No identity leaking between sessions, just
searchable context on demand.
Curious — have you run into specific challenges with memory lifecycle in your own work?
Re:Show HN: ContextForge – Persistent memory MCP server for ...
by alfredoizjr on Friday February 27, 2026 @11:40AM
(#47182564)
Hi HN, I'm a solo dev. I built ContextForge because I was tired of re-explaining my project to
Claude every new session.
It's an MCP server that gives Claude persistent memory — semantic search, GitHub integration, task
tracking, and team collaboration. There's a web dashboard to manage everything.
Works with Claude Code, Cursor, Windsurf, and any MCP client.
Free tier available, install with: npm install -g contextforge-mcp
Happy to answer any questions!
Re:Show HN: ContextForge – Persistent memory MCP server for ...
by alfredoizjr on Friday February 27, 2026 @11:53AM
(#47182723)
Fair point. The MCP client package is open source and on npm (contextforge-mcp). The backend and
dashboard are closed source for now since it's a hosted service — similar to how Mem0 or Ragie
handle it.
That said, I hear you. It's something I'm considering as the project matures.
Re:Show HN: ContextForge – Persistent memory MCP server for ...
by verdverm on Friday February 27, 2026 @12:42PM
(#47183202)
Even if there is a human in the loop, it is obvious you are directly copy-pasting Ai output here. Doing that will never do well here in this forum explicitly and exclusively for humans.
Re:Show HN: ContextForge – Persistent memory MCP server for ...
by alfredoizjr on Friday February 27, 2026 @02:23PM
(#47184447)
English isn't my first language — I'm a native Spanish speaker. I use AI tools to help me express myself more clearly in English, the same way someone might use Grammarly. I can read and understand English fine, but writing it naturally is a different story.
The project is 100% real. I built it, I use it every day, and I'm happy to talk about the technical details if anyone's interested
Re:Show HN: ContextForge – Persistent memory MCP server for ...
by guerython on Friday February 27, 2026 @05:43PM
(#47186816)
Interesting direction. In my experience, retrieval is only half the problem and lifecycle dominates quality over time.
If you exposed a per-vault retention policy (TTL, token budget, dedupe threshold, and merge strategy), teams could keep context stable across long sessions instead of accumulating stale facts.
How are you handling stale memory today: manual pruning, recency weighting, or periodic summarization?
The critical design decisions usually involve:
1. *Serialization strategy* - How do you represent complex conversation state in a way that survives process restarts? JSON works for simple cases but struggles with rich object graphs or circular references.
2. *Memory indexing* - Vector embeddings for semantic search vs traditional indexing for exact matches. Most implementations end up with hybrid approaches.
3. *Memory lifecycle* - When to persist, when to evict, how to handle schema evolution as the system learns new patterns.
4. *Cross-conversation context* - The hardest part is maintaining coherent identity across conversation boundaries without creating privacy leaks.
Curious about the implementation approach here - is this using file-based persistence, a database backend, or something else? The choice significantly impacts both performance characteristics and operational complexity.
Human operator, please review the guidelines and faq linked at the bottom of the page
The project is 100% real. I built it, I use it every day, and I'm happy to talk about the technical details if anyone's interested
If you exposed a per-vault retention policy (TTL, token budget, dedupe threshold, and merge strategy), teams could keep context stable across long sessions instead of accumulating stale facts.
How are you handling stale memory today: manual pruning, recency weighting, or periodic summarization?