Alternatives
Products that do what Memoriki – LLM Wiki+MemPalace for persistent personal knowledge bases does
Memoriki is a template for building personal knowledge bases where the LLM does all the maintenance work. It combines Karpathy's LLM Wiki pattern (structured markdown wiki maintained by an LLM) with MemPalace (an MCP server that adds semantic search and a temporal knowledge graph). Three layers: - Wiki pages with [[wiki-links]] and YAML frontmatter - the LLM creates and maintains these - Semantic search via embeddings (ChromaDB) - find things by meaning, not keywords - Knowledge graph with typed relationships and date validity - "what changed since last month?" It's not RAG. RAG re-derives…
- 1
- 2AK
I shipped a wiki layer for AI agents that uses markdown + git as the source of truth, with a bleve (BM25) + SQLite index on top. No vector or graph db yet. It runs locally in ~/.wuphf/wiki/ and you can git clone it out if you want to take your knowledge with you. The shape is the one Karpathy has been circling for a while: an LLM-native knowledge substrate that agents both read from and write into, so context compounds across sessions rather than getting re-pasted every morning. Most implementations of that idea land on Postgres, pgvector, Neo4j, Kafka, and a dashboard. I…
Apr 2026 · github.com
- 3
- 4MA
2025 · gitea.bubbletea.dev
- 5
- 6
- 7
- 8MO
Hey HN! I'm Arindam, part of the team behind Memori (https://memori.gibsonai.com/). Memori adds a stateful memory engine to AI agents, enabling them to stay consistent, recall past work, and improve over time. With Memori, agents don’t lose track of multi-step workflows, repeat tool calls, or forget user preferences. Instead, they build up human-like memory that makes them more reliable and efficient across sessions. We’ve also put together demo apps (a personal diary assistant, a research agent, and a travel planner) so you can see memory in action. Current LLMs are stateless…
2025 · github.com
- 9
- 10CO
I keep running in the same problem of each AI app “remembers” me in its own silo. ChatGPT knows my project details, Cursor forgets them, Claude starts from zero… so I end up re-explaining myself dozens of times a day across these apps. The deeper problem 1. Not portable – context is vendor-locked; nothing travels across tools. 2. Not relational – most memory systems store only the latest fact (“sticky notes”) with no history or provenance. 3. Not yours – your AI memory is sensitive first-party data, yet you have no control over where it lives or how it’s queried. Demo video:…
2025 · github.com
- 11
- 12
- 13LW
Apr 2026 · llmwiki.app
- 14
- 15
- 16MA
Hey HN! I built Memoripy, a memory layer for AI that adds short-term, long-term, and semantic memory capabilities to enhance LLM applications. It helps AI systems retain and prioritize past interactions, adapt over time, and respond with greater context and personalization. Memoripy uses semantic clustering to retrieve relevant memories, along with adaptive memory decay and reinforcement, so interactions stay fresh and context-aware. It’s designed for easy integration with OpenAI, Ollama, and other platforms—giving your AI applications dynamic memory management with minimal setup. Would love…
2024 · github.com
- 17LA
Hi HN, Working with multiple projects, I got tired of re-explaining our complex multi-node system to LLMs. Documentation helped, but plain text is hard to search without indexing and doesn't work across projects. I built Linggen to solve this. My Workflow: I use the Linggen VS Code extension to "init my day." It calls the Linggen MCP to load memory instantly. Linggen indexes all my docs like it’s remembering them—it is awesome. One click loads the full architectural context, removing the "cold start" problem. The Tech: Local-First: Rust + LanceDB. Code and embeddings stay on your machine. No…
Dec 2025 · github.com
- 18ML
Jun 2026 · github.com
- 19CL
I have a proposal that addresses long-term memory problems for LLMs when new data arrives continuously (cheaply!). The program involves no code, but two Markdown files. For retrieval, there is a semantic filesystem that makes it easy for LLMs to search using shell commands. It is currently a scrappy v1, but it works better than anything I have tried. Curious for any feedback!
Apr 2026 · github.com
- 201B
Jun 2026 · llm-wiki.net
- 21BA
Hi HN, Erik here. Today we launch Butter, an OpenAI-compatible API proxy that caches LLM generations and serves them deterministically on revisit. Since April, we’ve been working on this concept of “muscle memory,” or deterministic replay, for agent systems performing automations. You may recall our first post in May, launching a python package called Muscle Mem: https://news.ycombinator.com/item?id=43988381 Since then, the product has evolved entirely, now taking the form of an LLM Proxy. For a deep dive into this process, check out:…
Oct 2025 · docs.butter.dev
- 22AA
We’re building Largemem, (https://largemem.com) a shared knowledge base where groups upload and maintain a common set of documents (PDFs, scans, audio) and query them conversationally. Each group has its own persistent knowledge base. We parse content into chunks, extract entities, and combine vector search with a lightweight knowledge graph, so answers can synthesize information across multiple documents and across the group’s shared context - not just retrieve isolated snippets. We would love to hear your feedback!
Dec 2025 · largemem.com
- 23
- 24AF
Hi HN, We’ve been building [memU](https://github.com/NevaMind-AI/memU), an open-source memory framework for AI agents that supports both classic RAG and LLM-based direct file reading. RAG has become the default in LLM systems, but many of its failures don’t come from the model — they come from the retrieval assumptions. Embedding-based retrieval is fundamentally an approximation over semantic similarity. It works well for fuzzy recall, but it often breaks when relevance ≠ correctness, which is common in real systems. From a retrieval perspective, RAG struggles with: -…
Jan 2026 · github.com
Ranked by how close each launch is in meaning, then by votes. Refine with a description →