Your AI agent.
$2/month.

Your agent is always running. But it's idle 99% of the time — maybe 20–50 messages a day, 15 seconds each. That's 12 minutes of wall-clock time out of 1,440 in a day. 0.87% utilization.

But even that overstates it. Of those 15 seconds per message, maybe 100ms is actual CPU — the rest is waiting 1–10 seconds on an LLM API call. While your agent waits on Claude, hundreds of other agents can use that CPU. Your real CPU footprint is about 3 seconds per day. 0.003%.

Every other host charges you for a dedicated container running 24/7. They pay for resources your agent isn't using. That's why they charge $15–$24/month.

Ever let a laptop run out of battery? It hibernates — writes everything to disk, powers off. When you plug it back in, it reloads from disk and picks up where you left off. Ten years ago this took minutes and you'd lose your place. Now it takes microseconds and you barely notice. That's what we do with your agent. When it's idle, the kernel writes its memory to NVMe. When a message arrives, it pages back in and keeps going. Same trick your laptop already uses. You're already trusting it every day.

We just do it faster — NVMe, not a spinning laptop drive — and the reload is hidden behind an AI that takes seconds to think anyway. How it actually works →

One bare metal server. Thousands of always-on agents. The economics work because physics works.

All channels included. No tiers. No upsells. WhatsApp is not a premium feature — it's the default.

xCloud: $15/month. DigitalOcean: $24/month. Hostinger: $5/month. AWS Lightsail: $7/month. They all run dedicated containers that bill you for resources your agent isn't using.

We charge $2/month because idle memory swaps to disk and costs us almost nothing. A ~20μs page fault is invisible next to a 2–10 second AI response. We're not subsidizing your account. We're not burning VC money. The unit economics just work when you stop paying for idle RAM.

Their smallest plan costs more than 7x what we charge. For the same thing.

Every process thinks it has the entire machine to itself. That's the illusion. Your agent sees a flat, contiguous address space — gigabytes of it — but none of it is real. Every address is virtual. The CPU translates it to a physical location on the fly, through a structure called a page table managed by the kernel.

The kernel divides all memory — virtual and physical — into 4KB pages. When your agent reads address 0x7f3a00, the CPU looks up which physical 4KB page that virtual address maps to. If the mapping is cached in the TLB, it takes ~1ns. If not, the CPU walks the page table in DRAM — four levels deep on x86-64 — which takes ~100ns. And if the page isn't in RAM at all? The CPU raises a page fault, the kernel loads it from disk, and execution resumes. The process never knows the difference.

This is how swap works. It's not a hack. It's the original design. Virtual memory was invented in 1962 specifically so the OS could move pages between RAM and disk transparently. Every program you've ever run has relied on this. The kernel decides what's in RAM and what's on disk based on what's actually being used. Swap is just virtual memory doing what virtual memory was built to do.

The intuition is that swapped memory is slow. It is — a page fault to NVMe takes ~20,000ns versus ~100ns for a TLB miss to RAM. That's 200x worse. Sounds terrible.

But your CPU was never holding your entire process in silicon at once. There are two separate bottlenecks. The TLB (Translation Lookaside Buffer) caches virtual-to-physical address mappings — a typical L1 dTLB has 64–72 entries. Each entry maps one 4KB page (the smallest unit the CPU and OS use to manage memory), so only 256–288KB of pages are mapped without a TLB miss. Access anything outside those 64 pages and the CPU has to walk the page table — whether the page is in RAM or on disk. Separately, the data caches hold the actual bytes — L1d is 32–48KB, L2 is 256KB–1.25MB, L3 is a few MB per core shared. Miss in either one and you're waiting on DRAM, behind a memory controller. The rest of your process's address space — even if it's "in RAM" — isn't in silicon. It's waiting.

What matters is the working set — the pages your agent is actively touching right now. For an OpenClaw agent handling one message, that's the event loop, the HTTP client, a few buffers. Maybe 2–4MB. Those pages fault in from NVMe in the first few milliseconds and stay resident. Everything else — conversation history, skill modules, cached data — can stay on disk until it's needed. Pages that faulted in are executing while the next ones load. The CPU doesn't wait for your entire process to be resident.

And then there's the API call. Your agent formats a prompt and sends it to Claude or GPT. The response takes 2–10 seconds. That's 2,000,000,000–10,000,000,000 nanoseconds. The ~20,000ns page fault that happened three steps ago is a rounding error. It's 0.001% of the time you're already waiting.

The competitors who charge $15–$24/month are paying to keep your agent's full address space in DRAM at all times — memory the CPU isn't looking at, behind a controller it isn't talking to, for a process that's waiting on a network call. They're paying for the illusion that "in RAM" means "fast." It doesn't. Only "in cache" means fast. And cache doesn't care where the page came from.

There's one more thing nobody talks about. Since 2018, every major OS ships Spectre mitigations. Every time your agent makes a syscall — send(), recv(), read(), write() — the kernel flushes the TLB and branch predictor state on the way in and out. KPTI (Kernel Page Table Isolation) swaps the entire page table on every syscall. Your carefully warmed caches and TLB entries? Gone. Every network call, every file read, every epoll_wait() — the CPU starts cold again.

An AI agent is almost entirely syscalls. Format a prompt, send() it to the API. recv() the response. write() to the conversation log. Every one of those flushes the pipeline. The "fast" path through hot caches that in-RAM advocates imagine? It doesn't survive the first network call. By the time your agent gets a response back from Claude, its TLB is already cold — whether it was swapped or not.

Competitors pay $15–$24/month to keep your process in DRAM. But Spectre mitigations ensure the CPU forgets about it dozens of times per request anyway. They're paying for warm RAM behind a cold TLB. We skip the pretense and let the kernel page it in when it's actually needed — which takes the same number of TLB refills either way.

Oh, and we write the backend in Rust — but we don't store your data there. Your data lives on NVMe, backed up to object storage. Speaking of which: S3, the backbone of "the cloud," still runs on spinning rust. Literal platters with magnetic heads seeking across oxide surfaces. Your ~20μs NVMe page fault is faster than a single S3 GET. The industry's most critical storage layer is a mechanical arm on a disk, and nobody blinks. But swap to NVMe and suddenly it's controversial.

There's one more trick. KSM (Kernel Same-page Merging) scans physical memory for identical 4KB pages and collapses them into a single copy, copy-on-write. When you're running thousands of agents on the same base image, most of their read-only pages — libc, the Python interpreter, OpenClaw's core modules — are byte-for-byte identical. The kernel notices, deduplicates them, and gives us back the RAM. One physical page, thousands of virtual mappings. We're not just swapping idle memory to disk — we're not even allocating duplicate pages for the memory that stays resident. KSM turns a thousand agents' worth of libc into one copy. The math keeps getting better.

RAM is a cache for disk. Cache is a cache for RAM. TLB is a cache for page tables. KSM deduplicates what's left. Spectre made sure none of them stay warm. It's caches all the way down, and the kernel flushes them all.