The whole thing, explained from zero

You don't need to know anything about distributed computing. Ten minutes here and you'll understand exactly what this machine is, what's real, and how to use it.

The idea

Most computers are asleep at their desks

Right now, billions of devices are powered on and doing almost nothing. Their processors idle. Their memory sits empty. Exa RAM takes those idle slices and fuses them into a single computer that anyone can address through one API.

It has three layers, and each has a one-word metaphor we use everywhere: the Grid is the body, the Memory is the RAM, and the Reserve is the vault.

Layer 1 — The Grid

The body: devices become nodes

When you open /join and click the button, your browser opens a persistent connection (a WebSocket) to the coordinator. It reports the number of CPU cores your device really has and sets aside the amount of RAM you chose. That memory is allocated immediately, for real — your operating system's task manager will show it.

From then on your device is a node: a cell of the machine. It answers a heartbeat every five seconds, stores chunks of other people's data, and runs small compute tasks. Close the tab and the machine notices within moments; your cell goes dark on every dashboard, live. Servers can join too, with one command:node agent.js --ram 2GB --disk 10GB— that daemon contributes RAM and disk space as a slower storage tier.

Layer 2 — The Memory

The RAM: one pool made of everyone's memory

Here's the flagship trick. All that pledged memory becomes one pool you can allocate from, like ordering storage from a cloud — except the "cloud" is the laptops and servers enrolled around you. You say "give me 100 MB," write your bytes, and read them back later. Under the hood:

Sharding. Your data is cut into 4 MB chunks spread across nodes.
Replication. Every chunk is stored on two different devices. If one disappears mid-afternoon (laptops do that), your data survives on the other, and the system quietly makes a fresh second copy on a healthy node.
Honest telemetry. Every read tells you which node served it and the measured time it took. No estimates, no averages pretending to be measurements.

The pool is tiered, like rungs on a ladder: accelerator (GPU) memory at the top — fastest, priciest — then server DRAM, then CXL-class expansion memory, then NVMe disk at the bottom. You pick a rung, or say "auto" and get the fastest one with room. Rungs with nothing online say so, plainly. Usage is billed per GB-second of actual occupancy.

MemoryOS is the reason the ladder matters. AI systems generate huge temporary context caches; keeping cold ones in fast memory wastes money, recomputing them wastes more. So "auto" allocations are managed: leave data untouched and MemoryOS physically migrates its chunks down to cheaper rungs; touch it again and it climbs back up. Every move is a real transfer between real machines, listed in a live feed with the measured time and the price difference it earned.

Layer 3 — The Reserve

The vault: capacity you can hold

If the grid is a power plant, the Reserve is its futures market. You reserve, say, 10 GB of DRAM for 24 hours — that's 240 "GB-hours" locked in your vault. As your allocations actually occupy the pool, a meter runs every five seconds and draws your balance down. Stop using memory, and the drawdown stops.

Two honesty rules make it trustworthy. First, you can only reserve what is truly online right now (counting the two-copies rule, so usable capacity is half of raw). Second, every drawdown is a visible row in your ledger. Ask for more than the grid holds and the API answers with a flat refusal — HTTP 409, overbooking rejected.

And when it really matters, the vault door opens: emergency release. Activate a reservation and its capacity becomes guaranteed — if the tier is full, the grid evicts unreserved tenants to make room, and every eviction is written to the ledger. That's the strategic-reserve idea in miniature: hold capacity in calm times, draw it with priority in a crisis.

Compute

Jobs: borrowing everyone's processors

The grid doesn't just remember — it thinks. Submit a job (count words in a big text, search for a hash, count primes) and the coordinator splits it into tasks sized by each node's core count. Browser nodes compute in an isolated Web Worker; daemons use worker threads. You watch each node's progress bar move in real time, and the partial results merge into one answer. If a node dies mid-task, its slice is reassigned.

Trust

What 'nothing is simulated' means here

Every node on screen is a live connection. Every byte you store exists in the RAM or disk of enrolled machines — kill one and reads keep working from replicas, which you can prove yourself in two browser tabs. Every latency figure was measured on the request that produced it. When capacity is zero, the UI says "no capacity online" rather than inventing a number. That's the whole covenant.

Join the Gridor read the API docs →