machine0 Gives Coding Agents Persistent Cloud VMs

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

A remote agent machine is useful when a build, test suite, or investigation needs to outlive the laptop session that started it. machine0 offers persistent CPU and GPU VMs through a CLI and remote MCP server. This is a source assessment and proposed trial; we have not measured its reliability or completed a production deployment.

Updated 21 September 2026: checked the current vendor description, clarified suspended-storage charges, and replaced a suggested branch restriction with enforceable access controls.

What persistence buys

The vendor describes machines that remain running until stopped or suspended, with snapshots and profiles for configuring agent environments. Its pricing page distinguishes suspended compute from retained image storage: suspension pauses compute billing while image storage remains chargeable. Check the current machine size, region, storage terms, and account balance before provisioning. Advertised uptime is a vendor claim, not a result of this review.

For a repository with slow dependency installation, a retained checkout could avoid repeated setup. That advantage is worth testing against the remote-machine overhead: provisioning, copying evidence back, reviewing changes, and cleaning up. A small local test that already runs quickly is unlikely to justify another environment solely for persistence.

Prepare a disposable trial

Choose a non-urgent task with a known verification command and fixture data. Record the starting commit and dependencies. Agree on the spending limit and who will stop or remove the machine. Use the official installation documentation for the current setup procedure rather than copying an old installer command from an article.

Use a test repository or credentials limited to the required repository operations. Working on a branch does not prevent an agent with broad credentials from pushing elsewhere. Likewise, a prompt saying “read only” does not reduce an MCP server's granted permissions. Configure access at the credential, service, and runtime layers before connecting the agent.

Leave production secrets and customer data out of this first exercise. If a required test cannot run without them, choose a different test rather than silently expanding the experiment's authority. Repository team conventions can document these choices, but do not enforce them by themselves.

Test recovery separately from task completion

Create one identifiable local artifact, make a small uncommitted change, and record the repository status before testing suspension. Preserve a copy of anything valuable outside the trial machine. Use the vendor's documented lifecycle actions and confirm each reported state.

Do not infer that a background process resumed just because its output file survived. Check the process or rerun the job deliberately. A retained log can document an earlier pass while the present checkout fails. Keep those two observations separate in the review.

Require a portable handoff

Before cleanup, ask the agent for the changed files, commands and results, artifact locations, and unresolved problems. This can be an ordinary prompt; it does not require a custom slash command. Copy the diff and relevant evidence to the normal review location, then verify that they can be opened without the VM.

Session handoffs help the next person continue, but the machine's retained state is not a substitute for a reviewable record. Record whether the task actually finished and whether recovery required manual repair.

Finally inspect both compute and stored-image charges. Suspending a machine is not the same cleanup decision as deleting resources you no longer need. Keep a VM only when the retained environment has a clear next use and an owner. The trial succeeds when you can explain the time saved, the cost incurred, and how the resulting patch was checked.