machine0 Puts Agent VMs on the CLI

machine0 (YC S26) is Barnaby's CLI for giving coding agents persistent cloud VMs, including CPU boxes and GPU machines. It deals with a practical annoyance: long-running agents need somewhere stable to work after your laptop, shell session, or short-lived sandbox stops being enough. The takeaway is simple: machine0 is interesting when the VM lifecycle is the boring part you want removed, but you should test the billing, permissions, and resume behavior before trusting it with important work.

A persistent agent VM is a cloud machine that keeps its working environment across a long job, so an agent can compile, test, train, or repair code without rebuilding the world every time. For Claude Code, Anthropic's coding agent, this fits a real claude code workflow: give the agent a durable place to run, then keep the repo rules, MCP access, and review evidence tight.

Why a persistent VM got attention

machine0's launch pitch is deliberately small: run machine0 new mybox, get a VM for an agent, and pay by the minute. The public description says pricing starts at $0.013/hr and scales up to 60 vCPU / 240 GB RAM, with GPU options such as H100s and H200s, plus 99.99% VM-level uptime.

That matters because agent jobs are getting less like autocomplete and more like overnight builds. A coding agent working on a gnarly feature can spend hours cloning context, running tests, bisecting failures, and editing code. Training and reinforcement-learning jobs can run for days.

The trick is not that virtual machines are new. The trick is making agent compute feel like a local CLI primitive instead of a cloud console chore. If an agent can self-drive through CLI or MCP, the VM becomes part of the agent's working surface.

The trap is assuming this removes cloud complexity entirely. It only moves the boundary. You still need to know what credentials are on the box, what data can leave the repo, what gets persisted, and what happens when the job stops halfway through a package install.

What machine0 is trying to remove

Developers on the launch thread immediately asked the right question: why not just use AWS, Google Cloud, Hetzner, or DigitalOcean? A normal VM provider can already give you compute. The difference machine0 is claiming is the shape of the workflow: one command, agent-oriented persistence, minute billing, CPU and GPU options, and control through CLI or MCP.

That is useful if your pain is not raw compute. The pain is all the glue around it: account setup, instance selection, SSH keys, startup scripts, disk reuse, agent handoff, and cleanup. One small abstraction can be worth it if it turns a fragile checklist into a repeatable command.

A concrete example: you have a branch that needs a full integration suite, a dependency upgrade, and a flaky test hunt. You want the agent to keep a warm checkout, logs, build cache, and failed artifacts. Recreating that on every run is wasteful and usually where the human gets pulled back in.

The trap is paying for convenience without understanding the substrate. The public launch does not, by itself, answer every infrastructure question. Before you treat machine0 as critical path, ask how VM placement works, how disks are stored, what regions and accelerators are available, and what the failure mode looks like when capacity is tight.

Put a small permission boundary around Claude Code

For Claude Code users, the interesting part is not only the VM. It is the boundary between the coding agent, the remote machine, and external systems. MCP can make that boundary clean, but only if you start narrow.

A good first experiment is boring on purpose. Let Claude Code work on one non-production branch inside one machine0 VM. Give it read access to the issue or spec through MCP, local shell access inside the VM, and write access only to the checkout it is supposed to edit.

Here is a simple MCP permission note you can paste into the issue or repo instructions for the experiment:

This is where the related training topic matters in practice. Shared conventions are not paperwork; they are the small local rules that keep a capable agent from wandering into the wrong system.

The trap is handing the remote box the same authority as a trusted developer laptop. A persistent VM remembers mistakes. That is useful for debugging, and dangerous for credentials.

Use persistence for evidence, not just runtime

The best reason to try a persistent agent VM is not that the agent can run longer. It is that the work can leave behind evidence you can inspect without replaying a chat transcript.

Ask for a handoff receipt at the end of every remote run. It should name the branch, commands run, tests passed and failed, files changed, open questions, and where logs live on the VM. If the agent cannot produce that, the extra compute only made the failure more expensive.

For Claude Code, this pairs well with a slash-command workflow. A command like /remote-agent-receipt can ask the agent to summarize the VM state before you stop or destroy it:

Summarize this remote agent run.

Include:
- branch name and latest commit
- commands run, in order
- tests passed, failed, or skipped
- files changed and why
- artifact paths worth preserving
- unresolved risks before PR review

