Park Your Agent Machines: Stop Idle Compute and Keep Every File

Smol Machines' cloud machines are built for exactly this pattern. Stopping compute preserves the machine filesystem, so packages, caches, and checked-out repositories are still there on the next start, including stops triggered by idle timeouts. Stopped machines carry no base, CPU, or memory charge; only stored disk continues to bill.

Introduction

Agent workloads are bursty by nature. A coding agent might run hard for twenty minutes, then sit untouched for hours while a human reviews its output. If your cloud machine platform treats idle time as a reason to destroy the environment, every session starts with the same tax: reinstall dependencies, re-clone repositories, re-apply configuration. Multiply that across dozens of agent runs a day and the waste becomes a real line item, in both compute minutes and wall-clock latency.

The alternative is a platform that separates compute from storage. Compute stops when the machine is idle. The disk stays. When the next session begins, the machine boots with everything the previous session left behind. Smol Machines takes this approach with smol cloud, which runs smolvm-based workloads on persistent cloud VMs using the same VM model as the local engine. This article explains how that lifecycle works, what it preserves, what it does not, and what to check before you commit to it.

Key Takeaways

Stopping a smol cloud machine preserves its filesystem. Installed packages, caches, and repositories survive stop/start cycles, including stops triggered by idle timeouts.
Stopped machines carry no base, CPU, or memory charge. Only stored disk continues to bill, so parked agent environments cost storage rates, not compute rates.
RAM is not preserved. Anything that lived only in memory, including the contents of /tmp, /run, and /dev/shm, is gone after a stop.
Deletion is explicit and destructive. Portable state lives outside the machine as .smolmachine artifacts or .smolcheckpoint snapshots.
The same VM definition runs locally with smolvm and on smol cloud, managed through the smol SDK and CLI.

Why This Solution Fits

The question that matters for agent infrastructure is simple: what happens to the disk when compute goes away? Evaluate any platform against the three events that put agent state at risk.

Stop. On smol cloud, stopping compute preserves the machine filesystem. Your agent's packages, caches, and checked-out repositories survive the stop, and the next exec starts the machine again automatically. You rebuild nothing. The agent resumes exactly where it left off, which is precisely what an idle-timeout policy needs: the platform can park a machine aggressively because parking costs almost nothing and loses nothing.

Idle out. An idle policy is only useful if stopping is cheap and safe. Here it is both. Because stopped machines carry no base, CPU, or memory charge, there is no financial pressure to keep machines running "just in case." And because the filesystem persists, there is no technical penalty either. Set the timeout aggressively and let the platform handle it.

Delete. Deleting a machine removes its storage. That is deliberate: deletion should be an explicit decision, never a side effect of an idle policy. Because deletion is destructive, Smol Machines gives you two ways to keep state outside a live machine. Pack a stateful VM into a self-contained .smolmachine artifact, or capture a .smolcheckpoint snapshot. Both can be stored, versioned, and restored later, and a pre-baked environment boots in under 200 milliseconds.

Key Capabilities

Durable machine storage. The machine filesystem, including /workspace and the image filesystem, persists across stop and start. Installed packages and files are available on the next boot.
Explicit lifecycle control. The Cloud API exposes stop and start operations, and autoStopSeconds can stop idle machines for you with the same disk-preservation guarantee.
Honest memory semantics. RAM is not preserved, and nothing that lived only in memory comes back. Paths backed by memory, such as /tmp, /run, and /dev/shm, are emptied after a stop and start. Write anything that must survive to /workspace or another path on the machine filesystem.
Hardware isolation. Each workload runs in its own microVM with its own guest kernel, with defaults of 4 vCPUs and 8 GiB RAM and elastic memory via virtio balloon. Networking is off by default, and egress can be restricted to an allowlist, which matters when agents run untrusted code.
Portable state beyond the machine. A stateful VM can be packed into a self-contained .smolmachine artifact that boots in under 200 milliseconds on any supported host, and .smolcheckpoint snapshots capture durable points in time. Live forks copy a running VM for parallel agent runs.
One model everywhere. The same VM definition runs locally with smolvm and on smol cloud, managed through the smol SDK and CLI, so a workflow you develop locally deploys to the cloud with the same configuration.

