DEV Community: Paul Holland

Eidetic OS vs Mem0 vs Letta vs Khoj — Choosing an AI Memory Layer in 2026

Paul Holland — Thu, 11 Jun 2026 19:53:11 +0000

Full disclosure: I'm Paul Holland, the solo developer behind Eidetic OS. I built it because nothing else gave me what I wanted — local-first AI memory that I actually own and understand. This comparison is my honest attempt to map the landscape fairly. I'll tell you where the others are stronger, and where I think Eidetic wins.

The Problem: AI Has Amnesia

Every time you start a new chat with an LLM, it forgets everything. Your preferences, your project context, last week's conversation — gone. The industry has responded with a handful of "memory layer" tools, each taking a different approach to the problem.

If you're evaluating options in 2026, there are five worth looking at seriously: Eidetic OS, Mem0, Letta (formerly MemGPT), Khoj, and Nucleus MCP. They range from VC-funded cloud platforms to solo-dev open-source projects. Let's break them down.

The Contenders

Eidetic OS

What it is: An open-source, local-first AI memory operating system. Python CLI with 20+ subcommands.

Storage: SQLite + sqlite-vec. No external database dependencies.

Search: Hybrid retrieval combining BM25 lexical search with vector similarity, fused via Reciprocal Rank Fusion (RRF), then reranked with TF-IDF scoring.

Memory model: Three-tier architecture — Core, Recall, and Archival with exponential decay: P(M) = e^(-λt) * (1 + βf).

Verification: Five-tier GROUND-style pipeline. Ed25519 cryptographic signatures with SHA-256 hash chain.

Integrations: Obsidian vault sync, MCP skills, extension architecture. Works with local LLMs via LM Studio.

Mem0 ($24M funded)

Managed memory layer. Cloud-hosted, API-driven. Graph-based memory with entity extraction. Best for production SaaS apps.

Letta ($10M funded, formerly MemGPT)

Stateful AI agent framework with persistent memory. Powerful but complex. Best for agent orchestration.

Khoj (open-source)

Personal AI assistant with memory and search. Good UX, less technically extensible.

Nucleus MCP

MCP-based memory server. Clean architecture, newer and less mature.

Comparison Table

Feature	Eidetic OS	Mem0	Letta	Khoj	Nucleus MCP
Hosting	Local-first	Cloud	Cloud + self-hosted	Cloud + self-hosted	Local (MCP)
Pricing	Free / OSS	Freemium	Freemium	Free / OSS + cloud	Free / OSS
Storage	SQLite + sqlite-vec	Managed	Postgres + vector	Postgres / SQLite	SQLite
Search	BM25 + vector hybrid, RRF	Graph + vector	Vector + agent routing	Vector + keyword	Vector
Memory	3-tier with decay	Graph entities	Agent blocks	Flat docs	Key-value
Verification	5-tier + Ed25519	None	None	Basic	None
Best for	Local, hackable, auditable	Production SaaS	Stateful agents	Personal KM	MCP ecosystem

Where Each One Wins

Mem0 wins for production apps scaling memory across thousands of users.

Letta wins for full agent orchestration with memory as a component.

Khoj wins for personal AI with a polished interface.

Nucleus MCP wins on MCP ecosystem elegance.

Eidetic OS wins if you care about:

Privacy: Data never leaves your machine
Auditability: Ed25519 + SHA-256 hash chain
Retrieval quality: Hybrid BM25 + vector with RRF fusion
Memory realism: Exponential decay prevents stale context
Verification: Five-tier validation before content reaches your LLM
Hackability: Python CLI, no black boxes

The Honest Assessment

Eidetic OS is a solo project, not a venture-backed platform. But if you value understanding your own stack, want AI memory that respects your privacy, and believe verification and audit are features — not afterthoughts — then Eidetic OS was built for you.

Try It

pip install eidetic-os

GitHub: github.com/paulholland511/eidetic-os

