Generated banner for MIRIX
Generated logo for MIRIX

MIRIX

Memory server

Created by Mirix AI

Published in Mirix-AI/MIRIX. Publisher page

3,460 GitHub stars

What it is

Mirix is a multi-agent personal assistant designed to track on-screen activities and answer user questions intelligently. By capturing real-time visual data and consolidating it into structured memories, Mirix transforms raw inputs into a rich knowledge base that adapts to your digital experiences.
— the description by Mirix AI

AutoGineer overview, from the brain’s own files

Mirix is a memory server designed to provide AI agents with persistent, multi-modal memory. It functions by observing screen activity and processing natural language conversations, consolidating these inputs into six distinct memory components: Core, Episodic, Semantic, Procedural, Resource, and Knowledge Vault. The system uses a hybrid storage approach, leveraging PostgreSQL with pgvector for search and an optional Neo4j graph database for provenance tracking. Mirix includes an 'Auto-Dream' feature for periodic memory consolidation, deduplication, and refinement, ensuring that the agent's knowledge base remains structured and relevant over time.

How it works

Memory model: Hybrid

AutoGineer overview, from the brain’s own files

Mirix operates as a backend server that orchestrates six specialized sub-agents to manage different memory types. It captures user interactions and visual screen data, which are then processed and stored in a PostgreSQL database. The system supports full-text search via BM25 and vector similarity search. An optional graph memory layer can be enabled to map relationships between entities using Neo4j. The Auto-Dream functionality allows the system to review and merge memory entries, while the provided Python client enables agents to read from and write to these memory stores.

Folders
FolderRoleFiles
.githubagent-config1
assetsattachments3
docsdocs5
samplesexamples16
scriptsscripts34
teststests132
.vscodefolder2
dashboardfolder35
dockerfolder3
evalsfolder53
mirixfolder341

The agent writes

Requirements

Apps: Docker

Runtimes: Python >=3.10,<4.0

Databases: Neo4j, PostgreSQL, Redis, SQLite

API keys (by name): MIRIX_API_KEY

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Google Antigravity, Kiro, OpenCode, Amp, Roo Code, Cline, JetBrains Junie, Devin (ex-Windsurf)

Set it up

  1. This brain runs code automatically: 2 scripts. Review Makefile, setup.py before opening the folder in Claude Code. No step below turns a hook on for you.

    • Makefile: $(POETRY) install
    • setup.py: python setup.py
  2. Not scanned by AutoGineerThe author’s README also describes installing it with Docker Compose. Read its install section: AutoGineer did not scan that path. https://github.com/Mirix-AI/MIRIX/blob/9077e4b229dd8f61c5703b431a97788c6b61acfb/README.md#quick-start
  3. Not scanned by AutoGineerAutoGineer could not scan everything it runs. https://pypi.org/project/mirix/
  4. Created by Mirix AI. Published in Mirix-AI/MIRIX. Licence: Apache License 2.0.

Usage

AutoGineer overview, from the brain’s own files

  • Initialize a meta-agent with specific memory components.
  • Add conversation turns or tool-use logs to the memory store.
  • Retrieve context-aware memories based on user queries.
  • Trigger memory consolidation using the Auto-Dream endpoint.
  • Enable graph-based provenance for complex entity relationships.
“What did we discuss on MirixDB in last 4 days?”
The agent retrieves relevant conversation history and memory blocks from the last four days to answer the user's question.
“Deploy the service.”
The agent records the tool call, captures any resulting errors or successful fixes, and stores this as procedural memory for future reference.

Documentation by Mirix AI

Image: Mirix Logo

MIRIX - Multi-Agent Personal Assistant with an Advanced Memory System

Your personal AI that builds memory through screen observation and natural conversation

| 🌐 Website | 📚 Documentation | 📄 Paper | 💬 Discord

