Harshal Gajjar

Harshal Gajjar is an AI Forward-Deployed Engineer at C3 AI, based in the San Francisco Bay Area. Harshal leads Agentic AI harness development for the Forward-Deployed Engineering organisation at C3 AI, and since January 2026 has been building a stealth-mode startup in the Agentic AI space. Harshal cofounded Shram.io in 2024, where he led the pivot from a Jira-competitor product to an AI assistant that reached #2 Product of the Day on Product Hunt.

Harshal holds an M.S. in Computer Science (Machine Learning specialisation) from Georgia Tech and a B.Tech in Computer Science from IIT Dharwad, where he was part of the institute's foundational class. He spent three summers at Wolfram Research in Boston — first as a summer researcher in 2018, then as an instructor for high-school students in 2019 and 2020 — and was a Wolfram Student Ambassador throughout his undergrad.

Outside of work, Harshal is a long-distance cyclist and a vertical and horizontal caver, active with the San Francisco Bay Chapter (SFBC) grotto. In 2019 he was part of the Hubballi Bicycle Club Guinness World Record for the longest single line of bicycles.

Contact Harshal at mail@harshalgajjar.com.

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/monthCloudvs. mini you own ($1.35)vs. mini bought new ($9.25)
30 (1 h/day)$0.75cloud winscloud wins
60 (2 h/day)$1.49break-evencloud wins
120 (4 h/day)$2.99mini winscloud wins
240 (8 h/day)$5.98mini winscloud wins
730 (always on)$18.14mini 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.722.8 minutes
One machine0 small, always on$9.495.7 minutes
Ten CX22s, always on$47.2028 minutes
Twenty CX22s, always on$94.4057 minutes
GitHub Codespaces, 2-core, 160 h/mo$28.8017 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.

#reminal#tools#fde#economicsreminal on GitHub