Architecture
Most memory systems keep every vector hot forever and answer with whatever looks similar, even when the fact has changed. Oort closes facts that change and moves memories between three tiers, so answers stay correct and the cost stays flat as history grows.
| Tier | Precision | Storage | Latency |
|---|---|---|---|
| Photosphere Hot · in the moment | 512-dim int8 vectors | Recent and pinned memories, kept ready | No search neededTargetunder 15 ms in the cloud |
| Kuiper Belt Warm · remembered | 512-dim int8 vectors (binary quantization is Planned) | SQLite with FTS5 (BM25) keyword index plus vectors | Keyword p95 4.9 ms · vector p95 19.8 msTarget30 to 80 ms in the cloud |
| Oort Cloud Cold · long ago | No vector kept (text, stub and entities stay) | zstd-compressed blob (object storage in the cloud is Planned) | Not measured separately yetTarget80 to 180 ms in the cloud |
Measured on a laptop with the local SQLite engine and 10,000 memories. Vector recall used a stand-in embedder, so it leaves out the embedding API round trip. Cloud numbers are targets, not measurements.
When a fact changes, the old one is closed with a validTo date and linked to the fact that replaced it. Outdated answers do not leak into recall.
Recently used memories get a small boost from ACT-R activation, at most 5% of the ranking. A boost never re-admits a closed fact.
oort explain <id> shows why a memory was returned, so you can check it and forget it if it is wrong.
Tiers say how warm a memory is. Planned spaces (Star, Constellation, Galaxy, Planet) say whose it is. Planned
UserPromptSubmit · read hook
Runs before the prompt is sent
Stop · write hook
Queued and async, never blocks the chat
# install, then connect your agents npm i -g oortmem oort setup # search memory oort recall "what shoes should I suggest?" # see why a memory was returned oort explain <id> # forget one memory oort forget <id> # look around oort inspect
An SDK for code is Planned, and so is binary quantization of vectors.