Star the repo if you find it useful. Open an issue if you don't.

Paul Holland builds Eidetic OS. He believes AI memory should be local, verifiable, and yours.

From Personal Tool to Enterprise Platform: Where Eidetic OS Is Heading Next

Paul Holland — Sat, 06 Jun 2026 17:27:31 +0000

Six months ago I built a Python script that saved my Claude conversations to markdown files. Today it's a full personal AI operating system — 160+ skills, hybrid RAG search, pluggable vector backends, a web dashboard, fact extraction, memory decay scoring, and an Obsidian plugin. Here's the technical story of how each decision was made, what we tried, what failed, and where it's going next.

Why I Built This

I'm an IT operations manager. I use AI every day — architecture planning, debugging, code review, research. The problem: every conversation disappeared when I closed the tab. I'd spend an hour explaining my infrastructure to Claude, get great advice, then next session start from scratch.

I tried the obvious solutions first. Conversation history? Too noisy — full of corrections, tangents, tool output. Copy-pasting notes? Doesn't scale past a week. Third-party tools? Either cloud-dependent (privacy concern) or too basic.

So I built my own. The core thesis: your AI should remember everything and work while you sleep. Everything that followed was in service of that.

The Architecture Decisions (And Why)

┌──────────────────────────────────────────────────────────┐
│                      eidetic CLI                          │
│   init · doctor · search · embed · dashboard · skills     │
├──────────┬──────────┬───────────┬────────────────────────┤
│  Vault   │   RAG    │  Skills   │   LLM Backends         │
│  Markdown│  Hybrid  │  160+     │   LM Studio / Ollama   │
│  Git Sync│  BM25+Vec│  MCP      │   llama.cpp / OpenAI   │
├──────────┼──────────┼───────────┼────────────────────────┤
│  Fact    │ Security │  Vector   │   Dashboard            │
│  Extract │ AST Scan │  Backends │   Flask + D3.js        │
│  Memory  │ Sandbox  │  SQLite   │   7 Panels             │
│  Decay   │ Audit    │  LanceDB  │   Knowledge Graph      │
├──────────┴──────────┴───────────┴────────────────────────┤
│               Obsidian Markdown Vault                     │
│        (your files, your machine, git-versioned)          │
└──────────────────────────────────────────────────────────┘

Why Obsidian Markdown (Not a Database)

The first decision was storage format. I could have used SQLite from day one, or Postgres, or a purpose-built knowledge graph database. I chose plain markdown files in an Obsidian vault. Here's why:

Human-readable — I can open any file in a text editor and read it. No special tooling needed to inspect my memory.
Git-versioned — Every change is a commit. Free versioning, branching, diffing, conflict detection.
Portable — Move the folder to another machine and everything works. No database migrations, no server processes.
Obsidian-native — I already lived in Obsidian for personal notes. The vault is my knowledge base and my AI's memory. One source of truth.

The trade-off: markdown isn't searchable by meaning. That's where the RAG pipeline comes in.

Why Hybrid Search (BM25 + Vector + RRF + TF-IDF)

Pure vector search sounds elegant. Embed everything, find similar chunks, done. In practice it misses exact matches constantly. If I search for "sqlite-vec", embedding search returns results about "vector databases in general" but misses the specific chunk where I chose that library.

Pure keyword search (BM25) catches exact terms but misses conceptual connections. "What did we decide about the authentication approach?" won't find a chunk that talks about "JWT token validation strategy."

So we fuse both:

BM25 scores by term frequency (catches exact matches)
Vector cosine scores by semantic similarity (catches conceptual matches)
Reciprocal Rank Fusion merges both ranked lists with k=60 (prevents either method from dominating)
TF-IDF reranking refines the top results (boosts rare, query-specific terms)

Query: "What vector database did we choose?"
         │
         ├──► BM25 Keyword Search ──► chunks with "vector", "database"
         │
         ├──► Vector Cosine Search ──► chunks about "embedding storage"
         │
         ├──► Reciprocal Rank Fusion (k=60) ──► merged ranking
         │
         └──► TF-IDF Reranking ──► final top-N results

