Rendered at 20:36:46 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
zodiac 19 hours ago [-]
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?
messh 17 hours ago [-]
If you don't need GPU, check out https://shellbox.dev - it snapshots memory, processes. And you pay only for actual running time per minute
focxle 6 hours ago [-]
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.
Free to observe, no account, no card, two lines:
```python
pip install focxle
import focxle
focxle.init()
averylostnomad 1 days ago [-]
When you say suspendible, do you mean that I could make a VM, configure it by installing packages and libraries, then pause it?
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?
bwm 1 days ago [-]
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).
> 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?
bwm 1 days ago [-]
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.
kam 22 hours ago [-]
NixOS 25.11 was EOL a month and a half ago. Where's NixOS 26.05?
bwm 21 hours ago [-]
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
yetanotherjosh 16 hours ago [-]
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.
prodtorok 1 days ago [-]
Basic question:
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?
bwm 1 days ago [-]
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 :)
mbreese 20 hours ago [-]
Congrats on the launch. I can’t wait to try it.
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.
1 days ago [-]
xrisk 1 days ago [-]
This seems like something that could exist as free software and can be easily vibecoded in the form of a pile of scripts. Thanks for the idea!
dmmalam 1 days ago [-]
Could say the same about v1 of OpenRouter which Stripe is acquiring for $7B this week;) [1].
You can't vibecode your way to their market capture.
gajus 1 days ago [-]
OpenRouter is valuable because it has a large catalogue of competing providers for a fungible service. This does the opposite (lock in with a specific vendor).
1 days ago [-]
aua 1 days ago [-]
Dropbox-esque?
kwakubiney 1 days ago [-]
What does this give me that fly.io sprites does not give me?
bwm 1 days ago [-]
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!
gajus 1 days ago [-]
Can you give me a practical example of 3 most deserving use cases? Something that customers are actually using them for today.
bwm 1 days ago [-]
Hi! Sure: (1) running agent fleets for software factories, (2) Model training and RL environments orchestrated by agents and (3) as a backend for agentic products and platforms.
dmmalam 1 days ago [-]
What's the roadmap? Any plans for swarm specific tooling, or an backend marketplace (eg aws, hetzner etc).
bwm 1 days ago [-]
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.
messh 17 hours ago [-]
If you don't need GPU, check out https://shellbox.dev - it snapshots memory, processes. And you pay only for actual running time per minute
shaewest 17 hours ago [-]
You seem to be posting your project/startup constantly under others people's comments/posts.
7 hours ago [-]
bobbylarson 1 days ago [-]
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.
bwm 1 days ago [-]
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.
nc 1 days ago [-]
I’m currently using Modal for my GPU training workload, how does this differ?
bwm 22 hours ago [-]
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.
atechboy 22 hours ago [-]
So you are using Modal VMs for training (I assume RL evals?).
benswerd 1 days ago [-]
What is the hardest part of building this for you?
bwm 1 days ago [-]
I have a payments background. So maintaining a very high bar on security, reliability and performance as usage scales is super important.
happyopossum 21 hours ago [-]
> from $0.013/hr up to 60 vCPU / 240 GB RAM and GPUs
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
jkahrs595 17 hours ago [-]
“We charge by the minute!”
Makes me mental math how much they actually charge per minute.
rvz 1 days ago [-]
Does this internally use AWS or is this your own self-hosted environment?
bwm 1 days ago [-]
Hi! It sits on top of DigitalOcean. We also have BYOC on the roadmap.
This gives you the best of both worlds: agent native, CLI-first DX with the reliability and performance of a traditional cloud.
benswerd 1 days ago [-]
What made you choose digital ocean?
redrove 1 days ago [-]
YC gives DO credits for startups.
bwm 1 days ago [-]
Their machines are good & they have a partnership program that's fast and compatible with the model.
sparkling 1 days ago [-]
>machine0 provides on-demand cloud virtual machines accessible via a command-line interface and web dashboard. VMs run on DigitalOcean infrastructure.
Well, given DigitalOceans already inflated prices, this certainly won't be cheap.
bwm 1 days ago [-]
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.
gajus 1 days ago [-]
The funny thing is that DO itself has an MCP for spinning up VMs, resolving IPs, etc.
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()
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
Are people spawning VMs for every tool call? If so, would love to understand why so, and why containers are not a good fit?
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.
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.
[1]: https://news.ycombinator.com/item?id=49323381
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.
This gives you the best of both worlds: agent native, CLI-first DX with the reliability and performance of a traditional cloud.
Well, given DigitalOceans already inflated prices, this certainly won't be cheap.