Skip to main content

๐ŸŒ™ luminary-memory

A lightweight, self-hosted memory layer for AI agents.

PyPI version Python License CI Tests Coverage Stars

Self-hosted ยท Private ยท Budget-aware ยท Self-maintaining


What your agent remembers is what it becomes.

Agents are only as good as what they remember. A stateless agent re-learns the same context every session, paying the same tokens, making the same mistakes. luminary-memory closes that gap with a local memory store that persists between runs, retrieves the right context on demand, and keeps itself tidy over time.

Four retrieval strategies. One fused answer. Zero cloud.

  • Semantic, ONNX embeddings (384-dim, CPU, no GPU needed)
  • Keyword, FTS5 BM25 (SQLite, zero config)
  • Temporal, recency decay ร— access count
  • Graph, entity co-occurrence with automatic curation

Strategies run in parallel and fuse via weighted RRF (semantic 0.4, keyword 0.3, graph 0.2, temporal 0.1) โ†’ adaptive cutoff (cliff detection) โ†’ Jaccard deduplication (0.85) โ†’ token budget (4096). Short queries are expanded with graph entities before embedding, so "deploy?" still finds "production cluster".

Important rules always in context. In the Hermes provider, the top-N most important memories are injected every turn (persistent context) and merged with query recall under anti-duplication โ€” so the agent never forgets a rule that exists in the store. Rules are pinned (never pruned), and similar rule ingests auto-replace the old one instead of stacking contradictions. Core memory (tagged core) is auto-loaded into the system prompt every session โ€” the DB-backed equivalent of MEMORY.md โ€” so durable rules are present from the very first prompt, no query needed.


Quickstart

pip install luminary-memory
from luminary_memory import MemoryClient

client = MemoryClient(db_path="memory.db")

# store a durable fact
client.ingest("The deploy target is the staging cluster", tags=["deploy", "infra"])

# recall, four strategies fused into one ranked answer
result = client.recall("where do we deploy?")
for memory, score in zip(result.memories, result.scores):
    print(f"{score:.3f}  {memory.content}")
# โ†’ 0.942  The deploy target is the staging cluster
# CLI
luminary-memory add "deploy target is staging" --tags deploy
luminary-memory recall "where do we deploy?" --json
luminary-memory list
luminary-memory lifecycle
luminary-memory stats

Hermes Agent, first-class memory provider

Drop-in. Install the provider with pip install "luminary-memory[hermes]", then add memory.provider: luminary to your Hermes config. That's it.

From the next session: auto-recall injects relevant memories every turn, auto-save persists completed turns, and the model can call luminary_recall / luminary_ingest / luminary_list on demand.

Two optional LLM-powered features keep the store sharp:

  • ingest_llm, evaluates every turn before saving: drops chit-chat, stores factual summaries instead of raw transcripts.
  • auto_maintain, reviews the store at session end: keeps current facts, updates changed ones, deletes stale or duplicate ones.

22 settings are exposed in the Hermes dashboard for zero-hassle tuning. See hermes/README.md for the one-shot installer and full configuration.


Configuration

Every setting has a LUMINARY_* env var or a Settings object.

