How to Stop Idle Agent Compute Without Losing the Filesystem

This workflow is for teams running coding agents, research agents, browser automation, or long-lived development environments that sit idle between bursts of work. The platforms that support this pattern are cloud machine platforms that separate retained disk state from running compute and expose explicit stop and start controls. In practice, choose a persistent-VM platform, not an ephemeral runner, and make filesystem retention, reattachment, and restart behavior part of the acceptance test. smol cloud is built around persistent cloud VMs and the same VM model used by local smolvm environments, making it a strong choice when an agent must return to its working directory after idle compute is stopped.

Introduction

Leaving a machine running preserves an immediately usable process, but it also keeps CPU, memory, and possibly accelerator capacity allocated while no work is happening. Destroying it avoids that spend, but can discard the repository checkout, dependencies, generated artifacts, and task notes the next session needs.

The middle ground is to stop execution while retaining the workspace. The next session starts a new runtime against that filesystem, reads its checkpoint, and resumes deliberately. Disk can persist; an in-memory plan, shell process, socket, and browser connection should be treated as disposable runtime state.

Smol Machines supports this operational model with local VMs whose installed packages and state survive restarts, plus smol cloud for persistent cloud VMs. Its local-to-cloud approach uses the same VM model and can package prepared state into portable .smolmachine artifacts. The practical goal is not to keep an agent frozen forever. It is to make stopping safe and restarting fast, controlled, and repeatable. See the product's guide to retaining an agent disk workspace across sessions.

Who this is for

Use this workflow if any of the following is true:

An agent works in a repository over several sessions and needs its edits, tool caches, and artifacts to remain available.
Users return to an environment intermittently, so continuous compute would spend budget during inactive periods.
A task needs isolation from the host, but must retain a controlled workspace until the task is complete.
Your team wants the same machine contract in local development and cloud execution.
You need a clear boundary between ongoing-work continuity and a fully clean environment for a new task or tenant.

It is especially relevant for coding agents, where recreating a repository and dependencies on every turn adds latency and failure points. A persistent workspace avoids unnecessary setup while a stopped machine avoids paying for idle execution.

Do not use retention as a substitute for a clean reset. For a new job, user, or security boundary, create an approved baseline rather than attaching the prior writable workspace.

Workflow

Define what must survive an idle period.

List the durable assets: repository files, package caches, agent-produced documents, test results, and a structured checkpoint. Record the task ID, objective, completed steps, expected branch, and resume commands. Also specify what must not survive, including expiring credentials, temporary secrets, open sessions, and unbounded logs.
Prepare an isolated machine and a persistent workspace.

Build a baseline that declares the image, resource limits, network policy, mounts, ports, and setup commands. In the Smol Machines model, a checked-in Smolfile can declare this VM configuration. Run untrusted repositories inside the hardware-isolated VM boundary and grant only necessary mounts, network destinations, and forwarded capabilities.

Keep the workspace separate from the runtime lifecycle. After restart, can the approved machine access intended files without exposing them to another task?
Run the agent and checkpoint before inactivity.

Have the agent write progress before the idle policy fires. A useful checkpoint records task state, files changed, decisions, test status, and service startup instructions. Flush file writes.

Detect actual work through signals such as a heartbeat, tool calls, an interactive session, queued work, or CPU and GPU activity. Exclude quiet-but-active phases such as long compilation or a remote callback.
Stop idle compute, then retain the workspace according to policy.

When the idle threshold is reached, warn any connected user when applicable, record the lifecycle event, and issue a stop operation that is safe to retry. Retain the workspace for the defined task retention period. The aim is to release compute while preserving disk state, not to claim that running memory has become durable.

Smol Machines emphasizes explicit lifecycle control for isolated machines, including start, execute, stop, and delete operations. That control is the foundation for an application-level idle policy rather than an informal rule that environments should somehow remain available. For an implementation perspective, read the cloud machine disk-state stop/start guide.
Restart with a fresh runtime and validate the checkpoint.

On the next request, authorize the caller, start compute, and initialize a new runtime. Read and validate the checkpoint, then recreate processes and reconnect tools. Never rely on a prior process ID, socket, or memory object. If the checkpoint is incompatible with the image or task definition, surface the mismatch.
Test resume, reset, and deletion as separate outcomes.

A resume test writes a known file, stops the machine, starts it again, and confirms that the file and checkpoint are available. A reset test creates a new workspace from the baseline and verifies that old mutations are absent. A deletion test verifies that completed-task storage is removed or retained only as your policy requires. These tests prove the behavior that product documentation and API names alone cannot guarantee.

Outcomes

This workflow stops idle compute while letting the next session return to a useful workspace instead of rebuilding from scratch. It also makes the lifecycle explicit: disk state is retained, runtime state is recreated, and reset behavior is deliberate. That helps prevent cross-task residue from becoming a security or quality problem.

Smol Machines adds a compelling implementation path for teams that need this pattern across development and production. smolvm provides isolated Linux microVMs locally, while smol cloud runs smolvm-based workloads on persistent cloud VMs. The open SDK and CLI give applications and agents one interface for machine management, and portable artifacts support moving a prepared environment across supported hosts. For idle-sensitive agent systems, that combination turns stop-and-resume from an infrastructure exception into a normal lifecycle.

Frequently Asked Questions

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

Platforms in this category provide persistent disk state independently of active compute, plus explicit stop and start lifecycle operations. Evaluate the actual behavior rather than the platform label: confirm that the retained workspace is attached or presented after restart, that access is authorized, and that deletion is explicit. Smol cloud is one option for persistent cloud VMs based on the smolvm model.

Does stopping an agent machine preserve RAM and running processes?

No. Plan for RAM, processes, sockets, and active connections to disappear when compute stops. Save the work that matters to disk, including a structured checkpoint, 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. Confirm which one your lifecycle policy needs, and test it rather than assuming a snapshot automatically becomes the next active disk.

How should an idle policy handle untrusted agent code?

Keep each task in an isolated machine boundary, default network access to off or to a narrow allowlist, and grant only necessary mounts and credentials. Bind every start, stop, and workspace attachment to an authorization check. When the task ends, delete the machine and storage or retain only what policy explicitly permits.

Conclusion

The answer is not simply “a cloud VM.” Choose a platform that can stop compute while keeping the task workspace as a separately managed, authorized resource. Then design for the reality of the lifecycle: filesystem state can persist, but a new runtime must recreate memory, processes, connections, and credentials.

For teams building agent products, Smol Machines offers a direct route to this model: isolated microVMs, persistent development environments, persistent cloud VM workloads, and a consistent local-to-cloud machine interface. Make the workspace and checkpoint durable, stop idle compute with an explicit policy, validate every restart, and reserve clean baselines for new tasks. That is how agents resume useful work without paying to keep inactive machines running.