friday deploys — then open
the result marked fading.
the dashboard doing its job, recorded. Open this page on
a laptop to drive it yourself.
open full screen ↗
iai-pme is a memory that lives on your own computer. It keeps what you said, word for word, and hands the right piece back to your assistant before you have to repeat yourself.
Five things happen. You do none of them.
Nothing about your habits changes. No commands to learn, no "remember this", no "save that for later". You work the way you already work.
In the background, every message is written down — yours and the assistant's — exactly as it was typed.
Other tools ask a model to summarise your session and keep the summary. That is cheaper, and it loses the one sentence you actually needed — usually the specific one, with the number in it.
Here the original wording is kept and never rewritten. Months later you get back the sentence, not somebody's impression of it.
When your machine is idle, the engine goes back over what piled up. It groups related moments, notices what keeps coming back, and turns repeated patterns into something shorter it can reach for quickly.
It also lets go of noise. What you never touch again fades — unless you pinned it, and then it stays for good.
You open a new conversation and the assistant already knows what matters: the decisions you made, the rules you set, what broke last time and why.
This happens twice — once when the session starts, and again before each message, so what arrives is what this question needs rather than a dump of everything.
You once said deploys go out on Friday. After a bad night you decided Tuesday. Ask about deploys now and you get the current rule — and a note that it replaced an earlier one, which is still there if you want to read it.
Nothing is quietly overwritten. This is the part that stops an assistant from confidently telling you something you stopped believing months ago.
Every message of every session, exactly as written.
What it works out from those moments while your machine is idle.
How you like to work, applied without being asked.
What you decided must never fade. It never does.
Most memory projects are a thin wrapper around somebody else's vector database and somebody else's graph library. This one is not. There is no database to install, no cloud service to sign up for, and nothing to run alongside it — because the pieces doing the work were written for this exact job:
Keeps the records, the search index and the connections between memories in one encrypted file on your disk. Our own engine, not a database we wrapped.
Works out which memories belong together, so recall spreads through the right neighbourhood instead of the whole store. Written to be light enough to run through your whole memory every night.
Gives moments, knowledge and habits different internal shapes, which is what lets you find a memory by its shape and not only by its wording.
The embedder and the graph work run as native code. This is where the speed comes from, and why recall feels instant on a laptop.
Being honest about what we did not build: we did not write our own encryption, our own maths library or our own tensor kernels. Those sit on boring, audited, permissively licensed pieces, on purpose. Inventing your own crypto is how you lose someone’s data.
The reason for building the rest ourselves is that the hard case is not size, it is change. A memory that has to stay exact while it is rewritten every night, questioned on every message and never allowed to lose the old version of a fact is a different machine from a vector store you fill once and read from.
One person on one laptop is where that engine is proving itself, not the ceiling it was built for. The same core is what a whole company runs on next: every engineer’s machine feeding one brain that remembers all of it and answers from any seat. This is the first floor of that building — which is exactly why the foundation is ours and not rented.
None of this was designed by taste. Every mechanism in the engine comes from a field that already studied the problem, and the people who did that work are named below, so you can go and read the same papers we did.
Marr 1971 · McClelland, McNaughton & O’Reilly 1995 · Wilson & McNaughton 1994 · Nader, Schafe & LeDoux 2000 · Raichle et al. 2001
Human memory does not have one store. It has a fast one that records today and a slow one that keeps what matters, and the fast one hands over to the slow one during sleep — the complementary-systems account that McClelland, McNaughton and O’Reilly set out in 1995, building on Marr’s 1971 theory of the hippocampus. That is the shape of this engine: everything lands in the fast store immediately, and a nightly pass moves the durable parts across. The rest of the night’s work comes from the same field — replaying related episodes together, as Wilson and McNaughton observed happening during sleep; reopening an old memory when something new touches it, which is Nader and LeDoux’s reconsolidation; and idle-time reflection, the default mode Raichle described.
Traag, Waltman & van Eck 2019 · Traag, Van Dooren & Nesterov 2011
Memories are not a list, they are a graph, and a graph has neighbourhoods. We did not start by writing our own way to find them — that would have been arrogant. We started where anyone would, with the best-known published method in the field, and we tried it on the real thing.
It did not survive contact with our conditions. Not because the method is wrong — it is excellent at the job it was designed for — but because that job is not this one. It is built for a large graph you cluster occasionally and then read from. Ours is a small graph rebuilt from scratch every single night, on somebody’s laptop, inside the hours they are asleep. Three things broke:
Every night produced strangers. Cluster the same memory twice with a few days between and you get two unrelated sets of groups with fresh arbitrary labels. Nothing carries over. For a memory that is supposed to have continuity, that is fatal — “the pricing cluster” has to still be the pricing cluster next week, with a history you can ask about.
Somebody had to keep tuning it. How coarse or fine the grouping comes out is a number a human picks, and it needs re-picking every time the data shifts. Nobody is going to hand-tune a parameter on a laptop at three in the morning, every night, forever.
It had no concept of running out of time. It optimises until it converges. We get the idle window and not one second more, and we have to hand back a good grouping when that window closes rather than a perfect one eventually.
So we built MOSAIC instead: communities that keep their identity across every pass, split and merge; resolution that settles itself against several competing goals; and a hard wall-clock budget baked into the design rather than bolted on. It answers the same question, and it is a different machine.
One thing did come through from that reading, and we name it because it is theirs: the measure of what makes a good grouping — the CPM objective published by Traag, Van Dooren and Nesterov in 2011, and carried into the Leiden method by Traag, Waltman and van Eck in 2019. The yardstick is theirs and the credit for it stays theirs. What runs against it every night is ours.
Five things happen. You do none of them.
Nothing about your habits changes. No commands to learn, no "remember this", no "save that for later". You work the way you already work.
In the background, every message is written down — yours and the assistant's — exactly as it was typed.
Other tools ask a model to summarise your session and keep the summary. That is cheaper, and it loses the one sentence you actually needed — usually the specific one, with the number in it.
Here the original wording is kept and never rewritten. Months later you get back the sentence, not somebody's impression of it.
When your machine is idle, the engine goes back over what piled up. It groups related moments, notices what keeps coming back, and turns repeated patterns into something shorter it can reach for quickly.
It also lets go of noise. What you never touch again fades — unless you pinned it, and then it stays for good.
You open a new conversation and the assistant already knows what matters: the decisions you made, the rules you set, what broke last time and why.
This happens twice — once when the session starts, and again before each message, so what arrives is what this question needs rather than a dump of everything.
You once said deploys go out on Friday. After a bad night you decided Tuesday. Ask about deploys now and you get the current rule — and a note that it replaced an earlier one, which is still there if you want to read it.
Nothing is quietly overwritten. This is the part that stops an assistant from confidently telling you something you stopped believing months ago.
Every message of every session, exactly as written.
What it works out from those moments while your machine is idle.
How you like to work, applied without being asked.
What you decided must never fade. It never does.
Most memory projects are a thin wrapper around somebody else's vector database and somebody else's graph library. This one is not. There is no database to install, no cloud service to sign up for, and nothing to run alongside it — because the pieces doing the work were written for this exact job:
Keeps the records, the search index and the connections between memories in one encrypted file on your disk. Our own engine, not a database we wrapped.
Works out which memories belong together, so recall spreads through the right neighbourhood instead of the whole store. Written to be light enough to run through your whole memory every night.
Gives moments, knowledge and habits different internal shapes, which is what lets you find a memory by its shape and not only by its wording.
The embedder and the graph work run as native code. This is where the speed comes from, and why recall feels instant on a laptop.
Being honest about what we did not build: we did not write our own encryption, our own maths library or our own tensor kernels. Those sit on boring, audited, permissively licensed pieces, on purpose. Inventing your own crypto is how you lose someone’s data.
The reason for building the rest ourselves is that the hard case is not size, it is change. A memory that has to stay exact while it is rewritten every night, questioned on every message and never allowed to lose the old version of a fact is a different machine from a vector store you fill once and read from.
One person on one laptop is where that engine is proving itself, not the ceiling it was built for. The same core is what a whole company runs on next: every engineer’s machine feeding one brain that remembers all of it and answers from any seat. This is the first floor of that building — which is exactly why the foundation is ours and not rented.
None of this was designed by taste. Every mechanism in the engine comes from a field that already studied the problem, and the people who did that work are named below, so you can go and read the same papers we did.
Marr 1971 · McClelland, McNaughton & O’Reilly 1995 · Wilson & McNaughton 1994 · Nader, Schafe & LeDoux 2000 · Raichle et al. 2001
Human memory does not have one store. It has a fast one that records today and a slow one that keeps what matters, and the fast one hands over to the slow one during sleep — the complementary-systems account that McClelland, McNaughton and O’Reilly set out in 1995, building on Marr’s 1971 theory of the hippocampus. That is the shape of this engine: everything lands in the fast store immediately, and a nightly pass moves the durable parts across. The rest of the night’s work comes from the same field — replaying related episodes together, as Wilson and McNaughton observed happening during sleep; reopening an old memory when something new touches it, which is Nader and LeDoux’s reconsolidation; and idle-time reflection, the default mode Raichle described.
Traag, Waltman & van Eck 2019 · Traag, Van Dooren & Nesterov 2011
Memories are not a list, they are a graph, and a graph has neighbourhoods. Finding them is a studied problem, and the modern standard is the Leiden method of Traag, Waltman and van Eck (2019), scored with the CPM objective from Traag’s earlier 2011 work. That objective is the piece of published science we have in common with them, and the credit for it is theirs.
What clusters your memory every night is not that algorithm. It is ours, and it is a different machine — because our problem is one the standard was never asked to solve. Three differences carry the weight:
Communities keep their identity. Run ordinary clustering twice on a slightly changed graph and you get two unrelated sets of groups with fresh arbitrary labels. Ours tracks every community across every nightly pass and through every split and merge, so “the pricing cluster” is still the same thing next week and its history is something you can ask about. Standard implementations have no notion of this at all.
It settles its own resolution. How coarse or fine the grouping should be is normally a number a human picks, and re-picks whenever the data shifts. Ours decides that itself against several competing goals at once, every cycle — because nobody is going to hand-tune a parameter on a laptop at three in the morning.
It is built to run out of time. Clustering here has a hard wall-clock budget: it gets the idle window and not a second more, and it has to hand back a good grouping when that window closes rather than a perfect one eventually. That single constraint shapes the whole design, and offline graph tooling does not have it.
Same question as theirs, same scoring function, an entirely different answer to how you compute it under these conditions. We name them because that is how honest engineering reads — you say whose shoulders you stand on, then you say plainly what you built yourself.
Kanerva 1988, 2009 · Plate 1995 · Gayler 2003
Pentti Kanerva’s sparse distributed memory, and the wider vector-symbolic tradition that Tony Plate and Ross Gayler shaped, represent things as very wide patterns you can combine and compare whole. It is why a moment, a piece of knowledge and a habit can share one store without collapsing into the same mush, and why you can find a memory by its shape and not only by its words.
Shannon 1948
Not every gap in what it knows is worth asking about. Shannon gave us the measure of how much an answer would actually tell you, and the engine uses it to decide which few questions are worth keeping. Without that measure, a system that notices its own gaps would bury you in them.
Wiener 1948 · Ashby 1952, 1956 · Pask 1975, 1976
An old and unfashionable field that got there first. From W. Ross Ashby comes the idea that a system stays alive by holding a few essential variables inside survivable bounds — which is exactly what the engine watches while it reorganises itself, rather than optimising one number into the ground. From Gordon Pask comes something we use almost literally: his teach-back, where understanding is demonstrated by explaining a thing back and being corrected where the explanation fails. After each consolidation the engine attempts precisely that on its own conclusions and flags what does not hold together. Wiener named the field in 1948; it deserves more than nostalgia.
Murray, Lesser & Lawson 2005
This is where the name comes from, and it is a design decision, not a metaphor. Monotropism — the account of attention Dinah Murray, Mike Lesser and Wenn Lawson published in 2005 — describes deep narrow focus rather than shallow broad attention, and that is how recall here behaves. The exact words instead of the gist. Rare things kept rare instead of averaged away. Most memory systems are built to generalise; this one is built to be literal — which is precisely what you want from something that has to remember what you actually said.
Credit where it is not ours in any sense: the text embeddings come from the openly published bge-small-en-v1.5 model, the encryption is a standard audited implementation, and the numerical libraries underneath are other people’s excellent work. We name all of it in the repository.
Two honest caveats. These are working principles borrowed from the science, not a claim to be a brain — no serious person building software should say otherwise. And a good story about mechanism proves nothing by itself, which is why everything here is measured, and why the numbers and the tests that produced them ship in the repository.
No account, no sign-up, no API key of ours, no analytics. The memory is an encrypted file in your home folder. Everything is worked out on your own machine, and the only thing that goes to the internet is the model call your assistant was already making.
Want it gone? Delete the folder. That is the entire deletion story.
You do not have to wait for it to learn from conversations. Drop a file on the dashboard — notes, a runbook, a PDF, a spreadsheet — and it reads the file, breaks it into pieces and connects those pieces to what it already knows. Nothing is stored twice.
That one line brings the engine, the dashboard and the connector your assistant talks to. Claude Code users then install a plugin and are finished; any other assistant that speaks the standard connector protocol takes one more line. macOS and Linux are fully supported, Windows is in beta.
Free and open source under MIT. There is no paid tier to graduate to.
A side effect worth knowing about. When an assistant does not remember something it goes looking — reads files, searches the repository, spends thousands of tokens rebuilding a fact you already gave it. Handing it that fact from memory instead costs about 88% less.
The dashboard keeps your own count, live: how often memory answered instead of a search, and what that saved you.
Nothing on this page is something you have to take on faith. The benchmarks live in the repository. Clone it and run them yourself.
| What was measured | Result | Command |
|---|---|---|
| Finding the right memory | R@5 0.962 | python -m bench.longmemeval_blind |
| A replaced fact is still reachable | 1.000 | python -m bench.contradiction_longitudinal |
| Its original wording survives | 1.000 | python -m bench.contradiction_longitudinal |