Setting Env var Default
backend LUMINARY_BACKEND sqlite
db_path LUMINARY_DB_PATH luminary_memory.db
pg_dsn LUMINARY_PG_DSN postgresql://localhost/luminary_memory (pgvector only)
pg_hnsw_index LUMINARY_PG_HNSW_INDEX false
pg_hnsw_m LUMINARY_PG_HNSW_M 16
pg_hnsw_ef_construction LUMINARY_PG_HNSW_EF_CONSTRUCTION 64
embedding_model LUMINARY_EMBEDDING_MODEL BAAI/bge-small-en-v1.5
embedding_dim LUMINARY_EMBEDDING_DIM 384
ingest_llm LUMINARY_INGEST_LLM false
rrf_k LUMINARY_RRF_K 60
strategy_weights LUMINARY_WEIGHT_{SEMANTIC,KEYWORD,GRAPH,TEMPORAL} 0.4 / 0.3 / 0.2 / 0.1
recall_cliff_threshold LUMINARY_RECALL_CLIFF_THRESHOLD 0.45
dedup_jaccard_threshold LUMINARY_DEDUP_JACCARD_THRESHOLD 0.85
token_budget LUMINARY_TOKEN_BUDGET 4096
max_memories LUMINARY_MAX_MEMORIES 1000
ttl_default_seconds LUMINARY_TTL_DEFAULT_SECONDS null
prune_min_importance LUMINARY_PRUNE_MIN_IMPORTANCE 0.2
consolidate_jaccard_threshold LUMINARY_CONSOLIDATE_JACCARD_THRESHOLD 0.9
consolidate_semantic LUMINARY_CONSOLIDATE_SEMANTIC true
importance_auto LUMINARY_IMPORTANCE_AUTO true
importance_recall_boost LUMINARY_IMPORTANCE_RECALL_BOOST 1.0
rule_auto_replace LUMINARY_RULE_AUTO_REPLACE true
rule_auto_replace_threshold LUMINARY_RULE_AUTO_REPLACE_THRESHOLD 0.85
rule_importance LUMINARY_RULE_IMPORTANCE 0.9
context_top_n LUMINARY_CONTEXT_TOP_N 8
context_budget LUMINARY_CONTEXT_BUDGET 2000
context_min_importance LUMINARY_CONTEXT_MIN_IMPORTANCE 0.0
core_tag LUMINARY_CORE_TAG core
core_top_n LUMINARY_CORE_TOP_N 12
core_budget LUMINARY_CORE_BUDGET 8000
query_planner LUMINARY_QUERY_PLANNER true
query_planner_keyword_threshold LUMINARY_QUERY_PLANNER_KEYWORD_THRESHOLD 0.9
ingest_whitelist LUMINARY_INGEST_WHITELIST []
llm_base_url LUMINARY_LLM_BASE_URL ""
llm_api_key LUMINARY_LLM_API_KEY ""
llm_model LUMINARY_LLM_MODEL gpt-4o-mini
llm_timeout LUMINARY_LLM_TIMEOUT 10
llm_max_tokens LUMINARY_LLM_MAX_TOKENS 512
rule_keywords LUMINARY_RULE_KEYWORDS JANGAN,WAJIB,HARUS,...

Provider-specific settings (Hermes dashboard): max_memories, context_*, mode, recall_limit, auto_recall, recall_sync, auto_retain, retain_every_n_turns, retain_user_prefix / retain_assistant_prefix, ingest_llm, auto_maintain, consolidate_semantic, importance_auto, recall_indicator, retain_indicator โ€” live in ~/.hermes/luminary/config.json. See hermes/SKILL.md for the full provider config table.


Architecture

Memory is a loop, not a pipeline you run once. Every turn, luminary recalls what is relevant before the agent answers, then ingests what mattered after, and a background lifecycle keeps the store lean.

        โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ LOOP โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
        โ”‚                                                               โ”‚
   recall(query) โ”€โ”€โ–บ 4 strategies in parallel โ”€โ”€โ–บ weighted RRF โ”€โ”€โ–บ adaptive cutoff โ”€โ”€โ–บ ranked results
        โ–ฒ            semantic โ”‚ keyword โ”‚ temporal โ”‚ graph   (per-strategy weights)   (cliff detection)
        โ”‚                                                               โ”‚
        โ””โ”€โ”€ inject into agent context โ—„โ”€โ”€ token budget (4096) โ—„โ”€โ”€ dedup (Jaccard 0.85)
                                                            โ”‚            โ”‚
   persistent context โ”€โ”€โ–บ top-N by importance every turn โ”€โ”€โ”˜ (merged, anti-duplicated)
                                                            โ”‚
   ingest(text) โ”€โ”€โ–บ whitelist โ”€โ”€โ–บ (LLM curation) โ”€โ”€โ–บ embed (ONNX 384-d) โ”€โ”˜
                                                            โ”‚
   lifecycle() โ”€โ”€โ–บ cleanup (TTL) โ”€โ”€โ–บ consolidate (semantic + Jaccard, pinned exempt) โ”€โ”€โ–บ prune (importance, pinned exempt)
   maintenance() โ”€โ”€โ–บ LLM reviews store โ”€โ”€โ–บ keep โ”‚ update โ”‚ delete stale facts

Why it is accurate:

