Every team that rents GPUs for real work knows the same quiet fear. The job is hours in. The machine belongs to a stranger. At any minute, it could vanish.
A host drops offline. A listing ends. A supplier reclaims capacity. The job dies, the clock keeps running, and someone finds out later.
Damian Christopher Dixon is building a company to take that fear off the customer’s desk. It is called Kilawatt Cloud, and Dixon is its solo founder in Los Angeles. His idea is simple. Separate the job from the machine, so that when one machine disappears, the work simply lands somewhere else.
The founder
Dixon runs Kilawatt alone. He is the chief executive of a company that trades as Kilawatt Cloud under Right Recruit LLC. There is no big team behind the product yet, and no funding announcement doing the talking. The work speaks through public tests, and Dixon publishes the results himself.
His starting point is the way GPU capacity actually looks today. It is spread across more suppliers, more kinds of operators and more kinds of hardware than any one customer can track. A customer who rents from one supplier inherits that supplier’s failure modes. Kilawatt sits across several suppliers instead, so no single one of them can take a job down.
The model works like this. A customer submits a command and a time limit, and sets a spending ceiling. Kilawatt runs the job, watches it, and settles it. Billing runs by time from launch, with a 60-second minimum. If the job finishes early, the unused contract time is returned. If the machine underneath it is lost, the job is placed on another supplier and runs to completion. The result is checked by its hash, so the customer can verify the finished work is the work that was asked for.
Software that buys its own compute
The most striking part of Kilawatt’s story is who does the buying. Dixon’s team built an open-source extension, kilawatt-mcp-server, that lets the goose agent quote a GPU job, pay for it in USDC on Base through the x402 standard, and check its status. The package is published on npm, and Dixon says it is listed in the MCP Registry.
The agent cannot spend freely. It refuses to pay without an explicit confirmation. It enforces per-job and per-session spending caps. And it never prints keys.
On October 10, an agent running inside goose bought ten GPU machines from Kilawatt, one request at a time. Each was an NVIDIA RTX A4000 booked for 20 minutes at four cents. There was no account, no invoice, and no API key handed over in advance. The agent asked for a price, signed a USDC payment authorization, and a settlement service moved the money on Base.
All ten machines came up and shut down on schedule. They ran 1,202 to 1,240 seconds against 1,200 booked. Total paid was 40 cents, in ten settled USDC payments. A health agent inside the machines logged 195 readings, and every one said healthy.
Dixon does not oversell that run. The wallet was Kilawatt’s own, so it is not customer revenue and not a customer result. No training workload ran, so the GPUs were close to idle. The ten machines came from one supplier, and the run should not be read as the platform average. In earlier testing since September 21, 41 percent of launches never became ready, and every one of those was refunded.
A bigger run on October 8 makes the same point at larger scale. An agent attempted 329 x402 GPU jobs in one sitting, and 200 reached a ready state, a 61 percent ready rate. Seventy-two could not be placed and were never charged. Fifty-seven were placed but never became ready and were refunded to the account balance. Total paid was 17.73 dollars, with 1.82 dollars refunded automatically. Four GPU suppliers were in the routing mix, and eight long stability jobs running alongside all stayed healthy. Again, this was Kilawatt’s own test from its own wallet, not customer demand.
The kill test
On October 25, Kilawatt put its core promise to its hardest test on live hardware, using its own test account with the feature held behind an owner-only switch. Seven end-to-end scenarios all passed on the final code. They covered the safety switch, a clean finish, a clean failure, a time limit, a verified host, a known result checked by hash, and the kill test itself.
The kill test, drill E, is the one that matters. A job was submitted and its first machine took about 125 seconds to boot and report in. It ran for 45 seconds. Then the team deleted that machine through its supplier’s own interface, exactly the way a real loss looks from outside.
Kilawatt confirmed the loss 123.3 seconds later. About 3.5 seconds after that, it placed a replacement on a different supplier. The job ran to completion there. The result matched its expected output and hash. Settlement landed 2.8 seconds after the job finished, and both machines read back as gone from their suppliers.
One job, two machines, two suppliers. The gap in the middle is the time Kilawatt took to confirm the first machine was really gone.
They ran it again. The second drill confirmed the loss in 140.9 seconds, re-placed the work, and finished with the identical result. Those numbers are measured in minutes, not milliseconds. Dixon says that is deliberate. Confirming a loss carefully, rather than on one bad reading, is how you avoid killing a healthy job over a blip. Detection is slower than he wants it to be, and he says so himself. The honest shape of the promise is that the work moves to another supplier and finishes, and the total time limit is built around how long confirmation takes.
Settlement, once a job finishes, is fast. Most jobs in the seven scenarios settled within seconds, and one verified-host job settled 2.6 seconds after finishing.
How quickly finished jobs settle. The 60-second billing minimum stretches one bar to 59 seconds.
What broke first
The road here was not clean. Early attempts at the clean-failure scenario were refused before launch when a supplier had no stock of the requested card. Nothing launched, and nothing was billed.
Early kill-test attempts exposed weak spots in billing on re-placed jobs and in how quickly a lost machine was confirmed. Both were fixed, and every result Kilawatt now cites comes from the corrected code.
A host-selection filter now keeps jobs off marketplace machines that fail to bootstrap reliably. A booking-window issue, where a slow-booting machine could outlast its booking, led to a minimum-duration check that is deployed and being re-proven.
We would rather find them in our own tests than in a customer’s job.
That is Dixon’s line, and it explains why the company publishes failures at all.
The capacity underneath
Behind the jobs sits a read-only census. Every six hours, it lists what five suppliers have available. It has now completed 39 runs since October 16.
In that time, it has seen 656 distinct capacity sources across 12 GPU types. About 640 of them appeared in the last seven days, and a typical day shows roughly 325 to 385. Since October 17, a single run has seen between about 180 and 264 sources. The most recent run saw 264.
Distinct capacity sources seen in each census run. The marketplace-style supplier supplies most of them.
Those numbers need a careful reading. These are sources seen available. They are not 656 suppliers, and a listing is not proof that a job ran there. The jobs are the proof. The census is the map.
The map also shows where Kilawatt is thin. One supplier alone accounts for 606 of the sources, 92 percent of the total, while the other four contribute far less. By GPU type, the RTX 4090 and RTX 3090 dominate the listings, with data-center cards like the A100, H100 and H200 much scarcer.
Where the sources sit. One supplier holds 92 percent, and workstation cards outnumber data-center cards.
Where this is going
The direction is simple to state and demanding to deliver. The machine under a job should become an implementation detail.
First, Dixon wants to work alongside the people who own the hardware. The shape he describes is one where a data-center operator keeps its own platform, customers and terms, and connects its capacity to Kilawatt as one more supplier behind the control plane. For the operator, that means its infrastructure can take on jobs arriving through Kilawatt, and its own customers gain somewhere else to go when a machine fails. For the customer, it means more places for a job to land. No partners are announced yet.
Second, Kilawatt is working toward ten or more suppliers, with more data-center capacity, so that failing over to a different supplier is a real choice and not a thin one.
Third, every contract will carry a mandatory customer-set ceiling before job contracts open beyond Kilawatt.
Fourth, failure drills will get harder, with different machine types, different supplier mixes and unforced routing, repeated until the results are boring.
Behind those four goals sits unfinished work, and Dixon names it. How a running job behaves when the feature is switched off is being tightened, and a few remaining checks are still to be re-proven. Each result will be published the same way as the ones before it.
None of this is a promise that outages stop happening. Hardware fails, suppliers change, and networks drop. The goal is narrower and more useful. When it happens, the job has somewhere else to go, and the customer gets a result that can be verified by its hash.
Why it matters
Dixon’s bet is that infrastructure is believed one measured result at a time, and that many claims in this market are hard to check. His answer is to publish the numbers, including the slow ones, and let readers judge.
For anyone following the company, the test is simple. The test reports are published on Kilawatt’s Super Intelligence page, and the company says every future result, pass or fail, will be published the same way. If the drills keep getting harder and the misses keep being shared, the story will have earned its confidence. If the reports stop, that will be an answer too.
Kilawatt Cloud can be reached at hello@kilawattcloud.dev. Its public test reports are on the Super Intelligence page, and the agent extension is published on npm as kilawatt-mcp-server.
Disclosure: The facts and figures in this article come from Kilawatt Cloud’s October 25, 2026 job contracts and capacity report and from the founder’s account of the company’s tests. The AI Landscape has not independently verified them. Capacity sources are distinct listed machines or offer pools seen available in read-only supplier listings. They are not a count of suppliers or customers, and they do not show that a job ran on each one. Test results come from Kilawatt’s own test account on live supplier machines, with the feature held behind an owner-only switch. Traffic so far is small and mostly Kilawatt’s own testing.
