recall

Recall past memories related to a query — semantic by default. Finds relevant memories even when the query shares no words with what was stored.

Signature

recall({ query: string }) → {
  mode: 'semantic' | 'keyword',
  results: Array<{ id, text, created_at, score }>,
  keyword_extra?: Array<...>
}

The default limit is 10. Lower-scoring matches are dropped.

Example

MCP:

> recall what we know about how user data is stored

REST:

curl -X POST https://mneva.dev/v1/recall \
  -H "x-mneva-key: $MNEVA_KEY" \
  -H "content-type: application/json" \
  -d '{"query":"where does user data live"}'

Response on a test brain that had stored "we use Postgres 15 for the user database":

{
  "mode": "semantic",
  "results": [
    {
      "id": 2,
      "text": "we use Postgres 15 for the user database",
      "created_at": "2026-05-23T00:14:00+00:00",
      "score": 0.5919
    },
    {
      "id": 3,
      "text": "auth flow uses session cookies, not JWT",
      "created_at": "2026-05-23T00:14:00+00:00",
      "score": 0.4141
    }
  ],
  "keyword_extra": []
}

The Postgres memory was top despite the query containing none of its words. That's semantic recall doing its job.

Reading scores

score is raw cosine similarity (-1 to 1). Higher = closer. As a rule of thumb on short queries against this embedding model:

• 0.70+ — genuinely on-topic
• 0.55 - 0.70 — related register, sometimes useful
• 0.40 - 0.55 — same domain, weak relevance
• < 0.40 — noise

mode tells you which path served the result:

• semantic — Ollama was up; cosine ranking.
• keyword — Ollama was down; case-insensitive LIKE fallback.

keyword_extra lists keyword-matched memories that predate the embedding column (rare; only old self-hosted installs).

See also

• remember
• recall_dreams — surfaces unprompted overnight thoughts
• Memory — concept