<!-- | [Twitter/X](https://twitter.com/mirix_ai) | [Discord](https://discord.gg/S6CeHNrJ) | -->


Key Features 🔥
  • Multi-Agent Memory System: Six specialized memory components (Core, Episodic, Semantic, Procedural, Resource, Knowledge Vault) managed by dedicated agents

  • Screen Activity Tracking: Continuous visual data capture and intelligent consolidation into structured memories

  • Privacy-First Design: All long-term data stored locally with user-controlled privacy settings

  • Advanced Search: PostgreSQL-native BM25 full-text search with vector similarity support

  • Graph Memory (optional): A provenance hypergraph over episodic and semantic memories in Neo4j, with n-ary facts that link entities through named roles and cite the memory rows they came from

  • Multi-Modal Input: Text, images, voice, and screen captures processed seamlessly

Results

Image: MIRIX-2.0 compared with other memory systems on user-centric and agent-centric tasks

MIRIX-2.0 compared with other memory systems. Each axis label gives the MIRIX-2.0 score; the value in parentheses is its lead over the strongest baseline on that axis, shown where MIRIX-2.0 leads.

  • (a) User-centric tasks (accuracy, %): conversational recall on LoCoMo and LongMemEval-S, and the document QA tracks of MemoryAgentBench (SHDocQA, MHDocQA, DetectiveQA). Baselines are A-Mem, Graphiti, MemoryBank, mem0 and HyperMem. LoCoMo uses graph memory with AutoDream; LongMemEval-S and document QA use graph memory alone.

  • (b) Agent-centric tasks (success rate, %): the six ALFWorld task types (Pick, Look, Clean, Heat, Cool, Pick Two) and five WebShop product categories (Fashion, Beauty, Electronics, Garden, Grocery), with GPT-6 Luna as the agent model. Baselines are no memory, AWM and ReasoningBank.

Quick Start

Step 1: Backend & Dashboard (Docker):

docker compose up -d --pull always

Step 2: Create an API key in the dashboard (http://localhost:5173) and set as the environmental variable MIRIX_API_KEY.

Step 3: Client (Python, mirix-client, https://pypi.org/project/mirix-client/):

pip install mirix-client

Now you are ready to go! See the example below:

from mirix import MirixClient

client = MirixClient(
    api_key="your-api-key",
    base_url="http://localhost:8531",
)

client.initialize_meta_agent(
    config={
        "llm_config": {
            "model": "gemini-3.6-flash",
            "model_endpoint_type": "google_ai",
            "api_key": "your-api-key-here",
            "model_endpoint": "https://generativelanguage.googleapis.com",
            "context_window": 1_000_000,
        },
        "embedding_config": {
            "embedding_model": "gemini-embedding-001",
            "embedding_endpoint_type": "google_ai",
            "api_key": "your-api-key-here",
            "embedding_endpoint": "https://generativelanguage.googleapis.com",
            "embedding_dim": 768,
        },
        "meta_agent_config": {
            "agents": [
                {
                    "core_memory_agent": {
                        "blocks": [
                            {"label": "human", "value": ""},
                            {"label": "persona", "value": "I am a helpful assistant."},
                        ]
                    }
                },
                "resource_memory_agent",
                "semantic_memory_agent",
                "episodic_memory_agent",
                "procedural_memory_agent",
                "knowledge_vault_memory_agent",
            ],
        },
    }
)

client.add(
    user_id="demo-user",
    messages=[
        {"role": "user", "content": [{"type": "text", "text": "The moon now has a president."}]},
        {"role": "assistant", "content": [{"type": "text", "text": "Noted."}]},
    ],
    session_id="sess-demo-001",
)

# Include tool activity when you want skills learned from the WORK PROCESS:
# tool errors, retries, and the fix that finally worked are the distiller's
# strongest signals. Pass tool results as role="tool" turns and/or a
# "tool_calls" list on assistant messages (OpenAI shape) — both are preserved
# in the session conversation store.
client.add(
    user_id="demo-user",
    messages=[
        {"role": "user", "content": [{"type": "text", "text": "Deploy the service."}]},
        {"role": "assistant", "content": "", "tool_calls": [
            {"function": {"name": "kubectl_apply", "arguments": "{\"file\": \"deploy.yaml\"}"}}
        ]},
        {"role": "tool", "name": "kubectl_apply", "content": "error: forbidden (missing RBAC)"},
        {"role": "assistant", "content": [{"type": "text", "text": "Fixed the RBAC role and redeployed successfully."}]},
    ],
    session_id="sess-demo-001",
)

memories = client.retrieve_with_conversation(
    user_id="demo-user",
    messages=[
        {"role": "user", "content": [{"type": "text", "text": "What did we discuss on MirixDB in last 4 days?"}]},
    ],
    limit=5,
)
print(memories)

For more API examples, see samples/run_client.py.

Auto-Dream Memory Consolidation

MIRIX also exposes an auto-dream endpoint for explicit memory cleanup and consolidation. Auto-dream reviews existing memories, merges duplicates, resolves stale/conflicting entries where possible, and writes the result back through the memory tools.

REST endpoint:

POST /memory/auto_dream?user_id=demo-user
Content-Type: application/json

{
  "mode": "experience",
  "dry_run": false
}

Supported mode values:

ModeMemory component(s) reviewed
coreCore memory blocks
episodicEpisodic memories
semanticSemantic memories
resourceResource memories
proceduralProcedural memories
knowledgeKnowledge Vault memories
experienceEpisodic, Semantic, and Knowledge Vault memories together

Use dry_run: true to fetch counts and inspect what would be processed without applying updates. The optional model field can override the auto-dream agent model for that request. For procedural mode, pass the target meta_agent_id and optionally last_n_sessions to distill recent session experiences.

Python client example:

result = client.auto_dream(
    user_id="demo-user",
    mode="procedural",
    meta_agent_id=meta_agent.id,
    last_n_sessions=3,
    dry_run=False,
)
print(result)
Graph Memory

MIRIX can index episodic and semantic memories into a provenance hypergraph stored in Neo4j. Entities become anchors, each extracted fact becomes an n-ary frame whose edges name the role each anchor plays, and every frame cites the memory rows it came from. With graph memory on, episodic and semantic retrieval enters through the graph, and Auto-Dream merges duplicate anchors on the graph instead of rewriting stored memories.

Graph memory is off by default. To turn it on:

  1. Start Neo4j 5.23 or later. docker compose --profile graph up -d starts Neo4j 5.26 with APOC; first set MIRIX_NEO4J_PASSWORD (at least 8 characters) in .env, because there is no default password.

  2. Install the Neo4j driver. It is in requirements.txt; after pip install -e ., run pip install "neo4j>=5.20,<6".

  3. Set MIRIX_ENABLE_GRAPH_MEMORY=true and MIRIX_NEO4J_PASSWORD to the password your Neo4j uses. MIRIX_NEO4J_URI and MIRIX_NEO4J_USER default to bolt://localhost:7687 and neo4j.

With graph memory on, POST /memory/auto_dream refines the graph only unless the request sets graph_only to false. Evaluation settings and commands are in evals/GRAPH_MEMORY.md.

Upgrading an Existing Database

Fresh databases get their full schema automatically at startup. Existing databases require manual migrations when upgrading to a version that alters tables — startup creates missing tables but never adds columns to existing ones. If migrations are pending, the server refuses to start and names the exact scripts to run.

For the skill-based procedural memory release, run against your database (in this order):

psql "$MIRIX_PG_URI" -f scripts/migrate_procedural_to_skill.sql
psql "$MIRIX_PG_URI" -f scripts/migrate_add_message_session_id.sql
psql "$MIRIX_PG_URI" -f scripts/migrate_add_message_session_id_phase2.sql   # outside a transaction (CREATE INDEX CONCURRENTLY)
psql "$MIRIX_PG_URI" -f scripts/migrate_add_conversation_message.sql
psql "$MIRIX_PG_URI" -f scripts/migrate_add_conversation_message_phase2.sql # outside a transaction
psql "$MIRIX_PG_URI" -f scripts/migrate_add_skill_experience.sql
psql "$MIRIX_PG_URI" -f scripts/migrate_add_agent_trigger_state.sql
psql "$MIRIX_PG_URI" -f scripts/migrate_backfill_procedural_scope.sql   # backfill filter_tags['scope'] from each skill's owning client

For the graph-memory release, which adds five provenance columns, also run:

psql "$MIRIX_PG_URI" -f scripts/migrate_add_graph_provenance_columns.sql

Each script is idempotent where possible and documents its own preconditions in its header. Run them once, then restart the server.

License

Mirix is released under the Apache License 2.0. See the LICENSE file for more details.

Contact

For questions, suggestions, or issues, please open an issue on the GitHub repository or contact us at [e-mail address on the upstream page](https://github.com/Mirix-AI/MIRIX/blob/9077e4b229dd8f61c5703b431a97788c6b61acfb/README.md)

Join Our Community

Connect with other Mirix users, share your thoughts, and get support:

💬 Discord Community

Join our Discord server for real-time discussions, support, and community updates: https://discord.gg/S6CeHNrJ

🎯 Weekly Discussion Sessions

We host weekly discussion sessions where you can:

  • Discuss issues and bugs

  • Share ideas about future directions

  • Get general consultations and support

  • Connect with the development team and community

📅 Schedule: Friday nights, 8-9 PM PST 🔗 Zoom Link: https://ucsd.zoom.us/j/96278791276

📱 WeChat Group

You can add the account ari_asm so that I can add you to the group chat.

Acknowledgement

We would like to thank Letta for open-sourcing their framework, which served as the foundation for the memory system in this project.

docs/Mirix_async_native_changes.md

MIRIX Async-Native Rewrite

1. Why Async-Native

MIRIX is a multi-agent system where every user request fans out into database queries, Redis lookups, LLM API calls, embedding computations, and Kafka messages -- all I/O-bound. The previous sync codebase serialized these operations: each blocked thread sat idle waiting for a network response, and concurrency was limited to the thread-pool size.

Rewriting the stack to be async-native delivers several concrete benefits:

Higher throughput on the same hardware. A single event loop multiplexes thousands of in-flight I/O operations without dedicating a thread to each one. Connection pools (asyncpg, Redis, httpx) are shared across all coroutines, so the server handles more concurrent users with fewer file descriptors, less memory, and less context-switching overhead.

End-to-end consistency with FastAPI / Uvicorn. FastAPI is async-first. When route handlers are async def and directly await the server/manager/agent/LLM chain, there is no implicit offload to a thread-pool executor. This removes an entire class of subtle bugs (thread-safety of shared state, session leaks across threads) and makes the call stack easy to reason about.

Natural streaming and SSE. LLM token streaming and Server-Sent Events map directly to async generators. No background thread is needed to feed an SSE response; the generator yields tokens as they arrive from the LLM provider.

In-process background workers. Queue consumers (memory extraction, cleanup) run as asyncio.Tasks in the same process. This simplifies deployment (one container, one process) while keeping workers non-blocking.

Lower tail latency. asyncio.sleep-based retries and exponential back-off do not occupy a thread during the wait, freeing the loop to serve other requests.


2. High-Level Changes

2.1 External Library Migrations
LayerSync (before)Async (after)
Database driverpg8000 / psycopg2-binaryasyncpg (PostgreSQL), aiosqlite (SQLite)
SQLAlchemycreate_engine, sessionmaker, Sessioncreate_async_engine, async_sessionmaker, AsyncSession
Redisredis.Redisredis.asyncio.Redis with hiredis
HTTP clientrequestshttpx.AsyncClient
OpenAIopenai.OpenAIopenai.AsyncOpenAI
Anthropicanthropic.Anthropicanthropic.AsyncAnthropic
Azure OpenAIAzureOpenAIAsyncAzureOpenAI
Google AIsync genai callsasync genai + httpx.AsyncClient
Kafkasync kafka-python (if used)aiokafka (AIOKafkaProducer, AIOKafkaConsumer)
Web searchduckduckgo_searchasyncddgs
Google APIssync google-api-python-clientaiogoogle
Test runnersync pytestpytest-asyncio (asyncio_mode = "auto")
2.2 Application-Layer Changes

ORM base (mirix/orm/sqlalchemy_base.py) All CRUD methods (create, read, update, delete, list) are async def. Sessions are used via async with session. Retry decorators use asyncio.sleep().

Service managers (mirix/services/) All 16 managers are async:

#ManagerFile
1UserManageruser_manager.py
2ClientManagerclient_manager.py
3ToolManagertool_manager.py
4AdminUserManageradmin_user_manager.py
5OrganizationManagerorganization_manager.py
6BlockManagerblock_manager.py
7MessageManagermessage_manager.py
8CloudFileMappingManagercloud_file_mapping_manager.py
9StepManagerstep_manager.py
10AgentManageragent_manager.py
11RawMemoryManagerraw_memory_manager.py
12EpisodicMemoryManagerepisodic_memory_manager.py
13SemanticMemoryManagersemantic_memory_manager.py
14ProceduralMemoryManagerprocedural_memory_manager.py
15ResourceMemoryManagerresource_memory_manager.py
16KnowledgeVaultManagerknowledge_vault_manager.py

Every manager method uses async with self.session_maker() and await for all database operations.

LLM API layer (mirix/llm_api/) LLMClientBase.send_llm_request() and request() are async. All provider clients (OpenAI, Anthropic, Azure, Google, Cohere, Mistral, AWS Bedrock) use their respective async SDK classes. Streaming responses are AsyncGenerator. retry_with_exponential_backoff() uses asyncio.sleep().

Agent execution (mirix/agent/agent.py) step(), inner_step(), _get_ai_reply(), _handle_ai_response(), execute_tool_and_persist_state(), and save_agent() are all async. Built-in tools (core, memory, extras) are async. User-defined tools execute in ToolExecutionSandbox via asyncio.create_subprocess_exec() (no thread pool).

MetaAgent (mirix/agent/meta_agent.py) MetaAgent.step(), initialize(), and sub-agent orchestration are async. MessageQueue uses asyncio.Lock instead of threading.Lock.

Queue system (mirix/queue/)

  • MemoryQueue wraps asyncio.Queue.

  • KafkaQueue uses aiokafka (fully async producer/consumer).

  • QueueWorker runs as an asyncio.Task in the main event loop.

Server (mirix/server/server.py) AsyncServer (renamed from the former SyncServer) exposes async methods: send_messages(), _step(), load_agent(), create_agent(). A backward-compatible alias SyncServer = AsyncServer is retained for external callers that have not yet updated.

REST API (mirix/server/rest_api.py) All route handlers are async def and directly await server methods. Zero asyncio.to_thread wrappers on the request path. SSE streaming uses sse_async_generator().

Client SDK (mirix/client/remote_client.py) MirixClient uses httpx.AsyncClient with RetryTransport. All public methods (add, send_message, create_agent, etc.) are async. MirixClient.create() is an async factory for initialization.

Observability (mirix/observability/langfuse_client.py) Singleton initialization uses asyncio.Lock for coroutine-safe double-checked locking. The sync LangFuse SDK is called via asyncio.to_thread (see Section 3.1).

Tests (tests/, pyproject.toml) pytest-asyncio with asyncio_mode = "auto". Fixtures in conftest.py are async. asyncio_default_fixture_loop_scope = "session".


3. Remaining Synchronous Code

The request-serving hot path is fully async. The items below are the only remaining synchronous touch-points. Each is intentional.

3.1 LangFuse SDK
Wheremirix/observability/langfuse_client.py
WhatLangfuse() init, .flush(), .shutdown() are sync SDK calls, wrapped with await asyncio.to_thread(...).
WhyNo official async LangFuse client exists.
ImpactLow. Observability is off the hot path. to_thread borrows a thread from the default executor briefly; it does not block the event loop or limit request concurrency.
3.2 Gmail OAuth
Wheremirix/functions/mcp_client/gmail_client.py
Whatauthenticate_gmail_local() blocks waiting for a browser OAuth redirect. Called via await asyncio.to_thread(...).
WhyThe OAuth flow is inherently blocking (human in the loop).
ImpactLow. One-time auth; not on the per-request path.
3.3 SQLAlchemy DDL at Startup
Wheremirix/server/server.py, ensure_tables_created()
Whatawait conn.run_sync(Base.metadata.create_all)
WhySQLAlchemy's DDL/metadata API is sync-only; run_sync is the documented pattern for async engines.
ImpactNone at runtime. Runs once during application startup.
3.4 Cleanup Job Entry Point
Wheremirix/jobs/cleanup_raw_memories.py
Whatasyncio.run(delete_stale_raw_memories_async(threshold)) in __main__.
WhyStandard pattern for a standalone script invoked by cron; it bootstraps its own event loop.
ImpactNone. Separate process; does not affect the API server.
3.5 Pure CPU Helpers -- Intentionally Sync
Wheremirix/utils.py, mirix/services/utils.py, and private helpers in memory managers (_clean_text_for_search, _parse_embedding_field, _count_word_matches, _preprocess_text_for_bm25).
WhatString manipulation, regex, JSON parsing, token counting, date formatting, UUID generation. Zero I/O.
WhyAdding async def to a function that never awaits provides no concurrency benefit. The event loop only yields at await points, so an async def body with no awaits runs identically to a plain def -- but with extra coroutine-object overhead. A function should be async def if and only if it performs I/O. (Note: mirix/services/utils.py::build_query is correctly async def because it awaits embedding_model().)
ImpactNone. These run in microseconds. If a future helper became CPU-heavy, the correct fix would be asyncio.to_thread (offload to a thread), not async def.
3.6 Server Class Naming (Resolved)

The class formerly named SyncServer has been renamed to AsyncServer as part of this change set. All imports, type hints, docstrings, and tests have been updated. A backward-compatible alias SyncServer = AsyncServer is retained in mirix/server/server.py.


4. Summary

The MIRIX application is async-native from the HTTP boundary through the server, agents, service managers, ORM, database, Redis, Kafka, and LLM/embedding clients. The only remaining sync touch-points are:

  1. LangFuse -- sync SDK wrapped in asyncio.to_thread; low impact.

  2. Gmail OAuth -- blocking by design; wrapped in to_thread; rare.

  3. Startup DDL -- one-time run_sync; no runtime impact.

  4. Cleanup script -- asyncio.run() in __main__; separate process.

  5. Pure CPU helpers -- no I/O; async def would add overhead, not benefit.

  6. Server naming -- SyncServer renamed to AsyncServer; alias kept.

None of these limit MIRIX's ability to scale request throughput or concurrent users. The critical path is fully async.

512 files · 499 not served here

Advantages

  • Supports multi-modal inputs including text, images, voice, and screen captures. evidence: README.md
  • Provides a provenance hypergraph to link entities and cite memory sources. evidence: README.md

Limitations

  • Existing databases require manual migration scripts when upgrading to versions that alter table schemas. evidence: README.md
  • Requires manual configuration and setup of external dependencies like PostgreSQL and optional Neo4j. evidence: README.md

Security

Risk level: Low risk

This brain runs

Agent instructions that run or fetch something (12)

  • .cursorrules: User-defined tools run in `ToolExecutionSandbox` for security
  • .cursorrules: Run tests with: `pytest tests/`
  • .cursorrules: Run linters before committing: `ruff check .` and `pyright`
  • .cursorrules: User-defined tools MUST run in `ToolExecutionSandbox`
  • CLAUDE.md: docker-compose up -d # starts PostgreSQL (5432), Redis (6379), API (8531), Dashboard (5173)
  • CLAUDE.md: docker-compose ps # verify all services healthy
  • CLAUDE.md: pip install -e .
  • CLAUDE.md: python scripts/start_server.py --port 8531
  • CLAUDE.md: python scripts/start_server.py --port 8899 # Terminal 1
  • CLAUDE.md: make format # ruff import sort + format
  • CLAUDE.md: make lint # ruff check + pyright
  • CLAUDE.md: make check # format + lint + test

Install scripts (2)

  • Makefile (make install): $(POETRY) install
  • setup.py: python setup.py
  • Low risk: network-instructions (CLAUDE.md:31)
  • Low risk: scripts-present (scripts/start_server.py)
  • Low risk: scripts-present (setup.py)

Attribution and licence

Created by
Mirix AI
First committed by
@wangyu-ustc
Declared authors
  • Mirix AI (declared in pyproject.toml)
Publisher
MIRIX-AI (Community)
Source
Mirix-AI/MIRIX · commit 9077e4b
Licence
Apache License 2.0 (files served here)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Mirix AI.

Install from source

499 of its files are not served here, so there is no ZIP. Mirix-AI/MIRIX at 9077e4b