Keep durable repo facts short. A CLAUDE.md note such as Remote agent VMs must not contain production secrets; use fixture data unless a maintainer says otherwise is enough. Save task-specific details for the issue, the slash command, or the handoff receipt.

The trap is treating persistence as memory. A VM can keep files, logs, and caches. It does not automatically create a trustworthy narrative of what happened. For more on keeping long agent sessions inspectable, see Maximizing Claude Code Sessions.

Know when this is too much machine

Try machine0 when the setup cost is large compared with the code change. GPU experiments, long compile loops, multi-hour test suites, branch repair, dependency migrations, and agent-run benchmarks are good candidates.

Skip it for small edits. If the job is a lint fix, a copy change, or a simple unit test failure, a persistent VM adds another thing to secure and clean up. Local Claude Code is usually faster to reason about.

Be extra cautious with regulated data, private customer fixtures, licensed model weights, and jobs that need access to internal services. The launch pitch is about agent compute, not an automatic answer to your compliance model.

The trap is optimizing for agent autonomy before you can review the result. More CPU does not fix unclear requirements. More GPU does not fix a missing test oracle.

Try machine0 safely on one branch

Use this as a small experiment plan, not a forever policy.

• Pick one branch with a real but non-urgent task: a flaky test, dependency bump, or benchmark cleanup.
• Start from the advertised workflow: machine0 new mybox.
• Install only project dependencies needed for the task.
• Do not place production secrets, customer data, or broad cloud credentials on the VM.
• Connect Claude Code with the narrowest MCP access that lets it read the spec and edit the checkout.
• Ask the agent to run the smallest meaningful test first, then the expensive suite.
• Require a handoff receipt before you stop, suspend, or destroy the VM.
• Inspect the changed files locally before opening a PR.
• Compare the bill, elapsed time, and review quality against your normal workflow.
• Write down one decision: use again, use only for GPU or long tests, or skip.

A useful first win is not a perfect autonomous feature. It is a run where you can say, clearly, what the VM saved and what extra review it required.

Common questions

• Does machine0 use AWS, or is it self-hosted?

  The public launch discussion raised that question, but the launch signal alone does not prove the underlying infrastructure model. Ask machine0 directly about providers, regions, isolation, and capacity before treating it as production infrastructure. For a first test, assume it is an abstraction over compute until the vendor documentation or contract says more.

• What is machine0 doing that my agent could not do with AWS, GCP, Hetzner, or DigitalOcean?

  machine0 is trying to remove workflow friction, not invent the VM. The claimed difference is a CLI and MCP-shaped path for persistent agent compute, with minute billing and CPU/GPU choices. Raw cloud providers can do the underlying job, but they usually require more setup, cleanup, and integration glue.

• Can I pause a VM and resume it later with the disk ready?

  The launch says machine0 provides persistent VMs billed by the minute, but pause, suspend, disk retention, and no-compute-billing semantics need explicit confirmation. This is the key economic question. If storage remains between active sessions, ask what is billed, how long disks persist, and what happens after account or quota changes.

• Is this useful with Claude Code MCP?

  Yes, if the VM is the execution place and MCP is the narrow integration layer. Start with read-only external context and local repo writes, then expand only if the receipts are good. The useful pattern is not unlimited access; it is a durable workbench with small, inspectable permissions.

• When should I choose a GPU VM?

  Choose a GPU VM only when the task genuinely needs accelerator-backed work, such as model training, inference benchmarking, or agent-orchestrated evaluation. For ordinary coding, tests, and repository repair, CPU machines are usually the safer first experiment. GPU cost can hide bad task design very quickly.

Best ways to use this research

• Best for: Engineers evaluating whether persistent agent compute is worth adding to an existing Claude Code workflow.
• Best first artifact: A handoff receipt from one real branch, with commands, tests, changed files, and artifact paths.
• Best comparison angle: Compare machine0 against your current VM or devbox process on setup time, cleanup time, review evidence, and total bill.
• Best permission default: Let the agent edit one checkout and read the spec, but keep production secrets and cloud account controls out of the VM.
• Best stopping rule: If the remote run does not produce better evidence than a local run, do not keep adding compute.

Further reading

• machine0 (YC S26) — source
• Claude Code — getting started
• Claude Code — skills

Next step

Try one disposable machine0 VM on a branch you already understand. Keep the permissions small, require a receipt, and decide from the evidence rather than the demo.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.