KilawattCloud
Multi-provider GPU cloud with automatic failover
For weeks the only "customer" touching Kilawatt Cloud was me, testing my own infrastructure.
This morning that changed, just not the way I expected. It wasn't a person who signed up first. It was an AI agent. It hit my API, got a 402 Payment Required response, signed a payment from its own wallet, and had a GPU running four seconds later. Four cents, but real money, on-chain, verifiable.
I built the toll booth because I kept watching AI teams lose training runs when a single GPU provider ran dry mid-job. That part hasn't changed. What's new is x402, an old, unused HTTP status code that Coinbase and a few others are turning into a real payment rail for machines. No signup. No API key. No human clicking "approve." Just code paying code.
It's a strange thing to build toward for weeks and then watch happen with no ceremony at all. No email notification, no Slack ping, just a line in a terminal and a transaction hash. I sat there for a second not totally sure what to feel.
Revenue's still $0/mo on here, and honestly, four cents doesn't move that number. But something did change this morning that a bigger check wouldn't have told me: the toll booth works, unattended, exactly the way it's supposed to when no one's watching.
Docs for anyone curious how the payment flow actually works: kilawattcloud.dev/docs/x402
A few months ago I kept watching the same failure pattern: an AI team's training run would stall mid-job because their one GPU provider ran out of stock. No fallback, just a dead task and wasted money. That's the problem Kilawatt Cloud actually started as, routing compute across multiple providers so one outage doesn't kill your job.
But building the failover logic made me notice something bigger. Every cloud platform today, including ours at first, assumes a human is the one deciding to spend money. Log in, pick an instance, click confirm. That assumption is already starting to crack. AI agents are beginning to provision their own compute mid-task, with no person clicking anything.
When that happens, something still has to sit in the middle. Verify there's balance. Pick the right provider in real time. Route around failures. Settle the payment. All of it invisible, machine to machine. Basically a toll booth for compute.
I didn't build that part speculatively. It's already running. Every job on Kilawatt checks wallet balance and pre-authorizes cost before it starts, the same mechanic a machine-to-machine toll booth would need. We route across four GPU providers with real automatic failover, tested live, not just diagrammed. And the control layer is MCP-native, published on npm and the official MCP registry, so an agent can already provision compute directly, no dashboard required.
I don't know exactly when machine-to-machine billing becomes normal. Could be later than I think. But the toll booth mechanics don't cost anything extra to have ready early, and if that world does arrive, I'd rather already be standing there than scrambling to bolt it on after everyone else has moved.
Launching on Product Hunt tomorrow, September 9th. Built solo, every number tested before it's claimed.
-
1The machine-to-machine toll booth is where this gets much more interesting than GPU orchestration. If an agent can provision compute and commit spend without a human in the loop, I think there are actually two separate things the infrastructure eventually needs to establish: 1. Was this spend/resource allocation authorised? 2. Was it still authorised when the consequential execution actually occurred? The second gets particularly interesting with your automatic failover. Suppose an agent is authorised to provision a particular workload under defined cost/provider conditions. Kilawatt pre-authorises it, provider A becomes unavailable, and the job is automatically rerouted to provider B under different price or execution conditions. The original authorisation may have been perfectly valid — but does it automatically cover the substituted consequence? That's a boundary we've been exploring with OpsWatch: valid authority earlier isn't necessarily current authority at the point of consequence, and the evidence of what was authorised needs to be separable from evidence of what actually executed downstream. With Kilawatt already doing real four-provider failover, where do you currently draw that boundary? Does failover inherit the original authorisation, or are there conditions that force a fresh authority decision before the replacement provider executes?
-
1Great question. Answer: price stays locked. Kilawatt bills at a fixed customer price, not a pass through of whatever the backend provider charges. So when failover kicks a job from Provider A to Provider B, the agent's original authorization still covers it. We eat the variance, not them. Where it gets genuinely hard: non price conditions. If an agent authorized a job assuming region X and failover silently moves it to region Y, that's a real gap. Haven't fully solved it yet. Most people won't even ask this question until it's already a production incident. You asked it now. That's rare. Appreciate it.
-
1That's exactly the boundary I was trying to isolate. If price is fixed, then failover doesn't alter the customer's economic authorization. But region is different because it can be part of the conditions under which the action was authorized in the first place. So I think the interesting question becomes: what happens if the failover is technically permitted, but the replacement execution no longer satisfies one of those original conditions? I wouldn't necessarily call that a failed job. I'd call it an authority revalidation problem. Before Provider B executes, something needs to determine whether the original authorization is still valid for the new execution context — and if it can't establish that, fail closed rather than treating Provider A → B as an implementation detail. That's very close to the boundary I've been working on with OpsWatch. Your region X → Y example is actually one of the clearest real-world cases I've seen for it.
-
-
Communities across the country are pushing back hard on new data center construction, real grid strain, real water concerns, political fights strong enough to flip elections in the last year.
That fight is about who gets to build new physical facilities. Kilawatt Cloud doesn’t build data centers, we route compute across providers who already have infrastructure, RunPod, Vast.ai, Lambda, Hyperstack, choosing whichever has real capacity and the best price right now.
We’re not fighting county boards for permits or explaining diesel generators to a city council. Not because we’re clever, just because we don’t need to own the dirt under the servers.
As physical expansion keeps getting harder, models that don’t require new land, water, or grid capacity get more resilient by comparison. Curious if others building in this space have been thinking about this too.
published Kilawatt Cloud, a GPU orchestration platform that routes AI/ML workloads across RunPod, Vast.ai, Lambda, and Hyperstack with automatic failover, so a training run doesn’t die just because one provider ran out of stock.
Self-serve, per-second billing, zero egress fees. Built this from a two-bedroom apartment after watching too many builders lose runs to GPU stockouts.
Live now at kilawattcloud.dev. Would genuinely love feedback from anyone here who’s hit this exact problem.`
-
1The stockout pain is clear. Have early users actually recovered enough failed-run time or compute cost through failover to make Kilawatt worth paying for?
-
0xd too early to have customer data on that yet, just launched. What I can say is the failover itself is live and tested, real create-and-destroy verification across all four providers, and it's already caught real pricing/availability differences between providers during testing (one GPU type was 3x more expensive on one provider vs another at the same moment). The core bet is that avoiding even one stalled run is worth more than the platform costs, especially since it's per-second billing with no markup for the failover itself. Would genuinely love to have you as an early user to help answer this with real data instead of a guess.
-
1That 3x price difference makes the economic case more concrete, but the “one stalled run” value is still the key thing to validate. I’d be interested in digging into that with you as the real usage data comes in. Happy to continue privately — what’s the best email to reach you on?
-
-
3 Comments
The four cents don’t validate demand by themselves, but the unattended transaction is a meaningful behavioral signal. Do you know whether that agent was independently choosing Kilowatt Cloud for the GPU, or was this still effectively a controlled test of the payment flow?
Good question, and I'll give it to you straight instead of dodging: no, this wasn't an agent autonomously discovering Kilawatt in the wild. It was my own test client, funded and run by me, built specifically to prove the payment rail actually settles on-chain instead of just returning a 200 and calling it done.
I'm not going to dress that up as more than it is. Plenty of "launches" quietly skip this step and let people assume otherwise. I'd rather tell you exactly what was proven and what wasn't.
What's proven: the infrastructure works, end to end, with a real transaction hash you can check yourself. What's not proven yet: real agents choosing this autonomously at volume. That's the next milestone, and I'll be just as direct when I get there.
That separation between infrastructure proof and autonomous demand is useful. If you’re open to it, what’s the best email to reach you on?