KilawattCloud

Multi-provider GPU cloud with automatic failover

Visit Website
September 8, 2026 Why we built the toll booth before the traffic showed up

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.

3 Comments

  1. 1
    The 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?
    1. 1
      Great 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.
      1. 1
        That'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.
September 6, 2026 The data center backlash doesn't touch us, here's why

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.

kilawattcloud.dev

Comment

September 5, 2026 Kilawatt Cloud is live

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.`

5 Comments

  1. 1
    The stockout pain is clear. Have early users actually recovered enough failed-run time or compute cost through failover to make Kilawatt worth paying for?
    1. 0
      xd 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.
      1. 1
        That 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?
        1. 1
          hello@kilawattcloud.dev, happy to keep this going as real usage data comes in.
          1. 1

            Thanks! I’ve just sent it over.

            Looking forward to hearing your thoughts whenever you have a chance.

About

I kept watching AI teams lose training runs because a single GPU provider ran out of stock mid-job. There was no fallback, just a stalled task and wasted time. Kilawatt Cloud exists to fix that by routing compute across