This is an early release preview. You may encounter bugs.
Metronix Memory logo
Unclaimed

Tool memory

Metronix Memory

Metronix Memory is a self-hosted memory backend for agents over MCP: ingest files and Saa...

C 64/100 GitHub score ? This grade is derived from GitHub signals, not user votes. Open for the full breakdown.
No votes yet

01 / About

What Metronix Memory is.

Metronix Memory is a self-hosted memory backend that agents call over the Model Context Protocol. It ingests files and connected SaaS sources, retrieves with dense vectors, SPLADE sparse retrieval, and graph context with source citations, stores durable facts and preferences scoped per workspace and agent, and runs a freshness pipeline that flags stale or conflicting records as projects change.

The stack runs as a Docker Compose deployment: a Python core with PostgreSQL, Qdrant, Neo4j, and Redis behind it, plus a bundled Ollama container that pulls an embedding model and a small graph-extraction model on first start. No external chat model is required for memory use; one is configured only when Metronix itself should generate answers. Docker needs at least 6 GB of RAM and about 15 GB of disk.

Four pipelines carry the work: ingestion fetches, parses, chunks, embeds, and stores from connectors and file uploads across PDF, HTML, Office, text, and tabular formats; retrieval classifies, expands, recalls, reranks, scores, and answers; freshness links, reconciles, monitors, curates, and decides; and memory stores, searches, reviews, and assembles agent-scoped records of type fact, preference, and pinned.

Three surfaces sit on the same core: a REST API, an OpenAI-compatible API, and an MCP endpoint. An optional admin console, served behind its own Compose profile, adds data connectors for Jira, Confluence, GitHub, Google Drive, Notion, and Slack, chat-bot channel registration, file upload, and service health.

Directional single-run benchmark results are published under a stated protocol using the same answer model, blind judge, and volume for each system, reporting both retrieval and end-to-end layers.

Benchmark Scope End-to-end Retrieval signal
LoCoMo 1,982 QA pairs 52.8% Recall@10 85.3%
LongMemEval-S 500 questions 59.0% Recall@10 95.4%
MemoryAgentBench 2,800 tasks 63.6% Accurate retrieval 84.7%
EventQA 65K and 131K 86.8% blended 98.0% at 65K, 94.8% at 131K
BEAM 100K 400 questions 32.1% Recall@10 2.9%

Features

  • Hybrid retrieval: dense vectors, SPLADE sparse vectors, and Neo4j graph context with query expansion, reranking, and citations
  • Durable agent memory: fact, preference, and pinned records scoped by workspace and agent, with a review queue and snapshots
  • Freshness lifecycle: linking, reconciliation, monitoring, and curation detect stale or contradictory records
  • Connector framework: Confluence, Jira, Notion, GitHub, Google Drive, Slack history, and local files
  • Three API surfaces: REST, an OpenAI-compatible endpoint, and a built-in MCP server
  • Local models by default: bundled Ollama embedding and graph-extraction models; an external chat model is optional
  • Runtime guides: documented setup for Hermes, OpenClaw, Claude Code, Codex, OpenCode, Cursor, LangChain, LangGraph, n8n, and more
  • Native Hermes provider: a separate plugin prefetches memories before turns and writes through Hermes' own memory lifecycle
  • Admin console: optional web UI for connectors, channels, uploads, and health, served over HTTPS behind a Compose profile
  • Self-hosted install: one bootstrap script or Compose stack, with update, uninstall, and data-volume controls

02 / Discussion CREDIBILITY-GATED

Discussion

Reading is open to everyone. Posting and voting need a verified identity or a GitHub grade of B or higher.

  • No discussions yet.

03 / Build

Build with Metronix Memory.

Browse the catalogue for frameworks, tools, and harnesses, each scored on real GitHub credibility.

Get Metronix Memory →

Browse the catalogue