Your Mac mini costs $1.35 a month, and no cloud provider comes close
I was about to build a feature. Then I did the arithmetic.
I build reminal, a tool for reaching your terminal from your phone. The natural next feature seemed obvious: reminal new machine. One command, a cloud VM appears, you own it, it shows up on your phone, you tear it down when you're done. Spawn boxes like you spawn tabs.
Before writing the provider integration I sat down to check whether the thing actually made sense for the people who'd use it. It turns out it makes overwhelming sense for one group, no sense at all for another, and — the part I didn't expect — the two groups want architecturally opposite things.
The consumer number that ends the argument
The consumer pitch for a cloud VM is "replace the machine humming in your closet." Lots of people run an always-on box at home — a Mac mini, an old laptop, a NUC — as a place to leave things running. Put it in a datacenter instead. Better uptime, better bandwidth, no fan noise.
So what does the closet machine actually cost to run?
A Mac mini M4 idles around 4 W and peaks near 65 W. Call it 10 W average for a box that's mostly idle with occasional real work. That's 10 W × 730 h = 7.3 kWh a month. At the US residential average of 18.44¢/kWh (EIA, August 2026), 7.3 × $0.1844:
$1.35 a month. Sixteen dollars a year.
The closest cloud equivalent I could find — Hetzner's CAX31, 8 ARM vCPUs and 16 GB — runs €15.99 plus €0.50 for the IPv4, about $18.14 a month.
That's 13× the cost, for a machine with substantially worse single-core performance that can't run macOS. And that's against a mini you own, where the hardware is sunk. Buy one new to make the comparison fair and cloud still loses: $599 up front, a bit over a third of that back at resale in four years, is about $379 of real depreciation over 48 months — $7.90/month — plus the $1.35 of power, so $9.25/month all-in. Cloud still loses about 2:1.
There's no clever framing that rescues this. Hardware you already own is sunk cost, and even the amortized cost of new hardware is nearly free next to a monthly VM bill.
Unless you turn it off
The one variable that changes the picture is duty cycle. The CAX31 works out to $18.14 ÷ 730 h = $0.0249/hour, so if you only pay while the machine exists:
| Hours/month | Cloud | vs. mini you own ($1.35) | vs. mini bought new ($9.25) |
|---|---|---|---|
| 30 (1 h/day) | $0.75 | cloud wins | cloud wins |
| 60 (2 h/day) | $1.49 | break-even | cloud wins |
| 120 (4 h/day) | $2.99 | mini wins | cloud wins |
| 240 (8 h/day) | $5.98 | mini wins | cloud wins |
| 730 (always on) | $18.14 | mini wins 13× | mini wins 2× |
Two break-evens fall out, each just the mini's monthly cost divided by $0.0249/hour: $1.35 ÷ $0.0249 ≈ 54 hours a month against hardware you already own, and $9.25 ÷ $0.0249 ≈ 371 hours a month against buying it new.
Under two hours a day, cloud wins. Above it, the closet wins — and if the closet is already occupied, it wins by an order of magnitude.
So the consumer version of this feature isn't "replace your home machine." It's "rent a second machine for an hour." Those are different products with different UIs, and only one of them survives contact with a spreadsheet.
The exception worth naming: GPUs. A cloud RTX 4000 Ada runs about $0.84/hour. Twenty hours a month is $16.72, against $1,000+ to buy the card. There's no duty cycle at which owning wins for occasional GPU work. If your consumer story involves a GPU, everything above inverts.
The business number that ends a different argument
Now price the same VM as a business input. A fully-loaded US developer costs roughly $100/hour, or $1.67/minute. Convert infrastructure into developer-minutes by dividing the monthly bill by $1.67:
| Infrastructure | $/month | = dev time/month |
|---|---|---|
| One Hetzner CX22, always on | $4.72 | 2.8 minutes |
| One machine0 small, always on | $9.49 | 5.7 minutes |
| Ten CX22s, always on | $47.20 | 28 minutes |
| Twenty CX22s, always on | $94.40 | 57 minutes |
| GitHub Codespaces, 2-core, 160 h/mo | $28.80 | 17 minutes |
A box has to save under three minutes a month to pay for itself. Twenty boxes have to save under an hour, collectively, across a team.
No business declines this on cost. Which means every minute spent optimizing the cost of business dev VMs is wasted — the decision was never financial. It's about isolation, parallelism, whether the box has your tools on it, and how fast it comes up. Cost only reappears at hundreds of always-on instances, and by then it's a fleet-management problem, not a pricing one.
The asymmetry, which is the actual finding
Here's what I didn't see coming. Both segments want a cloud VM. They want opposite machines.
Business wants the box always on. It's a place things run — a build, an agent, a long job. Idle time costs three minutes of salary a month, so nobody thinks about it. Persistent presence is the entire value: it's there when you reach for it.
Consumer economics only work below roughly a two-hour daily duty cycle. Which means the machine must be off — suspended, destroyed, scaled to zero — for most of its life. For this user, the desirable steady state is not running.
That's not a preference difference. It's an architectural one, and it lands directly on the thing I'd already built.
reminal keeps a lightweight background host on every machine you own, so an idle box still appears in your list and can spawn a session on demand. Idle-but-reachable is the whole point. But a machine that is always reachable is a machine that is always billing — so for the consumer case, my architecture treats the economically correct state as a failure. An offline machine renders as a problem, when for that user it's the goal.
Fixing it isn't cosmetic. It means a third machine state — suspended — where the local record persists, the machine is genuinely gone from the network, and waking it goes through the provider's API rather than the relay. Nothing about ownership or presence gives you that for free. It only becomes visible when you price the idle hours.
Two smaller things the math settled
Billing granularity is a red herring. A 20-minute session costs $0.0043 on per-minute billing, $0.008 on per-second, and $0.0249 on Hetzner's hourly (you buy the whole hour). The entire spread is two cents. Choose a provider for its suspend semantics, its API, or its boot time — never for billing resolution. It changes how the number reads, not what it is.
For consumers the risk isn't cost, it's forgotten cost. $18/month of VM that someone stopped using is invisible inside a company and a support ticket at consumer scale. Idle auto-destroy, a cap on machine count, and a visible running total are consumer requirements. For business they're barely worth building.
What I'm doing with this
I'm still building reminal new machine. But I'm not positioning it as a replacement for the machine in your closet, because that claim doesn't survive $1.35 a month. It's a way to get an extra box for an hour — and for teams, a way to stop running five things serially on one laptop.
The general lesson is cheaper than the specific one. The same feature, priced against two different alternatives, produced two different products with incompatible defaults. Not two markets to segment later — two architectures, diverging at the point where you decide what "idle" means. That's worth finding before you write the provider integration, not after.