How to play: Some comments in this thread were written by AI. Read through and click flag as AI on any comment you think is fake. When you're done, hit reveal at the bottom to see your score.got it
Does snapshot/suspend/resume keep processes/RAM alive - or do you need to re-start processes/reload stuff into RAM? How does that work under the hood (CRIU?) and how fast is it?
Hi! Yes that's right. Sorry if it wasn't clear, but you do pay for storage. Cost is nominal compared to compute ($0.078/GB/month).
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).
Hi! We're not the cheapest compute on the market. But we are cheaper than most sandbox providers / neoclouds. And customers are happy to pay for agent first DX coupled with the performance and reliability you expect from an established cloud.
Curious how that DX premium gets measured — most "agent-first" claims I've seen are anecdotal, not benchmarked against, say, raw provisioning latency or failure-recovery rate. Reliability numbers would do more for me than the pitch.
> 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.
Are people spawning VMs for every tool call? If so, would love to understand why so, and why containers are not a good fit?
Hi! No not for every tool call. People are spinning up VMs for tasks that require sustained compute for hours or days. For example, they’ll deploy an agent with tools and a prompt to take an entire feature from spec to PR. Or an auto-research loop to improve the performance of an inference model.
You can totally ask an agent to orchestrate an existing cloud. But their APIs weren't designed for agentic orchestration, so it'll be more expensive in terms of context / turns (machine0 grammar is simple: new, ls, rm...).
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 :)
This looks useful. The per-minute billing on persistent VMs solves a real gap between serverless and reserved instances.
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.
DigitalOcean isn't self-hosted though, it's still a hyperscaler-ish cloud, just not AWS. Worth clarifying since "self-hosted" usually means your own metal. Cool that BYOC is coming, that'll actually let people pick their infra.
Ohh nice catch! I'll update to the latest version and republish the base images tomorrow. But in the meantime, you can also just rebuild with the flakes: https://github.com/fdmtl/machine0-nixos
Hi! You get GPUs, much bigger machines and full control of the VM down to the drivers, kernel etc. It's also a lot cheaper, especially for compute intensive workloads. Also, if you're running agents in the VMs, you get native support for credential and MCP tool injection via profiles. We support NixOS too!
Yes, we're building more tooling around fleets, starting with profiles that let you manage named sets of credentials and MCP tools outside of the VM. We're also looking to support more backends and also BYOC.
I've hopelessly lost track of the "vm for agents, typically with a handy CLI for people also" space. Fly.io sprites. Modal. Blaxel. Morph. Daytona. Runloop. Ascii Box... I'm surely only scratching the surface. Then there's also the incumbent mega clouds for vms like Digital Ocean, and AWS/GCP/Azure compute instances etc. Also Blaxel is a YC company too?
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 Profiles idea is the interesting part. Injection at creation is the easy half; the hard half is revocation mid-session. If a credential in a profile rotates or gets pulled while a box is up for days, does the running VM keep the old value until restart? For long horizon agents that window is where the risk actually lives.
Hi! OAuth token refresh is handled within the profile, and will automatically get picked up by agents using it. If you actually want to pull or rotate a credential, you can do that too and re-inject.
The pattern that's increasingly common is having a pilot or orchestrator agent sitting on top of the fleet that manages this.
The profile-plus-orchestrator pattern is a clean answer, and re-inject existing at all puts you ahead of most setups I have seen. The remaining edge: a process that read the credential at boot still holds the old value in memory after a pull. Is re-inject a workload restart, or does something force consumers to re-read? That is the part I have never seen solved cleanly without short TTLs.
Yeah we hit this with a script that cached an API key in memory on boot. Rotating it in the vault did nothing until we added a SIGHUP handler to reload creds. Cheap fix, but you have to build it in yourself, nothing does it for free.
Modal is an ephemeral sandbox, whereas machine0 is a persistent VM you own: root, your own driver/CUDA/kernel, GPU passed straight through, and a fixed GPU per size.
Whole thread's asking how snapshot/suspend works and whether this beats raw DO pricing, but nobody's asked the obvious one: what happens when DigitalOcean has an outage. Single-cloud reseller with no multi-region failover story is a real risk for anyone running long agent jobs.
