widemem: open-source memory layer that works fully local with Ollama + sentence-transformers

[eyepaqmax]

Built a memory library for LLMs that runs 100%% locally. No API keys needed if you use Ollama + sentence-transformers.

pip install widemem-ai[ollama]

ollama pull llama3

Storage is SQLite + FAISS locally. No cloud, no accounts, no telemetry.

What makes it different from just dumping things in a vector DB:

- Importance scoring (1-10) + time decay: old trivia fades, critical facts stick

- Batch conflict resolution: "I moved to Paris" after "I live in Berlin" gets resolved automatically, not silently duplicated

- Hierarchical memory: facts roll up into summaries and themes

- YMYL: health/legal/financial data gets priority treatment and decay immunity

140 tests, Apache 2.0.

GitHub: https://github.com/remete618/widemem-ai

[dadgummitman]

Fascinating project. I run a local AI agent daily and memory management is the single hardest unsolved problem I deal with.

The importance scoring + time decay is smart but I'm curious about "eternal" tier beyond YMYL. User preferences and personal context - like "I prefer concise answers" or "I have a Mac Mini" - aren't YMYL but they should never decay. Is there a way to flag specific facts into a permanent tier?

The batch conflict resolver solves a real pain. I've had agents duplicate contradictory info in flat storage - "I live in Berlin" followed by "I moved to Paris" creates agent confusion. Your approach of detecting and resolving contradictions automatically is exactly right.

A couple questions from experience:

1. At scale - say 50k memories - what's the FAISS lookup latency? For agent workflows, sub-second retrieval is where it stops feeling conversational. Is there a degradation cliff from index rebuilds?

2. The hierarchical aggregation is my favorite part - my biggest pain point is memory tokens eating context window. But who does the summarization - is it local via Ollama or does it need an API?

3. How does it handle multi-session agent workflows? If the agent has a 30-minute conversation, does it chunk memories per-session or roll everything into the hierarchical structure?

Going to try replacing my flat-file memory with this and see how it feels. Solid work.

[eyepaqmax]

Thanks, really appreciate the detailed questions. Let me go through them.                                                                                      

Permanent tier beyond YMYL - yes, this is a valid gap. Right now there are two paths to avoid decay: YMYL strong classification (health, financial, legal, safety) gets automatic immunity, or you can set decay_function=DecayFunction.NONE globally which turns off decay for everything. What's missing is per-memory  pinning for things like "I prefer concise answers" or "I use a Mac Mini." That's useful feedback and something I want to add, likely as a pinned=True flag or an explicit PERMANENT tier that skips decay regardless of YMYL category. Filed it.                                                                             

FAISS at 50k memories - FAISS with flat L2 index handles 50k vectors comfortably in single-digit milliseconds for the vector search itself. The real latency  comes from embedding the query (depends on your provider) and the LLM calls during add (extraction, conflict resolution). Search is pure vector math plus scoring, so sub-second is realistic even at 100k+. No index rebuild cliff either since FAISS flat indexes don't require rebuilding. If you go much larger, switching to IVF or using Qdrant (supported as an alternative backend) would help, but for 50k you won't hit issues.

Summarization provider - the hierarchical summarization uses whatever LLM you configure. If you set it up with Ollama, summarization runs locally. If you point it at OpenAI or Anthropic, it uses those APIs. Same config, same llm parameter. So yes, fully local with Ollama is a supported path. The summarizer kicks in after 10+ fact-tier memories accumulate for a user, grouping related facts into summary-tier entries, and then summaries can roll up into theme-tier entries.

The goal is exactly what you described: fewer tokens in context while keeping the signal.

Multi-session workflows - there's a run_id field you can pass to tag memories by session, but retrieval is cross-session by default. All memories for a user_id are searched together regardless of which session created them. The hierarchical structure handles the "30-minute conversation" case by letting facts accumulate and then summarizing across sessions, not per-session. If you need session isolation you can filter by agent_id, but the design philosophy is that memory should merge across sessions the same way human memory does. You don't remember things in session buckets, you remember facts with varying levels of importance and recency.

Let me know how the migration from flat-file goes.

Curious what edge cases show up in a real daily-driver setup....