Apache-2.0 · local-first · no account

Virtual memory for an
LLM's attention

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.

$pip install aether-context
$npx aether-context setup

Runs with no daemon, no network and no model pulled — setup verifies against a built-in mock model.

Terminal recording: npx aether-context setup sizes a 5 GB pool, doctor reports four green checks, status prints pool, reach and resident RAM.
A real session, captured unedited: guided setup, a clean doctor check, pool status.
~1.16Btokens of reach from a 5 GB pool
0.15 → 1.00recall of early facts, engine off vs on
−24%session cost, same work
100%on your machine, offline

Long runs die the same way

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.

It's virtual memory, for attention

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.

RAM → the resident window

What the model can see right now. Small and fast, exactly as it always was.

Disk → the context pool

Your encoded memory. ~5 GB ≈ ~1B tokens, sitting on your own drive.

Pager → the slice loader

Embeds what the model is reasoning about this second and prefetches the matching slices.

Page replacement → retention

Useful slices stay, stale ones fade, anything relevant again comes back.

Measured, not asserted

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.

MetricOffOnChange
Recall of early facts0.151.006.7×
Tasks done right3 / 2020 / 203 → 20
Cost, full session$0.0711$0.0542−24%
Cost, recall phase$0.00117/t$0.00053/t−54%
Two charts: cumulative cost per turn and recall coherence per turn, engine off versus on.

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 →

Disk in, reach out

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.

PoolSlicesReachIndex RAMSessions on 8 GB
5 GB (floor)2.27M~1.16B~146 MB~13
10 GB4.55M~2.33B~291 MB~7
15 GB6.82M~3.49B~436 MB~4
20 GB9.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.

Honest about the word "unlimited"

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.

Give the model you already run a longer memory

Two commands, no account, nothing leaves your machine.