This was the single biggest quality improvement in the entire project. The jump from pure vector search to hybrid was immediately noticeable — suddenly the system could find both the exact library name and the reasoning behind choosing it.

Why SQLite-vec (Not Pinecone/Weaviate/Qdrant)

For a personal knowledge base with ~10K chunks, you don't need a vector database service. You need something that:

Requires zero configuration
Embeds in the Python process (no running server)
Has no cloud dependency
Is fast enough for KNN over 10K vectors

sqlite-vec does all of this. It's a SQLite extension. Your vectors live in the same database as your metadata. pip install and you're done.

We added LanceDB and ChromaDB as pluggable alternatives (swap with one config line) for anyone who outgrows SQLite. But for 99% of personal use, SQLite is the right answer.

Why Local LLMs (Not Just Cloud APIs)

Every embedding, every search, every analysis can run on your hardware. We auto-detect LM Studio, Ollama, and llama.cpp at startup. No API keys required.

This isn't ideological — it's practical. I work on planes. I work in environments where sending data to cloud APIs isn't an option. And for a system that stores your complete professional context, keeping embeddings local isn't a luxury, it's a requirement.

We also support OpenAI-compatible APIs for people who want cloud speed. But the system works fully offline by default.

Why Extensions (Not a Monolithic CLI)

By v2.0, the CLI was a 1,500-line monster. Trading commands, voice synthesis, job tracking — all in one file. Every user got every feature. Adding a module meant editing the core.

v3.0 ripped it apart into a pluggable extension system using setuptools entry-points:

pip install eidetic-os              # Core only
pip install eidetic-os[trading]     # + trading module
pip install eidetic-os[voice]       # + voice synthesis
pip install eidetic-os[vector]      # + LanceDB/ChromaDB

Each extension is an EideticExtension subclass that registers its own commands, skills, and schedules. If one extension fails to load, the rest keep working. This was essential for community contributions — nobody should have to understand the trading module to add a documentation tool.

Why AST Security Scanning (Not Just Sandboxing)

With 160+ community skills, someone will eventually write code that does something dangerous — intentionally or not. Sandboxing catches runtime problems (infinite loops, memory bombs, file access). But it doesn't catch intent.

The AST scanner reads the code's structure before execution:

BLOCK — os.system(), subprocess.call(), network access, file deletion. Hard-stopped, never executes.
WARN — Dynamic imports, eval/exec, broad file access. Logged, requires approval.
INFO — External library imports, vault file reads. Noted but allowed.

This is defense in depth. The scanner catches dangerous patterns before the sandbox even starts. Two independent layers, each with different detection strengths.

Why Fact Extraction (Not Raw Transcript Storage)

v1 through v3 stored raw session transcripts. Every conversation, verbatim. This caused two problems:

Context bloat — Conversations are full of noise. False starts, corrections, "actually wait, let me rethink that." Embedding all of this pollutes search results.
Redundancy — The same decision gets discussed across multiple sessions. You end up with five chunks saying the same thing in slightly different words.

v4.0 introduced Mem0-style fact extraction. Instead of storing "we discussed authentication and decided to use JWT tokens because...", the system extracts: "Paul chose JWT tokens for authentication (decided 2026-05-15, reason: stateless, no session DB needed)"

Each fact gets:

Cosine similarity comparison against existing facts
Duplicate detection — if the fact already exists, bump its access count
Contradiction handling — if the new fact contradicts an old one, supersede it (mark old as inactive)
Merge logic — if the new fact extends an old one, combine them

This reduced context bloat dramatically. The system stores decisions, not discussions.

Why Memory Decay (Not Permanent Storage)

Not all facts are equally relevant forever. "Paul prefers dark mode" is permanent. "The deploy target is staging-3" is temporary. Without decay, stale facts accumulate and pollute active reasoning.

