Vector Databases · ClaudioDrews

memory-os

Memory OS is a local-first memory system for Hermes Agent that persists conversations, facts, and context across sessions using SQLite, Qdrant vector search, and intelligent injection. It runs entirely on your machine with any LLM provider and eliminates the need for cloud memory subscriptions.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/ClaudioDrews/memory-os

1.2k

GitHub stars

117

Forks

Python

Primary language

MIT

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	ClaudioDrews/memory-os
Owner	ClaudioDrews
Primary language	Python
License	MIT — OSI-approved
Stars	1.2k
Forks	117
Open issues	7
Latest release	Unknown
Last updated	2026-06-10
Source	https://github.com/ClaudioDrews/memory-os

What memory-os is

A 7-layer Python architecture combining flat-file workspace memory (MEMORY.md, USER.md, CREATIVE.md), SQLite with FTS5 for session search, structured fact storage with trust scoring, a forked Icarus plugin for cross-session fabric recall, Qdrant hybrid search (cosine + BM25), auto-curated wiki ingestion, and a Ground Truth hierarchy to enforce memory use. Includes semantic deduplication, decay scanning, and surgical context injection.

Quickstart

Get the memory-os source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/ClaudioDrews/memory-os.git2cd memory-os3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Long-running Hermes Agent projects requiring persistent context

Teams building autonomous agents that need to retain project decisions, architectural patterns, and user preferences across weeks or months of sessions without repeating setup context.

Privacy-critical AI development with local infrastructure

Organizations requiring on-premise memory storage with no data leaving local machines, avoiding cloud-locked solutions and vendor lock-in for memory infrastructure.

Multi-provider LLM experimentation with unified memory

Development teams switching between OpenAI, Anthropic, Ollama, and local models while maintaining a single persistent memory layer and avoiding provider-specific memory APIs.

Implementation considerations

Docker and Python 3.11+ required; one-command installer (curl + bash) provided but verify on target hardware before production deployment.
Qdrant vector database tuned for 4096-dimensional embeddings with cosine + BM25 hybrid search; requires understanding of embedding model dimensionality and relevance thresholds.
Layer 7 (Ground Truth hierarchy) is critical—injected memory is ignored without explicit agent instructions in SOUL.md and rulebook.md; requires careful prompt engineering.
SQLite FTS5 for session search and fact storage; suitable for single-machine use but scaling to millions of facts/sessions requires monitoring query performance.
Semantic deduplication at cosine >0.92 similarity; tuning threshold and decay scanner policies (weekly by default) needed for your memory size and refresh cadence.

When to avoid it — and what to weigh

You require production SLA guarantees — Project shows early maturity (created 2026-05-31, latest release 'none', 7 open issues). No stated uptime guarantees, disaster recovery, or commercial support available.
You need multi-user, cloud-distributed memory — Architecture is local-first and single-machine; no clear support for multi-user sync, cloud replication, or distributed deployments across teams.
You cannot run Docker locally — Stack requires Docker (Qdrant, Redis, ARQ Worker) plus Python 3.11+. No serverless or lightweight deployment options described.
You need battle-tested third-party vendor memory — If you prefer outsourcing memory to mature SaaS (mem0, Zep, Letta) with commercial support, this DIY local stack requires operational ownership.

License & commercial use

MIT License. Permissive OSI-approved license allowing use, modification, and distribution in commercial and private projects. No copyleft obligations.

MIT permits commercial use without restrictions. However, no warranty, support, or liability indemnification is provided. Use in production requires your own operational ownership, monitoring, and backup procedures. No commercial support offering stated.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Strong
License clarity	Clear
Deployment complexity	High
DEV.co fit	Good
Assessment confidence	High

Security considerations

Local storage (SQLite, Qdrant) holds conversation history and structured facts; encryption at rest not mentioned. No stated audit, penetration test, or security hardening documentation. Redis + ARQ services require network isolation from untrusted networks. LLM provider credentials must be protected (environment variables assumed). Data exfiltration risk depends on LLM provider you choose—review their privacy terms. Qdrant setup should restrict network access if running on shared machines.

Alternatives to consider

mem0

Cloud-first memory layer with multi-provider LLM support. Offers commercial hosting and managed memory but requires cloud subscription; less control over data locality.

Zep

Open-source long-term memory for LLM apps with cloud or self-hosted options. Broader LLM compatibility but less Hermes-native integration and no structured fact trust scoring.

Letta (formerly Memgpt)

Agentic memory system with multi-turn context management. More general-purpose than Hermes-specific; memory is less deeply integrated into conversation loop.

Software development agency

Build on memory-os with DEV.co software developers

Memory OS runs locally on your machine with any LLM provider. Start with the one-command installer, configure your Ground Truth hierarchy, and stop repeating context. Review the full architecture and deployment guide in the README.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

MemoryOS MemOS EverOS

Related on DEV.co

Explore the category and the services that help you build with it.

Vector Databases AI application development Custom software development API development Talk to DEV.co

memory-os FAQ

Can I use Memory OS with LLMs other than Hermes?

Not directly. Memory OS is designed as a Hermes Agent plugin. It could theoretically be adapted to other agents, but the Icarus fork and layer-injection architecture are Hermes-specific. Requires significant modification.

What if I lose my local Docker containers?

SQLite databases (state.db, memory_store.db) persist in the filesystem if you back them up. Qdrant data persists in Docker volumes if configured with named volumes. No backup/restore tooling mentioned; you must manage this yourself.

How much disk space does Memory OS need?

Not stated. Depends on conversation history, fact store size, and Qdrant vector index. Weekly decay scanner removes old embeddings. Monitor disk usage during early sessions; no guidance on pruning or archival.

Is Memory OS production-ready?

Early-stage (May–Jun 2026). Includes smoke tests and community-driven fixes but no stated SLA, commercial support, or disaster recovery. Suitable for solo developers or small teams willing to operate it themselves. Not recommended for mission-critical applications without hardening.

Software development & web development with DEV.co

Adopting memory-os is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate vector databases software in production.

Ready to give your Hermes Agent long-term memory?

Talk to DEV.co Schedule a Consultation