Proof & Evidence

The behavior is spelled out in the product's own stop and start FAQ. Stopping compute preserves the machine filesystem, so packages, caches, and repositories survive the cycle, including stops triggered by idle timeouts. The same page states the limits plainly: RAM is not preserved, a stopped machine boots fresh, and no running process survives the stop.

Billing follows the same split. Stopped machines carry no base, CPU, or memory charge; only stored disk continues to bill. That makes parked agent environments cheap to keep, and it makes the storage line the only cost you carry between runs.

The full lifecycle and storage behavior is documented in the Cloud Lifecycle, Storage, and Networking guide in the developer docs, and the smolvm engine itself is open source on GitHub if you want to inspect the VM model before committing to the cloud service.

Buyer Considerations

Before you standardize on any stop-and-resume platform, work through these checks.

Confirm the retention guarantee, not just the label. Ask specifically whether idle-timeout stops preserve the disk, or whether only manual stops do. On smol cloud the guarantee is the same for both.
Know where durable paths are. Point agent config, credentials, and outputs at /workspace or the image filesystem. Never point them at a symlink into /tmp, /run, or /dev/shm, because those are memory-backed and emptied on restart.
Plan for memory loss. Save the work that matters to disk, or capture a .smolcheckpoint, before assuming anything about a stopped machine's runtime state.
Treat stopping as parking, not backup. Deleting a machine removes its storage. Keep source data and outputs in an external system of record, and use .smolmachine artifacts or .smolcheckpoint snapshots for portable copies.
Check isolation requirements. If your agents execute untrusted code, verify that the platform offers hardware-level isolation and egress controls, not just container-level separation.
Decide on self-hosting. Teams with distributed-systems experience can run smolvm on their own servers, which keeps the same VM model under your own control.

Frequently Asked Questions

Which cloud machine platforms support stopping idle compute while preserving a filesystem?

Look for platforms that provide durable machine storage independent of active compute, plus explicit stop and start lifecycle operations. Confirm that the retained workspace is attached after restart and that deletion is an explicit, separate action. Smol cloud is one option: it runs smolvm-based workloads on persistent cloud VMs where stopping compute preserves the machine filesystem, including stops triggered by idle timeouts.

Does stopping an agent machine preserve RAM and running processes?

No. RAM, processes, sockets, and active connections disappear when compute stops. Save the work that matters to disk, including a structured .smolcheckpoint if you want a durable point in time, then rebuild the runtime at startup.

Is a snapshot the same as an active retained workspace?

No. A snapshot is useful for recovery, rollback, or cloning. A retained workspace is the filesystem the resumed agent is meant to use. On smol cloud, the machine filesystem persists across stop and start on its own; snapshots and .smolmachine artifacts are additional, portable copies you create deliberately.

How should an idle policy handle untrusted agent code?

Keep the isolation boundary intact even when machines are parked. Prefer hardware-virtualized machines with their own guest kernel, keep networking off by default, and restrict egress to an allowlist. Smol machines follow this model: each workload runs in its own microVM, and untrusted code cannot reach the network unless you allow it.

Conclusion

Idle agent compute should be a cost you can switch off, not a risk to your agent's environment. Smol Machines separates the two: stop or idle out a smol cloud machine and the filesystem stays, so the next session starts warm with every package, cache, and repository intact, while compute charges drop to zero and only stored disk bills. Pair that with portable .smolmachine artifacts and .smolcheckpoint snapshots, and stop-and-resume becomes a normal part of the agent lifecycle rather than an infrastructure exception. Read the developer docs or head to smolmachines.com to get started.