The retention model: P(M) = e^(-λt) · (1 + βf)

λ = temporal decay rate
t = time since last access
f = access frequency
β = reinforcement coefficient

Frequently accessed facts stay hot. Old, unreinforced facts decay toward deactivation. The sleeptime daemon runs this scoring while you're offline, pruning stale context automatically.

Why Channel Adapters (Not Terminal-Only)

A personal AI OS that only works when you're at your desk is half a solution. The channel adapter framework lets you query your knowledge base from Slack or Telegram. The system runs as a local daemon, receives messages, routes them through RAG search, and sends back answers.

This was directly inspired by Letta's custom channels architecture. The key insight: decouple the intelligence from the interface. The same RAG pipeline serves the CLI, the dashboard, the Obsidian plugin, and messaging apps.

Where It's Going: v5.0

A competitive analysis against Letta ($10M funded), Mem0 ($24M Series A), and Nucleus MCP revealed two gaps between "personal tool" and "enterprise platform": verification and provenance.

The Trust Problem

When an AI agent executes code autonomously, the question isn't "can it do the task?" It's "can you prove it did the task correctly?"

In regulated industries — finance, healthcare, government — every autonomous action needs a tamper-evident audit trail. Our JSONL log captures everything, but anyone with filesystem access can modify it after the fact. And for code execution: we check for danger (AST scanning), but we don't verify correctness.

