Open-core memory engine
A memory engine you can actually inspect, not just trust.
Spomory extracts what you tell it into a graph of entities and relations, retrieves by walking that graph instead of guessing from a similarity score, and uses a reinforcement-learned policy — not hardcoded rules — to decide what to add, update, or forget.
Two ways to run it, same engine underneath
Local-first
For developers and technical users: install the MCP server, point Claude Desktop or Cursor at it, and your memory graph lives in a SQLite file on your own disk — encrypted at rest by default, no account required.
Cloud & cross-app
For memory that needs to follow you across more than one client: a hosted MCP endpoint backed by Postgres, reachable over HTTPS with either an API key or OAuth 2.1 — currently for MCP-capable clients (Claude Desktop, Cursor, and similar), not a web app.
What's actually different here
Memory sovereignty, not a compliance checkbox
Export your full graph any time in an open JSON-LD-style format, or physically delete it — permanently, with an audit trail, and it's a free-tier feature, not something locked behind a paywall.
Basis: memory passport export + true delete — see the Memory Passport page.
Real measured results, limitations included
Published LoCoMo and LongMemEval numbers, run against a live LLM — including the run where a fix traded retrieval recall for a real accuracy gain, and we explained why instead of just reporting the win.
Basis: see the Verified Results page for the full numbers and caveats.
An RL-trained policy decides what to remember
ADD / UPDATE / DELETE / NOOP isn't a set of hand-written if-statements — it's a GRPO-trained policy, evaluated against a rule-based baseline with the comparison published, small sample size and all.
Basis: memory_manager/train_grpo.py, trained and evaluated on real GPUs.
Retrieval you can trace, not just a similarity score
Queries are matched against extracted triples, then expanded across the graph with personalized PageRank — every answer traces back to specific facts, not an opaque embedding distance.
Basis: retrieval/query_match.py + retrieval/ppr.py; exposed directly via the get_graph tool.
What's actually running underneath
HippoRAG-style retrieval (query matched directly against triples, then diffused across the graph with personalized PageRank) + a LightRAG-style dual-layer incremental graph (entities and relations extracted and merged incrementally, never rebuilt from scratch) + a lightweight GRPO-trained policy for memory management. In a landscape split into consumer cross-app memory, developer memory infrastructure, and enterprise memory governance, Spomory sits in the developer-infrastructure layer and is actively extending into consumer cross-app use — it does not currently address enterprise governance (multi-user permissions, SSO, compliance workflows).
Read the full technical methodology on GitHub →What isn't here yet
Being specific about what's still missing is part of how this project is run, not an afterthought bolted onto a marketing page.
- Not listed in Anthropic's official Connector Directory yet, or on ModelScope's / Cursor's marketplaces — OAuth is deployed and working, submission is a separate step that hasn't happened.
- No bi-temporal queries — you can see when a fact was recorded, not separately "what the system believed at the time" vs. "what's actually true now."
- The GRPO policy is trained on 140 real samples — real gradient signal, but not yet enough data to call the advantage durable.
- Billing is a skeleton (auth, quotas, a Stripe webhook stub) — no live payment processing, so pricing below is a waitlist, not a checkout.
- No web app for browsers that don't speak MCP — ChatGPT's or Gemini's web UIs aren't reachable yet, only MCP-capable clients are.