You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
feat: local persistent memory with embedded vector store (no vendor lock-in) #14
Local, fully user-owned persistent memory using an embedded vector store — no cloud sync, no vendor lock-in, portable and private.
Motivation
ChatWise and Claude have memory features but they're tied to vendor backends. Jan has no memory. Users want the model to remember things across conversations (preferences, project context, past decisions) but they don't want that data leaving their machine or locked in a proprietary format.
Scope
Embedded vector store (sqlite-vss, LanceDB, or similar — ships with the app, no install required)
Auto-embed and index conversation summaries after each session
Manual "pin this to memory" action on any message
Memory viewer: browse, search, and delete stored entries
Inject relevant memories as context at conversation start (RAG-style)
Export all memories as JSON (full portability)
Memory is stored in user's app data directory, never transmitted
Notes
This is a strong privacy-first differentiator. The pitch: "Your AI remembers everything — and it all stays on your machine." Pairs well with local model support (Ollama) for a fully local stack.
Local storage and exportability solve ownership, but the automatic write path still needs a memory lifecycle. A session summary should not become active long-term memory merely because it was embedded successfully.
I would separate:
source/session summary;
candidate memory;
user-pinned or reviewed active memory;
generated vector index.
The vector store is a derived retrieval view and should be rebuildable from the inspectable records. The memory viewer should expose source session, creation method, confidence, scope, last confirmation, and any superseding item. Deletion should remove the active record and rebuild the derived index; export should include provenance and lifecycle state, not only text plus embedding metadata.
The manual "pin this" action is a good promotion gate. Automatic summaries can remain candidates until the user or a clear policy promotes them.
Activity
hegu-1 commentedon Jul 15, 2026
Local storage and exportability solve ownership, but the automatic write path still needs a memory lifecycle. A session summary should not become active long-term memory merely because it was embedded successfully.
I would separate:
The vector store is a derived retrieval view and should be rebuildable from the inspectable records. The memory viewer should expose source session, creation method, confidence, scope, last confirmation, and any superseding item. Deletion should remove the active record and rebuild the derived index; export should include provenance and lifecycle state, not only text plus embedding metadata.
The manual "pin this" action is a good promotion gate. Automatic summaries can remain candidates until the user or a clear policy promotes them.
This Continuity/Snapshot/Trace model is the distinction I am using between durable lines and raw history: https://github.com/hegu-1/personal-ai-os/blob/main/docs/continuity-snapshot-trace.md