Stage Mechanism
4 strategies Semantic (ONNX cosine, vectorized matmul) + keyword (FTS5 BM25) + temporal (recency ร— access, batched fetch) + graph (entity co-occurrence, SQL aggregation), all in parallel
Persistent context Top-N important memories injected every turn (not just at session start), so rules never fall out of context
Weighted fusion Each strategy carries a tunable weight (semantic 0.4, keyword 0.3, graph 0.2, temporal 0.1), so high-signal strategies dominate the ranking
Query expansion Short queries are expanded with co-occurring graph entities before embedding, so a bare "deploy?" still finds "production cluster"
Importance boost Memories at importance โ‰ฅ 0.8 get a ranking bonus, lifting durable rules above weak-but-recent noise
Adaptive cutoff Cliff detection keeps only the relevant cluster: a sparse store returns 3 strong matches instead of padding to 20, while a dense relevant store keeps everything (no over-filtering)
Token budget Hard cap so memory injection never blows up the context window

Why it stays clean:

Stage Mechanism
Lifecycle TTL cleanup, semantic consolidation (embedding cosine, fallback Jaccard), importance-based pruning โ€” all batched at the backend level
Rule pinning Memories at importance โ‰ฅ 0.9 are pinned: never pruned, never deleted by consolidation
Rule auto-replace Similar rule ingests replace the old one (anti-contradiction), so "JANGAN tabel" never coexists with "WAJIB table"
Store hygiene Rule keywords are checked only against the LLM-curated summary (raw transcripts are never pinned); turns without a curated summary are dropped when ingest_llm is on
Auto importance Every memory is scored by recency + access + graph centrality; prune and health use live values
Max memories cap max_memories (default 1000) prunes the oldest/lowest-importance when the store exceeds it
LLM maintenance Optional auto_maintain reviews the store at session end: keep, update, or delete stale facts
Health score health_score() gives a 0-100 checkup with actionable recommendations

health_score() gives you a 0-100 checkup with actionable recommendations.


Documentation

Section
Quickstart Install and first use
Architecture Pipelines and data flow
Python API MemoryClient reference
CLI All subcommands
Recall Four strategies + fusion
Lifecycle Cleanup, consolidation, pruning, LLM maintenance
Backends SQLite vs pgvector
Hermes integration Provider, config, installer
Roadmap v0.2.13 โ†’ v1.0.0
Benchmarks ~77 ms recall @ 5k (p50), 0 LLM tokens

License

Apache-2.0 ยฉ 2026 Dwiky Candra

Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

luminary_memory-0.2.13.tar.gz (166.5 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

luminary_memory-0.2.13-py3-none-any.whl (73.0 kB view details)

Uploaded Python 3

File details

Details for the file luminary_memory-0.2.13.tar.gz.

File metadata

  • Download URL: luminary_memory-0.2.13.tar.gz
  • Upload date:
  • Size: 166.5 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? Yes
  • Uploaded via: twine/7.0.0 CPython/3.13.14

File hashes

Hashes for luminary_memory-0.2.13.tar.gz
Algorithm Hash digest
SHA256 3899aeec6f95338dcae07f036357032006ea5057ca422a2a6683f977529b5aa9
MD5 29f46477ffe46325b1ba4eb699e46ba1
BLAKE2b-256 3d28c450062463501df3b83fb8ac3a0115502ef7bd5743f5c1f37e1c591816ac

See more details on using hashes here.

Provenance

The following attestation bundles were made for luminary_memory-0.2.13.tar.gz:

Publisher: publish.yml on alertxsto/luminary-memory

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

File details

Details for the file luminary_memory-0.2.13-py3-none-any.whl.

File metadata

File hashes

Hashes for luminary_memory-0.2.13-py3-none-any.whl
Algorithm Hash digest
SHA256 ba90fc72d74de498a9094378ebaf0eb838f332f7236b1a7d60262ce4fa340d9d
MD5 ee00ab2115c1172e148e1d857bafde3f
BLAKE2b-256 12cfb7401c20e15610fdaeac81332b466d9adf40359cfb4c803a4d0205e7e9d2

See more details on using hashes here.

Provenance

The following attestation bundles were made for luminary_memory-0.2.13-py3-none-any.whl:

Publisher: publish.yml on alertxsto/luminary-memory

Attestations: Values shown here reflect the state when the release was signed and may no longer be current.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page