Structured Verification Gates (#29)

A 5-tier pipeline that runs before any autonomous execution:

SYNTAX — AST parse, catch errors before anything runs
IMPORTS — Verify dependencies resolve, cross-reference security block list
TESTS — If tests exist for the module, run them
RUNTIME — Execute in sandbox, capture output and resource usage
DIFF — Show what changed, flag unexpected modifications

Code/Skill ──► SYNTAX ──► IMPORTS ──► TESTS ──► RUNTIME ──► DIFF ──► ✅ Execute
                 │           │          │          │          │
                 ▼           ▼          ▼          ▼          ▼
              BLOCK?      BLOCK?     FAIL?     CRASH?    UNEXPECTED?
                 │           │          │          │          │
                 └───────────┴──────────┴──────────┴──────────┘
                                    │
                                 🛑 STOP

Each tier produces a typed result. Execution stops on the first BLOCK-level failure. Every result feeds into the audit trail.

Cryptographic Audit Signatures (#30)

Ed25519 signatures on every audit trail entry, with a SHA-256 hash chain linking each entry to the previous one. If any entry is modified after creation, the chain breaks and verification fails.

Entry 1          Entry 2          Entry 3
┌──────────┐    ┌──────────┐    ┌──────────┐
│ action   │    │ action   │    │ action   │
│ timestamp│    │ timestamp│    │ timestamp│
│ prev: ∅  │───►│ prev: h1 │───►│ prev: h2 │
│ sig: Ed25│    │ sig: Ed25│    │ sig: Ed25│
└──────────┘    └──────────┘    └──────────┘
   hash=h1         hash=h2         hash=h3

This turns the audit trail from "a log file" into "a cryptographic proof of execution history." Supports SOC2, EU DORA, and MAS TRM without any cloud service.

Tiered Memory (#31)

Moving from a flat vector store to Core (hot context) / Recall (recent cache) / Archival (cold storage). The agent decides what stays active vs. what gets archived, using memory decay scoring to make informed decisions.

Valkey Search (#32)

High-performance search backend for multi-user deployments where retrieval latency matters. Keeps SQLite-vec as the zero-config default for personal use.

The Philosophy

Every decision in Eidetic OS comes back to three principles:

Local-first — Your data never leaves your machine unless you explicitly send it somewhere
Human-readable — Every piece of state is inspectable in a text editor
Progressive complexity — Works with zero config out of the box, scales to enterprise with opt-in features

The AI agent space is moving fast. Letta and Mem0 have venture funding and full teams. What we have is a different philosophy: your AI's memory belongs to you, runs on your hardware, and produces verifiable proof of what it did.

pip install eidetic-os
eidetic init
eidetic doctor

GitHub: paulholland511/eidetic-os
PyPI: eidetic-os

v5.0 features are being built right now. Star the repo if you want to follow along.

This is the second post in my series on building Eidetic OS. The first post covers the full feature set and comparison tables.

Eidetic OS — How I Built a Personal AI Operating System That Never Forgets

Paul Holland — Fri, 05 Jun 2026 15:08:07 +0000

Every AI conversation I had vanished the moment I closed the tab. Weeks of research, planning sessions, decision context — gone. I'd spend an hour explaining my project structure, my coding preferences, my infrastructure setup — and the next session started from zero. So I built a system that fixes that permanently.

Eidetic OS (formerly Atlas OS) is an open-source personal AI operating system that wraps Claude Cowork and Claude Code with persistent memory, hybrid RAG search, 160+ installable skills, scheduled automation pipelines, a full web dashboard, and pluggable backends for both LLMs and vector databases. It turns a stateless chatbot into something that remembers everything, learns from every interaction, and works autonomously while you sleep.

Why "Eidetic"? The word means having perfect, photographic memory recall — the ability to remember everything you've ever seen or experienced with total clarity. That's exactly what this system does for your AI. We renamed from Atlas OS to avoid namespace collisions with the Windows debloater project (20.8K GitHub stars) and Fluidstack's bare-metal infrastructure OS. The old name buried us in search results. "Eidetic" is unique, memorable, and communicates exactly what the system does: your AI never forgets.

GitHub: paulholland511/atlas-os | pip install eidetic-os

The Problem: AI Amnesia

If you've spent any time with Claude, ChatGPT, or any conversational AI, you've hit this wall. You build up context over a long session — your project architecture, your preferences, your ongoing decisions — and then the conversation ends. Next time, you start from scratch.

Some tools try to solve this with conversation history. But raw conversation logs are a terrible memory format. They're full of false starts, corrections, tangents, and redundancy. Searching through thousands of lines of dialogue to find that one architectural decision you made three weeks ago? Painful.

I wanted something different: a system where every conversation automatically becomes part of a searchable, structured knowledge base. Where the AI can instantly recall not just what we discussed, but the decisions we made and why. Where background processes keep the knowledge fresh, indexed, and connected.

That's what Eidetic OS does.

The Architecture

┌──────────────────────────────────────────────────────────┐
│                      eidetic CLI                          │
│   init · doctor · search · embed · dashboard · skills     │
├──────────┬──────────┬───────────┬────────────────────────┤
│  Vault   │   RAG    │  Skills   │   LLM Backends         │
│  Parser  │  Engine  │  160+     │   LM Studio            │
│  Git Sync│  SQLite  │  Market-  │   Ollama               │
│  Session │  BM25+Vec│  place    │   llama.cpp            │
│  Capture │  RRF     │  MCP      │   OpenAI-compatible    │
│  Locking │  Rerank  │  Registry │   Auto-detect          │
├──────────┼──────────┼───────────┼────────────────────────┤
│  Exten-  │ Security │  Vector   │   Dashboard            │
│  sions   │ AST Scan │  Backends │   Flask + D3.js        │
│  Plug-   │ Sandbox  │  SQLite   │   7 Panels             │
│  gable   │ Audit    │  LanceDB  │   Knowledge Graph      │
│  Fault-  │ Trail    │  ChromaDB │   Real-time Stats      │
│  tolerant│ JSONL    │  Abstract │   Dark Theme           │
├──────────┴──────────┴───────────┴────────────────────────┤
│               Obsidian Markdown Vault                     │
│        (your files, your machine, git-versioned)          │
└──────────────────────────────────────────────────────────┘

The entire system is local-first. Your notes, embeddings, and knowledge graph never leave your machine. The "database" is a folder of markdown files with YAML frontmatter. History is plain git — every change is a commit. Everything is diffable, portable, and yours.

How It Works: The Memory Pipeline

Step 1: Session Capture

Every Claude Cowork conversation gets saved as a structured markdown note in your Obsidian vault. This happens automatically, twice daily via scheduled tasks. Each captured session includes a summary of what was discussed, key decisions and action items, files that were created or modified, code snippets and commands that were run, and YAML frontmatter with timestamps, tags, and metadata.

The capture process strips noise — repeated prompts, error messages, verbose tool output — and preserves signal. The result is a clean, readable note that you can browse in Obsidian like any other document.

Step 2: Semantic Chunking & Embedding

Raw markdown files aren't searchable by meaning. So the RAG pipeline breaks every document into semantically coherent chunks — not by fixed character count (which splits mid-sentence), but by detecting topic boundaries using heading structure, paragraph breaks, and content similarity.

Each chunk gets an embedding vector (via your local LLM or any OpenAI-compatible endpoint), a BM25 term frequency index, TF-IDF weights for reranking, and metadata linking back to the source file, heading, and position.

The embedding runs incrementally. Changed files get re-chunked and re-embedded. Unchanged files are skipped. A full vault re-embed of ~2,000 files takes about 15 minutes on a local LM Studio instance with Nomic embeddings; incremental updates take seconds.

Step 3: Hybrid Search with Reciprocal Rank Fusion

This is the core of the RAG engine, and the single biggest quality improvement I made:

Query: "What vector database did we choose and why?"
         │
         ├──► BM25 Keyword Search
         │    Scores every chunk by exact term frequency
         │    Finds: chunks containing "vector", "database", "choose"
         │
         ├──► Vector Cosine Search (sqlite-vec)
         │    Finds semantically similar chunks
         │    Finds: chunks about "embedding storage decisions"
         │
         ├──► Reciprocal Rank Fusion (RRF)
         │    Merges both ranked lists with k=60
         │    Prevents either method from dominating
         │
         └──► TF-IDF Reranking
              Refines the top-N results
              Boosts chunks with rare, query-specific terms

Why not just use embeddings? Because pure vector search misses exact matches. If you search for "sqlite-vec", embedding search might return results about "vector databases" in general but miss the specific chunk where you named the library. BM25 catches those exact hits. The fusion ensures you get both precision and recall.

Step 4: Knowledge Graph

Entity relationships are extracted from your vault and stored as a directed graph. People, projects, technologies, and decisions become nodes; their interactions become edges. The dashboard renders this as a D3.js force-directed graph, letting you visually explore how concepts connect across your knowledge base.

The Extension Architecture (v3.0)

In v3.0, I ripped apart the monolithic CLI and rebuilt it as a pluggable extension system.

The Problem

The original cli.py was a 1,500-line monster. Trading commands, voice synthesis, job tracking — all tangled together. Every user got every feature whether they wanted it or not.

The Solution

Every feature module is now an extension — a self-contained Python package that registers itself via setuptools entry-points:

from eidetic_os.extensions.base import EideticExtension

class TradingExtension(EideticExtension):
    name = "trading"

    def register_commands(self, app):
        @app.command()
        def trade_report():
            """Generate a trading analysis report."""
            # Your trading logic here

    def register_skills(self):
        return ["crypto-analysis", "market-briefing"]

    def register_schedules(self):
        return [{"name": "morning-briefing", "cron": "0 7 * * *"}]

Install only what you need:

pip install eidetic-os              # Core system
pip install eidetic-os[trading]     # + trading extension
pip install eidetic-os[voice]       # + voice synthesis
pip install eidetic-os[vector]      # + LanceDB/ChromaDB backends

MCP Skills: Every Skill Is a Server

The Model Context Protocol (MCP) is how modern AI tools communicate. In Eidetic OS, every skill in the marketplace automatically becomes an MCP server.

Drop a SKILL.md into a directory — it describes what the skill does, its parameters, and its execution logic. The MCP skill wrapper reads the markdown, generates a JSON-RPC tool definition, and serves it over stdio or HTTP transport. Any MCP-compatible client can discover and invoke it.

eidetic skills list                              # List available skills
eidetic skills run security-audit --target ./app # Run a skill
eidetic mcp serve                                # Start the MCP server

The marketplace currently has 160+ skills spanning security auditing, DevOps automation, frontend/backend engineering, data analysis, document generation, and business tasks.

Security: Because Autonomous Code Execution Is Dangerous

Letting an AI agent run arbitrary code on your machine is terrifying. Eidetic OS takes this seriously with three layers:

Layer 1: AST Static Analysis — Before any community skill executes, the code runs through an Abstract Syntax Tree analyser. It scans for dangerous operations (os.system(), subprocess.call(), network access, file deletion) and classifies them as BLOCK (hard-stopped), WARN (logged, requires approval), or INFO (noteworthy but safe).

Layer 2: Runtime Sandbox — Even after static analysis, skills execute inside a sandboxed environment with timeout limits, memory caps, restricted filesystem access (vault-only), and no network access.

Layer 3: Audit Trail — Every autonomous action gets logged to an append-only JSONL file. The dashboard has a dedicated panel for browsing these logs with full timestamps and details.

Git Sync Hardening

When you have multiple agents writing to the same vault simultaneously, git conflicts are inevitable. v3.0 adds safe merge strategies (-X ours — vault-side always wins), YAML frontmatter validation before every commit, file-based locking with stale detection and automatic cleanup, and iCloud compatibility for Obsidian vaults synced through iCloud.

Pluggable Vector Backends

The default sqlite-vec backend works great for personal use. But if you need more, swap backends without changing a line of indexing code:

# In your config
vector_backend: "lancedb"   # or "chromadb" or "sqlite" (default)

All three backends implement the same abstract VectorBackend interface. Your RAG pipeline doesn't know or care which one is running underneath.

Pluggable LLM Backends

Eidetic OS auto-detects whatever local LLM server you're running — LM Studio, Ollama, llama.cpp, or any OpenAI-compatible API. No cloud dependency. No API keys required. Everything runs on your hardware.

The Dashboard

eidetic dashboard launches a Flask web app with seven panels: System Health (vault size, embedding coverage, sync status), Audit Trail (browse every autonomous action), Scheduled Tasks (view and manage automated pipelines), Skills (browse 160+ marketplace skills), Vector Store (embedding statistics, chunk distribution), RAG Search (test queries with result explanations), and Knowledge Graph (D3.js force-directed entity visualisation).

Dark theme with slate/green accents. Server-side rendered — no npm, no build step, no React.

How It Compares

Feature	Eidetic OS	Letta (MemGPT)	Mem0	Khoj	gAIOS
Memory Model	Markdown vault + hybrid RAG	Git-backed virtual FS	Vector + graph fact store	TF-IDF + semantic	System prompts + wiki
Consolidation	Scheduled pipeline + chunking	"Sleeptime" background merging	Event-based fact extraction	Incremental indexing	Manual CLI tools
Vector Store	SQLite-vec / LanceDB / ChromaDB	Supabase (pgvector)	Qdrant, Neo4j, Milvus	In-memory + local	Filesystem
Security	AST scanner + sandbox + audit	—	—	—	—
Extensions	Pluggable entry-points + MCP	Parent-subagent worktrees	Thread-linked agents	Multi-agent workers	Python tools
Local-First	Yes (fully offline)	Partial	No (cloud required)	Yes	Yes
LLM Backends	LM Studio, Ollama, llama.cpp, OpenAI	OpenAI, Anthropic	Various cloud	OpenAI, Ollama	Claude Code only
Dashboard	Flask + D3.js (7 panels)	Web UI	—	Web UI	—
Skills	160+ marketplace	Built-in	Built-in	Built-in	/wiki tools

What It Actually Does Day-to-Day

7:00 AM — Morning briefing pipeline fires. Scans the vault, checks health, compiles a summary, emails it to you.

Throughout the day — Every Cowork session is captured automatically. Architecture decisions, debug sessions, planning — all preserved.

Any time — Search your vault: "What did we decide about authentication?" Hybrid RAG returns the exact chunk with reasoning preserved.

6:00 PM — Evening session capture. Another batch of conversations preserved.

Overnight — Embedding pipeline processes new files. Knowledge graph updates. Tomorrow's briefing compiles.

The 17+ automated pipelines include twice-daily session capture, incremental RAG indexing, morning email briefings, knowledge graph rebuilds, vault health checks, git sync and commit, trading research modules (optional), and audit trail rotation.

The Numbers

650+ tests, CI/CD via GitHub Actions with OIDC trusted PyPI publishing
160+ installable skills with marketplace, registry, and MCP server
3 pluggable vector backends — SQLite-vec, LanceDB, ChromaDB
4 LLM backends — LM Studio, Ollama, llama.cpp, OpenAI-compatible
7-panel dashboard with D3.js knowledge graph
17+ automated pipelines on configurable schedules
Append-only JSONL audit trail for every action
AST security scanner with BLOCK/WARN/INFO severities
Git sync hardening with safe merge, file locking, frontmatter validation
MIT licensed, Docker support, Python 3.9+

What I Learned

Session persistence is the killer feature. Without persistent memory, you're rebuilding context every session. This is the fundamental problem that makes all AI assistants feel disposable.
Hybrid search is worth the complexity. BM25 + vector + RRF + TF-IDF was the single biggest quality improvement. Pure embedding search sounds elegant but fails on exact matches.
Local-first is a real constraint but worth it. No cloud dependencies means it works offline and never leaks data. But you're managing your own infrastructure.
Git as the sync layer is underrated. Free versioning, branching, conflict detection. v3.0's hardening made concurrent access reliable.
Names matter more than you think. "Atlas OS" collided with a 20K-star Windows project. Every search result — buried. Rebranding was painful (176 files) but necessary. Pick a unique name from day one.
Security can't be an afterthought. The moment you let an AI execute code autonomously, you need static analysis, sandboxing, and audit logging. From the start.

What's Next: v4.0 Roadmap

#22 — Mem0-style Fact Extraction — Extract discrete facts from conversations instead of storing raw transcripts. Deduplicate against existing memory. Estimated 80% context reduction.

#23 — Sleeptime Consolidation Daemon — Background process that compresses and synthesises dialogue logs while you're offline. Resolves contradictions, merges related facts, prunes stale info.

#24 — Native Obsidian Plugin — Search, manage, and visualise your memory index directly inside Obsidian. Runs against the local server.

#25 — Interactive Setup Wizard — Guided CLI interview that auto-detects LLM backends, maps endpoints, configures vault location, profiles your preferences.

#26 — Channel Adapters — Query your knowledge base from Slack or Telegram. System runs as a local daemon.

#27 — Memory Decay Scoring — Time-weighted relevance. Recent memories boosted, stale ones decay. Prevents old context from polluting active reasoning.

Getting Started

pip install eidetic-os         # Install
eidetic init                   # Initialise vault + detect LLMs
eidetic doctor                 # Check system health
eidetic embed                  # Index your vault
eidetic search "auth decision" # Search your knowledge
eidetic dashboard              # Launch web dashboard
eidetic mcp serve              # Start MCP server

The repo is at github.com/paulholland511/atlas-os (renaming to eidetic-os soon). Feedback, issues, and contributions welcome.

Update (June 2026): Renamed from Atlas OS to Eidetic OS. Shipped v3.0 with extension architecture, MCP skills, security hardening, git sync hardening, and pluggable vector backends. Published v4.0 roadmap. What started as a simple session-capture script is now a complete platform for building a persistent, secure, local-first AI operating system.