Apache-2.0 · local-first · no account
Keep a billion-token pool on your own disk. Your local model reaches it in slices, one small window at a time — so a long run stops quietly forgetting what it decided an hour ago.
Runs with no daemon, no network and no model pulled — setup verifies against a built-in mock model.
The model fills its window, starts compressing its own history, and silently drops the one detail that mattered three steps ago. You get the runaway PR, the function rewritten twice, the build that falls apart at hour two. A bigger window only delays it, and a crammed one rots in the middle anyway.
The fix isn't more window. It's to stop throwing the overflow away — encode it to a pool on disk, and recover the exact slice when it's needed.
Map it onto an operating system and it clicks. The pager runs while the model generates, so most of the fetch hides behind its own thinking.
What the model can see right now. Small and fast, exactly as it always was.
Your encoded memory. ~5 GB ≈ ~1B tokens, sitting on your own drive.
Embeds what the model is reasoning about this second and prefetches the matching slices.
Useful slices stay, stale ones fade, anything relevant again comes back.
One live, paid run: a reasoning model driven through a 40-turn agent session
that overflows its window — 2,000-token window, 60 real microsoft/vscode issues,
engine off vs on. $0.19, 14 June 2026. Raw artifacts are committed in the repo.
| Metric | Off | On | Change |
|---|---|---|---|
| Recall of early facts | 0.15 | 1.00 | 6.7× |
| Tasks done right | 3 / 20 | 20 / 20 | 3 → 20 |
| Cost, full session | $0.0711 | $0.0542 | −24% |
| Cost, recall phase | $0.00117/t | $0.00053/t | −54% |
Scope, honestly. That run used a hosted reasoning model, not a local one — the mechanism is backend-agnostic, but the headline number is not a local number. The 2,000-token window is deliberately tiny to force overflow, so a realistic window shows a smaller (still real) gain. N = 20 recall turns, single run. It measures the engine, not the MPO chain: on this single-fact task the chain ties plain recall, and its multi-slice edge is synthetic-only so far. Full write-up →
One number to choose. Roughly 2.2 KB per 512-token slice works out to ~233M tokens of reach per gigabyte, and RAM stays a formula rather than a mystery.
| Pool | Slices | Reach | Index RAM | Sessions on 8 GB |
|---|---|---|---|---|
| 5 GB (floor) | 2.27M | ~1.16B | ~146 MB | ~13 |
| 10 GB | 4.55M | ~2.33B | ~291 MB | ~7 |
| 15 GB | 6.82M | ~3.49B | ~436 MB | ~4 |
| 20 GB | 9.09M | ~4.65B | ~582 MB | ~3 |
Session counts are for isolated pools, and roughly double on a 16 GB machine. Share one pool instead and the index is paid once — dozens of sessions fit, with CPU as the limit rather than memory, at the cost of isolation. A bigger pool always buys reach, never more concurrent sessions.
It means reach, not attention. Your model keeps its native context window; the engine makes it reach a billion-token pool in slices, through fast retrieval. The whole thing rides on hit rate — when that's high the pool feels like one seamless context, and when it isn't, a miss looks like forgetting. That's the trade, stated plainly.
Two commands, no account, nothing leaves your machine.