NNyquest docs

Recall and Surfacing

How memories actually reach the model — the search, the ranking, the injection, and how to read the recall indicator.

The recall pipeline (per message)

When you hit Send:

  1. Embed your draft message — the recall service computes an embedding (~10-30ms)
  2. Search the recall_chunks index — top-K most similar chunks, where K defaults to 3-5
  3. Filter by similarity threshold — chunks below the threshold are dropped (avoids irrelevant noise)
  4. Filter by recency boost — recent chunks rank higher than equally-similar old ones
  5. Inject as system context — the survivors are formatted as a small system message and prepended to your conversation

The model never sees raw embeddings; it sees a short, human-readable block of context like:

[Relevant context from prior conversations:
- User is a backend engineer working in Rust
- User prefers concise replies under 200 words
- User mentioned they are migrating from MongoDB to Postgres]

This injection happens per message, not per conversation. Different messages in the same conversation can recall different chunks based on what each message is about.

Short messages skip recall

Semantic recall does not run on messages shorter than 4 words. "yes", "do it", "and the other one?" are too short to embed usefully, and searching on them returns noise, so the search step is skipped.

Skipped means only the semantic search is skipped. The model still gets the recent messages in the conversation, the conversation summary, and your durable facts.

There is no recall on/off control anywhere in Settings. Recall always runs, and the short-message gate is the only case where it doesn't. If you are checking whether the model remembers something, ask in a full sentence — "remind me which stack I'm using?" recalls, "my stack?" doesn't.

The recall indicator

In some chassis (notably Ridgeline and Apsis), assistant replies show a small badge:

💭 3 facts recalled

Click it to see exactly which facts surfaced for that reply. This transparency matters — if recall surfaces something stale or wrong, you want to know.

In other chassis the badge is hidden but the recall still happened. We're rolling out the indicator across more chassis incrementally.

What recall is good at

  • Continuity across conversations — picking up where you left off without re-explaining
  • Cross-project context — a fact extracted in one project surfaces in another if relevant
  • Implicit references — saying "the project" works because recall pulls in which project you mean
  • Style consistency — "user prefers terse replies" surfaces and the model honors it

What recall is NOT good at

  • Exact retrieval — if you need the specific contents of a past message, search the conversation list, don't rely on recall
  • Bulk recall — recall surfaces top-K chunks (typically 3-5), not "everything you've said about X"
  • Time-sensitive facts — "what was the price last week?" is not how recall works
  • Code recall — code is better stored as artifacts than recalled as facts

Project scoping

Inside a project, recall is biased toward chunks from that project's conversations:

  • Same-project chunks: weighted higher
  • Cross-project chunks: still surface if highly relevant
  • Global chunks (not in any project): also surface based on similarity

This means:

  • Personal vs work projects don't accidentally mix on routine recalls
  • A fact you really want recalled across projects (like "user prefers concise replies") still surfaces because it's relevant to most messages

If you want strict per-project memory scoping (no cross-project recall ever), it's not yet a setting but on the roadmap.

Tuning recall behaviour

Recall has no on/off switch — it always runs, except on messages under 4 words. What you control is the facts it ranks over, in Settings → What Nyquest remembers:

  • Pin a fact. It never decays, is exempt from the daily consolidation pass, and is prioritised in recall.
  • Forget a fact. That one fact is removed permanently and stops surfacing. Nothing else is touched.
  • Confidence. Each fact carries a score that rises when you re-affirm it and falls when you contradict it, and recall ranking uses it. Correcting the model in conversation moves a wrong fact down the ranking over time.

Coming:

  • Adjust K (how many chunks to recall)
  • Adjust similarity threshold (looser = more recall, tighter = stricter)
  • Per-project scope toggle

Performance notes

Recall typically adds 50-150ms to message latency. The embed call to your provider (or platform-hosted) is the bulk of that; the DB query is sub-10ms.

If recall is slow:

  • Embedding model issues at the provider — recall falls back to "no recall" rather than blocking the message
  • Database under load — extremely rare, the recall index is small per-user

If recall consistently fails (returns 0 chunks when you expect some):

  • Your message was under 4 words — the short-message gate skipped semantic recall; rephrase it as a full sentence
  • The chunks might not exist yet — recall builds up over your first few conversations
  • The similarity threshold might be filtering everything out — this is rare with default settings

Where to next