Retrieval
How Hivemind decides what reaches the model.
Retrieval is the part that matters. Storing things is easy; choosing what to send, and what to leave out, is where a memory layer either saves you tokens or costs you them.
Two searches, then a decision
Every query runs a keyword search and a meaning-based search at the same time, and the results are fused so that something both agree on outranks either one's favourite.
What happens next is what decides whether the result is worth sending:
Results that fall away sharply from the best match are dropped. If nothing is close enough, nothing is returned, an empty payload is the right answer to a question your memory has no bearing on.
You give a token budget; the most valuable set that fits inside it is chosen. Not the top ten, whatever they happen to cost.
Models read the beginning and end of a long context far more reliably than the middle, so memories are placed accordingly rather than in rank order.
The same memories are shaped differently for a tool that expects structured context than for one that expects prose.
Controls
budget | Hard token ceiling for the result |
threshold | Relevance floor, 0–1. Higher is stricter |
limit | Cap on the number of memories |
searchMode | Search stated memories, uploaded documents, or both |
filters | Narrow by your own metadata |
rerank | Cross-encoder re-scoring, on by default. Costs ~100ms; pass false to skip it |
rewriteQuery | Also search alternative phrasings of the question |
See the SDK reference for how to pass them.
Seeing the decision
The dashboard's Retrieval view runs a query exactly as a connected tool would and shows what came back, what was discarded, what the payload costs, and what filtering saved.
It is worth trying with a question your memory cannot answer. Getting nothing back is the feature.
Profiles
Some facts should colour every response, how you like your code, what you are shipping this week, and no particular query is ever about them, so search is the wrong tool.
The Profile view collects them: stable traits on one side, current work on the other. Stable is not guesswork; it is what has actually been retrieved often enough, across enough threads, to have earned the label.