2
3 Comments

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.

posted toAvatar for product KilawattCloud
KilawattCloud
  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.