The overnight run was meant to file every supplier form in the portal by morning. At breakfast the operations lead found the desktop gone, a stack of forms done and the rest untouched, while the next batch of tasks sat queued because idle machines from earlier sessions still held every slot.
Long agent jobs fail this way because most of their time is spent waiting, and a VM left to wait either holds capacity it is not using or loses its work. The answer is a lifecycle policy set at create time: pause on idle instead of killing, park for short waits, escalate a long park to a full pause, and checkpoint on an interval. Solari's Computer Desktops and AI Sandboxes take all four as fields on the create call, from one account and one API. This guide walks through each setting in the order a long job meets it.
Why Long Agent Jobs Lose Work or Hold Slots
The opener's failure had two causes, and each setting below answers one of them. A virtual machine keeps its memory, processes and disk only while something keeps it alive, and a cloud plan caps how many can run at once. A VM that shuts down loses its work; a VM that idles without limit takes a slot from the next task.
On Solari both outcomes are explicit. If code inside a VM runs poweroff or shutdown, the VM is deleted with its disk and cannot be resumed, while a VM left running keeps counting against the plan's limit. The first setting decides which outcome applies when nobody is using the machine.
Set an Idle Timeout That Pauses
The idle timeout is the baseline the other settings build on. Every action and every open connection resets the clock, so a busy VM never disappears mid-task. When the timeout passes with no activity, "pause" saves the state and "kill" shuts the machine down.
Pause is the default, and without a timeout set a Solari VM pauses after 30 minutes idle. A paused VM frees its slot until it resumes, and every VM keeps a stable id, so connect(id) from a fresh worker re-attaches and resumes it where the agent stopped.
A same-host resume took about 1.3 seconds on staging, five trials, once the pause had finished saving its snapshot. A resume called while that pause is still saving waits its turn and takes much longer, so a job that pauses and resumes in quick succession should budget for the slow path. For gaps too short to be worth a pause, there is a lighter option.
Park for Short Waits, Pause for Long Ones
Parking handles the short gaps inside a session, such as an LLM response or a person reading the screen. With parkAfterMs set, Solari freezes the VM's CPUs after that much idle time while its slot, network connection and live stream stay held, so the next touch wakes it with nothing to restore. A parked VM still counts against the plan's running limit, which makes parking a latency tool rather than a cost tool.
The long tail of waits is where slots and credit drain away. If a parked VM stays idle for the hibernateAfterParkedMs period, Solari escalates it to a full pause, saving its state and freeing its slot, much as hibernation writes a laptop's memory to storage. A short park with a longer hibernation delay is a sensible starting point, tuned against the job's real idle gaps:
The last field in that block protects against a different failure: the host underneath.
Checkpoint Long Sessions on an Interval
Pausing protects work from idle time; checkpointing protects it from the machine. Application checkpointing saves a snapshot of state so a job can restart from that point after a failure. On Solari, checkpointEveryMs takes a durable checkpoint on that interval while the VM runs, so an unexpected host issue costs at most one interval of progress.
Each checkpoint briefly pauses the guest, so the screen freezes for a moment, and the field has a floor to stop a session spending its time stuttering. Like parking, it is off unless the create call sets it. With the settings in place, the remaining question is what each state costs.
What Each VM State Costs
Cost and capacity follow the state the machine is in, and the figure sets the states side by side.
Solari bills sandboxes and VMs by size, at $0.0245 per vCPU-hour and $0.0077 per GB-hour on Professional, and a VM adds $0.02 per hour for the live screen. Professional runs 10 sandboxes or desktops at once, so a few forgotten parked VMs can hold back the next batch of work.
Every product draws from one credit balance that refills monthly, and at a zero balance new sandboxes and desktops stop launching rather than running up an overage charge. That makes the lifecycle policy the main lever on both the bill and the size of the fleet.
Choosing the Right Setup
A long agent job needs a VM that never dies by accident and never sits on capacity it is not using. Pause on idle and never power off from inside, park for waits measured in seconds, and escalate a long park to a pause. Add a checkpoint interval when losing a session would cost more than a brief freeze.
Get Started With Solari
The first step for the opener's overnight run is a single desktop with pause as its idle policy and a short park, then the same job resumed by id from a fresh worker. Solari starts sandboxes in 90 ms and runs them almost 3x cheaper per sandbox hour than E2B, and the Solari launch overview shows how desktops, sandboxes and browsers share one account. Start free on Solari, where the Free plan's $3 of monthly credits cover the first long run.
