Connecting to the grid…
Every idle computer on Earth.
One machine.
Devices enroll and become nodes of one computer — the body. Their pooled RAM becomes one addressable memory — the RAM. Capacity can be held and drawn down like a strategic asset — the vault.
Nodes online
CPU cores fused
Memory online
Ops / sec · p50
How it works
Three steps, one machine
A device joins
Open /join in any browser, or run one command on a server. The device reports its real cores and pledges a slice of RAM or disk. It is now a node — a cell on the die.
Resources fuse
Pledged memory becomes one pool, sharded into 4 MB chunks with every chunk stored on two different nodes. Close a laptop — your data survives on its replica.
You address it
One API: allocate, write, read, free. Run compute jobs that shard across every CPU in the grid. Reserve capacity ahead of time and watch it draw down as you use it.
The memory ladder
One pool, four tiers.
Price follows physics.
A hierarchy with real silicon lineage — accelerator HBM at the top, then DRAM, then a CXL/Optane-class spillover rung, then NVMe. Choose a tier explicitly, or ask for auto and MemoryOS manages placement for you: hot data climbs the ladder, idle data sinks to cheaper rungs — real chunks, physically migrating between real machines. Each rung shows its genuinely online capacity and measured latency — if nothing is online, we say so.
Allocate memory nowAccelerator memory
GPU / NPU-attached · WebGPU device buffers
no capacity online
Server DRAM
RAM from browser tabs & daemon nodes
no capacity online
CXL expansion memory
Pooled expansion · spillover RAM class
no capacity online
NVMe storage
Disk-backed capacity from daemon nodes
no capacity online
Layer 1 — The Grid · Every chip, one computer
The body: real devices, one die
Every lit cell is a physical device connected right now — a browser tab, a laptop, a server daemon. It reports its true core count and heartbeats every five seconds. Close the tab and the cell goes dark within moments, everywhere, live.
- → Join from a browser in one click — no install
- → Or run
node agent.js --ram 2GB --disk 10GBon any server - → Nodes execute real jobs on their real CPUs
No nodes online — join the grid to light up a cell
# S3 for RAM — three calls and your bytes live in the grid
$ curl -X POST /api/v1/mem/alloc -d '{"bytes":104857600,"tier":"auto"}'
→ {"allocId":"m_9f2…","tier":"dram","replicationFactor":2}
$ curl -X PUT /api/v1/mem/m_9f2… --data-binary @file.bin
→ {"latencyMs":17.2,"nodes":["n_0650…","n_b41e…"]}
$ curl /api/v1/mem/m_9f2… # works even if a node died
→ X-OM-Latency-Ms: 31.4 · X-OM-Served-By: n_0650…
Layer 2 — The Memory · Infinite memory for everything
The RAM: one address space over everyone's memory
Your bytes are sharded into chunks and each chunk lives on two different nodes. Reads come from the fastest live replica and every response tells you the truth: measured latency, which node served it, which tier it came from. Billed per GB-second of actual occupancy.
Why it matters — the KV-cache problem: AI models pile up huge temporary context caches. When fast memory fills, you either buy more accelerators or recompute context — both expensive. MemoryOS decides automatically: hot data is promoted up the tier ladder, idle data physically migrates down to cheaper rungs. The model never forgets; you never overpay.
- → Replication factor 2 — a vanishing node loses nothing
- → MemoryOS: automatic promote/demote across the ladder
- → Four tiers, one API — from GPU memory to NVMe
Layer 3 — The Reserve · Fort Knox for compute
The vault: capacity as a strategic asset
Countries stockpile oil and gold; the next reserve is compute. Lock in GB-seconds of any tier while the capacity exists. The ledger draws down in real time against your actual usage — metered every five seconds. Reservable capacity is computed truthfully from what's online, so overbooking is rejected, always.
- → API-key accounts, per-tier balances, billed per GB-second
- → Emergency release: open the vault and the capacity is guaranteed — unreserved tenants are evicted to honor it
- → Ask for more than the grid holds → HTTP 409
Reservable right now (usable capacity at ×2 replication)
Blue = already reserved. Recomputed live from connected nodes.
Plain-English FAQ
What actually happens when I click “Join the Grid”?+
Your browser opens a live connection to the coordinator, reports how many CPU cores it really has, and sets aside a slice of RAM you choose (held as real ArrayBuffers in the tab). From that moment your device can store other people's data chunks and run small compute tasks. Close the tab and you leave the grid instantly.
Is any of this simulated?+
No. Every node on the dashboard is a live connection. Every byte you store genuinely lives in the RAM (or disk) of enrolled devices. Every latency number is measured on the request you just made. When a tier has no capacity, the site says “no capacity online” instead of pretending.
What happens to my data if a device turns off?+
Every chunk of your data is stored on two different nodes. If one vanishes, reads are served by the survivor, and the system automatically copies the chunk to a new node to restore the safety margin.
What are the four tiers?+
They're rungs of speed and price. Accelerator memory (GPU-attached) is fastest and most expensive; Server DRAM is ordinary RAM; CXL expansion is a slower spillover class of RAM; NVMe is disk-backed — cheapest and slowest. DRAM and NVMe are live today; the other rungs light up whenever a node truthfully offers them.
What is the Reserve, in one sentence?+
It's Fort Knox for compute: you lock in GB-hours of a tier while the capacity is online, and your balance ticks down only as you actually use the pool.
Can I use it from code?+
Yes — it's a plain REST API with API keys. Create a key, then alloc / write / read / free with curl or any HTTP client. The Docs page has copy-paste examples that run against this very instance.
Still curious? Read the full explainer →