Demo: https://www.youtube.com/watch?v=gyllkZ0M04E
Agent workloads are moving from ephemeral to always-on. A coding agent working on a complex feature runs 6-8 hours. Agent orchestrated training & RL runs take days. OpenClaw & Hermes run 24/7. As you run more in parallel:
- Resources: a few agents on a large codebase saturate RAM and CPU. Model training and RL needs GPUs you don't have.
- Security: `--yolo` on your personal machine is one prompt injection away from exfiltrated credentials.
- Availability: close your laptop and the agent dies mid-task.
- Isolation: there's no clean line between you and the minimum your agent actually needs.
machine0 gives every agent its own computer. It's a CLI simple enough that both humans and agents use it without reading docs: `machine0 new mybox` creates an SSH-ready VM with a static IP and HTTPS endpoint. Always on (with 99.99% VM level uptime) until you switch it off.
- Billed by the minute. 1 vCPU / 1 GB at $0.013/hr up to 60 vCPU / 240 GB, plus GPUs from RTX 4000 Ada to 8×H200.
- Suspend, snapshot and resume. Making it easy to pause your work, and come back to it later. Or to make a golden master image to stamp out clones for a fleet.
- Block storage. Persistent volumes (from 10 GB to 16 TB) that you can manage with intuitive grammar: `--yolo` and attach to your VMs.
- Profiles. Bundles of credentials, MCP connections, prompts, and env vars, injected at VM creation. So each agent gets exactly the capabilities you choose, and nothing else.
- Agents self-serve. Hand the CLI or MCP server to Claude, Codex, or OpenCode and it manages its own fleet: spin up a box for a build, snapshot it, tear it down.
- Reproducible Builds. Using NixOS flakes or Ansible playbooks with Ubuntu.
How do people use it today?
- Agent fleets. People run a pilot agent that scopes work and delegates it to sub-agents, each on its own VM: shape a project with the pilot, and the workers implement it and open PRs. One customer runs hundreds of machines at once, spun up and torn down from the CLI.
- Model optimization & RL environments. ML teams use machine0 for agent-orchestrated RL environments and model optimization work. One customer runs RL environments on 60 vCPU machines that stay up for days at a time; another keeps a suspended H100 around and points an agent at it overnight to grind on inference-speed optimizations.
- Product infrastructure. One customer builds their product on top of machine0 rather than using it themselves: every user session gets a fresh XL machine from a versioned image of their own agent runtime. They've shipped hundreds of versions of that image and launched thousands of machines, most alive for two minutes.
What’s under the hood?
Every machine is a full KVM virtual machine, not a container or sandbox. You get the real GPU exposed to the guest with its actual driver, kernel-level access (load any module or driver you want), and no syscall-interception layer between you and the hardware. The stack itself is deliberately dull: TypeScript, Postgres, Redis. We weigh heavily towards security, reliability and performance making machine0 ideal for sustained compute intensive workloads. About me
I've been building cloud infrastructure for about 15 years. I dropped out of a PhD at Imperial College London on cloud resource allocation, later spent six years as co-founder and CTO of Upflow (YC W20), owning DevOps, infra and security personally the whole way to 7-figures in ARR because it was too high-stakes to delegate. machine0 started as a tool for me, I’m my own first user :) Asks
Would love you to try it out and give us your feedback (see below). Or if you’re a company looking for compute for software factories, model training or RL environments, feel free to reach out at barnaby@machine0.io
# install machine0
$ curl -LsSf https://machine0.io/install.sh | sh
# create a machine and ssh in
$ machine0 new myvm
$ machine0 ssh myvm`machine0 suspend` takes a full disk snapshot and tears down the compute; you keep paying only for storage. `machine0 start` restores the disk and cold-boots the VM from it. So processes restart, they don't resume mid-execution. Practically: anything that survives a reboot survives a suspend.
And resume it later with the full disk ready to go? No billing during the inbetween time?
That’d be huge, but seems wild. How can you economically keep the storage between active sessions?
The other option is to define your entire environment as code using nix (we have native NixOS support). For example, you can use an agent to author code which declares everything on your machine: packages, libraries, shell, vim config... And then you can take that code and use it to rebuild a new VM on machine0 whenever you like (or somewhere else).
Docs here: https://docs.machine0.io/examples/nixos
Well, given DigitalOceans already inflated prices, this certainly won't be cheap.
Are people spawning VMs for every tool call? If so, would love to understand why so, and why containers are not a good fit?
What are you doing here that my agent couldn't do with: AWS, GCP, Hetzner, DigitialOcean?
Quick read is this is some simple api abstraction? or you're even brokering that compute? Which i would want, why?
The other thing is if you're running large workloads that span many machines (e.g. software factories, model training or RL environments), then over time you'll end up with orphaned artifacts that will need to be maintained (think security groups, volumes, elastic IPs etc).
Ultimately, most of our customers today just want to be able to spin up a powerful & reliable VM without worrying about DevOps or any other kind of maintenance :)
But, I don’t think this is your strongest argument. The APIs for those providers are pretty easy to orchestrate and don’t take that many tokens to use. (Especially if you are hosting on top of one of these providers)
Instead, I think some strengths you could focus on are (a) not being one of those providers, (b) having a better product mix that people want to use, and (c) keeping a minimal design. Clear use-cases, minimal friction, easy to keep the model in your head.
You definitely have a good product here with plenty of reasons to choose you. But your minimal API isn’t a great moat.
One question on the agent fleet pattern you described: when a pilot agent delegates to dozens of sub-agents across separate VMs, how do you track what the whole job actually cost? The VM minutes are visible, but the API calls each agent makes to OpenAI, Anthropic, Serper, Firecrawl, those are spread across processes and vendors.
We ran into this running our own agent fleets. Token counts only come back with the response, so per-key limits and vendor dashboards always arrive too late. focxle sits inside each agent process, attributes every call to a named agent, and prints a consolidated report showing per-agent and per-vendor spend plus the projected monthly at the current rate. That projected number is the one that gets budget attention.
Free to observe, no account, no card, two lines:
```python pip install focxle
import focxle focxle.init()
This gives you the best of both worlds: agent native, CLI-first DX with the reliability and performance of a traditional cloud.
I need an explainer. Each of these products is carving out a particular niche, or competing directly for someone else's niche with better X or Y, and I'd love to see some analysis of the landscape.
The pattern that's increasingly common is having a pilot or orchestrator agent sitting on top of the fleet that manages this.
It ranges from cold to orange! From one earth gravity to 32* Kelvin!
If you’re gonna pretend to give pricing give pricing. If you’d rather hide it, don’t throw out $0.013
Makes me mental math how much they actually charge per minute.