Memoriki: Persistent Memory Layer for Claude Code

This two-line setup creates a persistent memory layer for Claude Code that survives session restarts. Memoriki merges Andrej Karpathy’s LLM Wiki pattern with the MemPalace MCP server, giving Claude both structured knowledge compilation and semantic search capabilities.

Overview

Claude Code sessions typically start from scratch. A CLAUDE.md file provides some continuity, but decisions made during development, architectural explorations, and discovered patterns vanish when the session ends. Memoriki addresses this by implementing two complementary memory systems.

The first layer uses the LLM Wiki pattern. Raw materials - documentation, meeting notes, code snippets, research papers - go into a designated folder. Claude reads these sources and generates wiki pages with [[wiki-links]], YAML frontmatter, and structured indexes. Knowledge gets compiled once rather than re-derived from scratch during each query, similar to how Obsidian organizes notes but with the LLM handling the writing.

The second layer adds MemPalace MCP, which provides semantic search across 856 text chunks with embeddings, a knowledge graph connecting entities through typed relationships, and an agent diary where Claude records session summaries. When a new session begins, Claude reads previous diary entries to restore context.

Installation

Clone the repository from https://github.com/AyanbekDos/memoriki.git and run the standard Node.js installation:

Configuration requires adding the MCP server to Claude’s settings. The repository includes setup instructions for connecting MemPalace to Claude Desktop or Claude Code. The wiki folder structure needs initialization - create directories for sources, entities, concepts, and the generated index.

Point the source directory at existing documentation, notes, or any text-based materials relevant to ongoing projects. Claude will process these during the first session to build the initial wiki structure.

Usage Examples

Testing reveals how the combined system outperforms either component alone. When searching for information about tools used in a project, three approaches show different strengths:

Using grep against wiki files finds keyword matches but requires manually opening five or six files to assemble a complete answer. The wiki provides structure but lacks semantic understanding.

MemPalace search without the wiki returns semantically similar text chunks - it understands meaning rather than just matching words. However, results come back as raw fragments without the organizational structure the wiki provides.

The combined system queries the knowledge graph for entities tagged as “tools,” retrieves their wiki pages for context, and uses semantic search to find related usage examples. Results arrive structured and complete.

The agent diary creates continuity across sessions. After working on a feature, Claude writes a diary entry summarizing architectural decisions, unresolved questions, and next steps. The following session begins with Claude reading recent diary entries, effectively remembering the project state.

Limitations

Memoriki requires manual maintenance. The wiki doesn’t auto-update when source materials change - developers must trigger regeneration or update pages manually. This works well for relatively stable documentation but becomes tedious with rapidly changing codebases.

The 856-chunk embedding limit means large projects may exceed capacity. Expanding this requires modifying MemPalace configuration and potentially managing multiple memory instances for different project areas.

Semantic search quality depends on embedding model selection. The default configuration works for general technical content, but specialized domains might benefit from fine-tuned embeddings. Switching models requires rebuilding the entire chunk database.

Knowledge graph queries need careful relationship modeling. The system creates connections based on how information appears in source materials and wiki pages, but these relationships may not capture implicit domain knowledge. Teams should review and refine the graph structure as it develops.

Session diary entries accumulate over time. Without periodic summarization or archival, reading the complete diary history adds latency to session startup. Implementing a rolling summary system helps manage this growth.