Why AI Agents Need Sleep/Wake Architecture

Running AI agents in production is expensive, and not because compute is expensive. It is because the standard deployment model bills you for time your agent spends doing nothing.

The Always-On Problem

Deploy an agent on a VM or a long-running container and you are paying for 24/7 uptime against a workload that is almost all silence. A support agent might see 50 queries a day. A data agent runs hourly. A monitoring agent wakes every 15 minutes, works for four seconds, and goes quiet. At $50 to $100 per container per month, multiplied across a handful of agents, the bill stops making sense.

What Sleep/Wake Actually Is

Sleep/wake is a lifecycle, not a power setting. When the agent goes idle, the platform checkpoints the entire running process and removes it from the machine. When a trigger arrives, it restores the checkpoint and resumes execution exactly where it stopped.

1. Request arrives. A webhook, cron tick, or API call hits your agent's endpoint
2. Wake. The checkpoint is restored in under 2 seconds
3. Process. The agent handles the request with memory, history, and tool state intact
4. Sleep. After a configurable idle timeout, the agent is checkpointed and suspended

On our Firecracker hosts, "checkpoint" is literal. The hypervisor serializes guest RAM, vCPU registers, and virtio device state into a snapshot file, and the VM process exits. The host holds no memory and schedules no CPU for that agent. The agent exists as a file. Restore maps the memory back, recreates the devices, and resumes the vCPUs at the paused instruction. Open sockets inside the guest are still open. Page tables are still valid. From the agent's point of view, no time passed.

That is the difference between a restore and a restart. A stopped container that "wakes up" is actually re-executing its entrypoint: interpreter boot, import graph, reconnects, cold caches. A restored snapshot skips all of it, because the work was already done once and the result was kept.

The Economics

Take the standard case: about 100 invocations a day, 30 seconds each.

You are paying for roughly 50 minutes of daily compute instead of 1,440 minutes. The other 96.5% of the day your agent is a few hundred megabytes on disk, and disk is nearly free.

When Always-On Makes Sense

Sleep/wake has one honest cost: the first request after an idle period pays for the wake. We measured that at a median of 674 ms on Firecracker. Behind a webhook or a cron job it is invisible. On the first message of a real-time chat it is noticeable. If your agent needs sub-100ms first-byte latency or sustains hundreds of concurrent requests, run it always-on; on Maritime you just tell the agent to never sleep.

For everything else, the math points one way.

Getting Started

Maritime manages the lifecycle automatically. Create the agent, wire your triggers, done.

maritime create my-agent --template openclaw
maritime deploy my-agent

Your agent gets an endpoint, sleeps when idle, and picks up mid-thought when the next request lands.