DEV Community: Damian Dixon

"Nvidia B200 Chips, Rented by API: 31 of 33 Jobs Came Up Ready"

Damian Dixon — Tue, 13 Oct 2026 03:39:44 +0000

We rented Nvidia B200 GPUs through a single API call, 33 times, and measured what happened. Every job in this run was a B200. Here are the results.

What we ran

Kilawatt Cloud is an orchestration layer that routes GPU jobs across multiple suppliers. In this run we sent 38 B200 requests to the API. The router launched 33 of them: 30 five-minute jobs and 3 one-hour jobs. Across those 33 jobs we launched 39 cards.

The headline numbers

31 of 33 launched jobs came up ready (94%). The two that did not were refunded automatically.
37 of 39 cards came up ready.
25 of the 31 ready jobs were ready in under 60 seconds.

By supplier

RunPod: 13 launched, 13 ready. Median time to ready was 8 seconds. The slowest was 14 seconds.
Vast.ai: 20 launched, 18 ready. Median time to ready was 44 seconds. The slowest was 316 seconds.

The one-hour test

The RunPod one-hour job ran the full hour. We checked its health 87 times and all 87 checks passed. It logged 0 XID errors, 0 uncorrectable ECC errors, and a peak GPU temperature of 34C.

Both Vast.ai one-hour jobs stopped about 15 to 16 minutes in. That was at the supplier account level, not a hardware fault. We are not counting them as host failures.

What did not launch

Five requests for four cards at once could not be placed. RunPod had no machine available, and the Vast.ai quote for four cards failed our pricing check. Nothing was charged for those requests, and the router skipped them instead of forcing a bad launch.

What this does and does not show

This is a small run on one GPU type. It measures how fast and how reliably the router gets a B200 to ready. It does not yet measure what happens when a host dies mid-job. That is the next test we are building: checkpoint-aware jobs that resume on a second supplier. We will publish the timings we measure, whatever they are.

Read the full report

The full report, with charts and the job-by-job breakdown, is on our Super Intelligence page:

kilawattcloud.dev/super-intelligence

Open the latest entry, "Nvidia B200 Chips, Rented by API: 31 of 33 Jobs Came Up Ready", to read or download the PDF. We publish each test run there, including the ones that do not go perfectly.

Questions about the method or the raw numbers are welcome in the comments.

An Outside Tester Found Nine Problems in Our x402 Endpoint. Here Is Every Fix.

Damian Dixon — Sun, 11 Oct 2026 06:45:03 +0000

On Oct 10, an outside tester applied to test Kilawatt Cloud's x402 pay-per-job GPU endpoint. We sent a small amount of USDC to their wallet. They bought one 60-second GPU job for one cent, then sent back nine findings about how the endpoint behaves when things go wrong. Two of the nine could cost a buyer money.

We changed all nine in code within hours. We have since re-checked five of the eight headline fixes against the live service. Three still need a paid call to verify. This post is the full account, including the parts that are not proven yet.

The two that could cost a buyer money

1. Malformed JSON became a default H100 job. A request with a broken body was not rejected. It was quietly priced as a default H100 job at about 38 cents. An agent that signs payments automatically could have paid for work it never asked for.

2. A replayed payment returned a vague 402. Resending an already-settled payment did not return a clear conflict. A client that lost its response could not tell "already paid" from "failed", which risked a duplicate payment or a lost one-time API key.

Both are fixed in code. The first one is also confirmed live.

All nine findings and what changed

#	What the tester found	What changed	Checked
1	Broken or non-JSON requests quoted as a default H100 job	Body parsed first. Invalid JSON, a non-object or an array returns 400 `invalid_json`. Wrong content type returns 415. Empty body still gets documented defaults.	Live
2	Replayed settled payment returned a vague 402	Clear 409 `payment_already_used` with the original transaction and job where known. A unique transaction-hash check remains as a backstop.	Code
3	`price_changed` code missing	Both protocol versions return `price_changed`. Version 2 also returns the new required amount.	Code
4	Unfunded wallet or bad signature gave an opaque error	One stable code, `insufficient_funds_or_invalid_signature`, plus a hint. It cannot tell the two causes apart, so this is only partly fixed.	Code
5	Unknown GPU name returned 503, no list of valid names	400 `unknown_gpu_type` with the 16 valid names. Oversize requests return 400 `size_not_available`. 503 stays for real capacity misses.	Live
6	GET on the endpoint returned website HTML, no discovery file	JSON 405 with an `Allow` header. `/.well-known/x402` returns a JSON manifest.	Live
7	Misleading errors when a payment header was in the wrong place	400 `wrong_payment_header`. Unreadable amounts return 400 `malformed_payment`.	Code
8	Job receipt had no ready time, end time or runtime	Receipt returns `created_at`, `ready_at`, `ended_at`, `runtime_seconds`.	Live
9	Internal payment ID and exact supplier cost in responses	Payment ID removed. Supplier cost still returned, but rounded and labeled approximate. Hiding it fully is under review.	Live

"Live" means we sent a request to the public service on Oct 11 and read the response. "Code" means the change is in the source and has not yet been exercised on the live service. Items are numbered in our fix order, not the tester's order.

How we re-checked the live ones

You can run these yourself. They are plain requests, nothing paid.

# Malformed body and a bare array: expect 400 with code invalid_json
curl -si -X POST https://www.kilawattcloud.dev/api/public/x402/exec \
  -H "Content-Type: application/json" -d '[1,2,3]'

# Wrong content type: expect 415 unsupported_media_type
curl -si -X POST https://www.kilawattcloud.dev/api/public/x402/exec \
  -H "Content-Type: text/plain" -d 'hello'

# Wrong method: expect 405 with Allow: POST, OPTIONS
curl -si https://www.kilawattcloud.dev/api/public/x402/exec

# Discovery manifest: expect 200 and JSON
curl -si https://www.kilawattcloud.dev/.well-known/x402

On Oct 11 between 05:05 and 05:10 UTC these returned 400 invalid_json, 415, 405 with Allow: POST, OPTIONS, and a 200 JSON manifest. An unknown GPU name returned 400 with the list of 16 valid names. A job receipt requested without a key returned 401. With the account's own key it returned 200 and the new timing fields, with no internal payment ID.

For the receipt of a 1,200-second job, the new fields read: created 03:28:24, ready 03:29:05, ended 03:49:02, runtime 1,238 seconds. The runtime includes the short lag before a machine is shut down after its booking runs out.

What we have not proven

Three headline fixes are not live-verified. The replay 409, the price_changed code and the short-wallet code (items 2, 3, 4) are in the source. Checking them live needs a paid call or a deliberately failed payment. They are marked code only.
Item 4 is only partly fixed. One combined code covers an unfunded wallet and a bad signature. A buyer cannot tell which one it was.
Supplier cost is still visible. It is rounded to the nearest 10 percent of the billed amount and marked approximate. A buyer can still estimate our margin from it.
Untested paths. The refund when no capacity is available after payment, credit for an overpayment and recovery of the one-time API key after a lost response were not tested in this round.
One tester, one paid job. We did not verify the tester's identity or claims, and this is not a penetration test or a security audit.
What held up is the tester's word. They reported that refusals on a wrong recipient or network, schema validation, CORS, rate limiting and the price re-quote guard behaved correctly. We did not re-test those for this report.

The paid job itself was funded by us (3 USDC sent to the tester's wallet, one cent spent), so it counts as sponsored, not customer revenue.

Lessons if you are building an x402 endpoint

Parse the body before you price anything. A default quote on a broken request is a money bug, not a cosmetic one.
Make replays boring. Return a clear 409 with the original transaction, so a client that lost a response can recover.
Give every failure a stable machine-readable code. price_changed, unknown_gpu_type and wrong_payment_header are cheap to add and save agents from guessing.
Publish a discovery manifest and return JSON on the wrong method. Agents should never have to parse website HTML.
Put timing in the receipt. ready_at, ended_at and runtime_seconds let buyers audit what they paid for.
Do not leak internal IDs or exact costs in buyer responses.

Read the full report

The full report has the three charts, the paid-job record with its transaction hash, the method, and the limits:

https://kilawattcloud.dev/super-intelligence

Look for "Outside Tester Report 1: Nine Findings, Nine Changes" under Security.

If you want to test the endpoint, or you find something we got wrong, tell us: hello@kilawattcloud.dev

Kilawatt Cloud is a trade name of Right Recruit LLC. This is a company-prepared report, not independent reporting.

"Goose AI x Kilawatt Cloud: An AI Agent Bought Ten GPUs With USDC. We Checked Every Receipt."

Damian Dixon — Sun, 11 Oct 2026 06:21:30 +0000

On the evening of Oct 10, an agent running inside goose, the open-source desktop agent, bought ten GPU machines from Kilawatt Cloud, 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.

What happened

All ten machines came up and shut down on schedule, running 1,202 to 1,240 seconds against 1,200 booked.
Not one refund.
The health agent inside the machines logged 195 readings, and every one said healthy.
Peak GPU temperature across all ten runs was 73 C.
Total paid: $0.40, in ten settled USDC payments.

How it works

Kilawatt publishes an MCP server with x402 tools. The agent quotes a price, checks it against local limits, signs the payment, pays, and gets back a job ID and receipt. You can see the discovery manifest yourself:

curl -s https://www.kilawattcloud.dev/.well-known/x402

The temperatures

Nine of the ten runs peaked on the first reading, then settled at 44 to 48 C within about ten minutes. These are not load temperatures. The job request has no training command, so the GPUs were close to idle.

What this does not prove

This is a small test, on our own money. The wallet is ours, so it is not customer revenue and not a customer result. No training workload ran. Earlier in our own testing, 41 percent of launches (178 of 439, since Sep 21) never became ready, and every one of those was refunded. These ten are a clean run on one GPU model from one supplier, Vast.ai, and should not be read as the platform average. The report says all of this in plain words.

Check it yourself

Every payment hash and job ID is in the full report, so you can look the payments up on Basescan. The report has six charts, the proof tables and the limits:

https://kilawattcloud.dev/super-intelligence

Look for "x402 Goose Stability Run: Ten GPUs, No Refunds" under MCP / Agent Layer.

If you want to run a test against the endpoint, or you find something we got wrong, tell us: hello@kilawattcloud.dev

Independent test by Kilawatt Cloud. Not affiliated with or endorsed by Block or the goose project.

Free x402 GPU test for agent builders: first 10 testers get test funds

Damian Dixon — Fri, 09 Oct 2026 15:13:07 +0000

Hi, I'm Damian, CEO of Kilawatt Cloud. If you build agents that need to pay for compute, I'd love your help testing something. You're welcome here whether you've shipped ten agents or you're about to ship your first.

What we built

Kilawatt Cloud is a gateway where an AI agent pays per GPU job with x402 (USDC on Base) and gets a machine routed from one of several suppliers, with automatic failover. No account setup and no API key signup for the agent. It pays, and it gets a machine.

Where we are, in honest numbers

On October 8 we ran 329 x402 GPU jobs in one sitting and 200 reached ready state. That is a 61% ready rate. Here is how the rest broke down:

72 could not be placed, and they were never charged.
57 were placed but never became ready, and they were refunded to the account balance.

That run was our own test from our own wallet. It is not customer demand, and I won't pretend it is. The full report, including the misses, is here: https://www.kilawattcloud.dev/super-intelligence

The invite

We are opening a free test to the first 10 approved testers worldwide. You get:

About $3 in USDC on Base, sent to the wallet you give us. That covers dozens of short test jobs.
Access to the live x402 endpoint, with a quick start here: https://www.kilawattcloud.dev/docs/x402
A direct line to me if anything breaks.

How to join

Email hello@kilawattcloud.dev with the subject "x402 test", your Base wallet address, and one line on what your agent does.
We screen the wallet, confirm by reply, and send the test funds.
Your agent calls the endpoint with its own x402 client, pays, and gets back job, payment and health details. The endpoint provisions GPU capacity. It does not run your code.
Tell us what worked, what broke, and what you would change.

What I'm asking in return

Honest feedback, including the rough edges. If something fails, that is exactly the data we need. In our design your wallet only signs a payment authorization, so it should not need ETH for gas. If anything asks for gas, please tell me, because that's a bug I want to fix.

What we record, and what we do with it

We keep payment records, job records and machine health data on our side, so we can check results against what your test actually did. Anything we publish is aggregated and anonymous. We name you, your company or your wallet only with your written permission. Jobs on test funds are marked "sponsored" in our records, and we don't count them as customer revenue.

The fine print

Limited to the first 10 approved testers, one per person or team. Test funds are for test jobs only. Refunds and unused funds stay as credit on your account balance and are not returned on-chain. No obligation to buy anything, and no partnership or commitment of any kind.

Questions? Ask below and I'll answer in the comments. If you'd rather not run a test, I'd still love to hear what you'd want from agent payments for compute.

Thanks for reading.

Damian Dixon
CEO, Kilawatt Cloud (d/b/a Right Recruit LLC)

We ran 329 x402 GPU jobs in one sitting. 200 landed.

Damian Dixon — Fri, 09 Oct 2026 02:47:12 +0000

Today we ran our biggest live test of Kilawatt Cloud so far. An autonomous agent paid for GPU jobs with x402 (USDC on Base), sent them through our gateway, and we counted what actually happened.

The numbers, straight from our database:

329 jobs attempted, each one paid for through x402.
200 jobs landed, meaning the machine reached a ready state. That's about 61 percent.
$17.73 paid in total, with $1.82 refunded automatically on jobs that never became ready.
Four GPU suppliers were in the routing mix.
We also ran 8 long stability jobs alongside the launches, and all 8 stayed healthy.

What this was, and wasn't: This was our own test, run from our own wallet. It is not customer traffic, and I'm not presenting it as demand. It is evidence that the payment, routing and refund path works under load, with real money and real hardware.

What we learned: The 129 jobs that didn't land are the most useful part of the data. Some suppliers had streaks of machines that never became ready, and one supplier we had to pause under a spend cap. Because the refund path worked, those failures cost us cents and not trust. That's the point of routing across multiple suppliers.

We started the day aiming for 100 landed jobs and ended at 200. Next run, we're aiming for 400.

If you build agents that need to buy compute on their own, I'd like to hear what breaks for you. The full run report, with the results by supplier, the hardware health data and the failures, is on our Super Intelligence page: https://www.kilawattcloud.dev/super-intelligence

Our MCP server is also on npm as kilawatt-mcp-server.

"We're not leaving: hunting B300s on demand across four suppliers (live x402 results)"

Damian Dixon — Tue, 06 Oct 2026 18:56:42 +0000

NVIDIA's B300 is the GPU everyone is asking about. So on October 2, 2026, we ran a live test to find out what is actually available to rent on demand right now.

An autonomous agent surveyed four suppliers for multi-GPU B300 capacity, then requested, paid for, and received a machine in USDC on Base. No account, no API key, no human intervention. Here is exactly what it found.

The survey

Before paying for anything, the agent read each supplier's live inventory.

Supplier	B300 availability at time of test
RunPod	Up to 2 cards in one machine, limited stock
Vast.ai	None in stock
Lambda	None in stock
Hyperstack	None in stock

RunPod was the only supplier with any B300 inventory, and its largest machine was two cards. Because no supplier listed a four-card or eight-card B300 machine, we did not attempt requests of that size.

The job

The agent requested the two-GPU B300 machine and paid for it on Base.

Supplier	Config	GPUs booked	GPUs ready	Time to ready	Paid	Outcome
RunPod	2x B300	2	2	17 seconds	$2.97 USDC	Delivered

Confirmed hardware: the supplier's own machine report confirmed two B300 GPUs.
Time to ready: the machine reached a healthy state 17 seconds after payment.
Lifecycle: it ran its ten-minute booking and shut down on schedule. Our platform recorded the shutdown at the ten-minute mark, and RunPod no longer listed the machine afterwards.
Real money: the payment was a real USDC transaction on Base against the production endpoint. Nothing was simulated.

What this tells you

The number of B300 jobs we could run was limited by market supply, not by the platform. Our platform can request B300 jobs up to eight cards per request, but only one supplier listed any B300 inventory that day, and only up to two cards.

That fits how a new GPU generation usually behaves. Capacity for a newly released generation is largely committed to long-term reservations, so on-demand inventory is scarce. If you need guaranteed B300 volume, on-demand marketplaces are probably not the right channel. Dedicated capacity agreements are, and that is a separate sourcing conversation.

Limits of this test

One snapshot: inventory was read immediately before the request, and stock is not a reservation. It may look different an hour later.
One job: a single two-GPU job is a live data point, not a benchmark. It says nothing about larger B300 configurations.
Platform and supplier records: figures come from Kilawatt Cloud's platform records and the supplier's own machine report.

What's next

We will re-check B300 availability across all four suppliers on a regular cadence, and run more two-GPU B300 jobs as stock allows. As soon as a supplier lists a larger single-machine B300 configuration, we will test it and publish the result the same way, failures included.

Read the full reports

Every live verification run we do is published in full, with the provider, GPU count, result, time and cost for each job. You can read all of them on our Super Intelligence page:

https://kilawattcloud.dev/super-intelligence

If you are building agents that need B300 capacity, or you have seen different availability on your side, we would like to hear about it.

Kilawatt Cloud: https://kilawattcloud.dev

"Four suppliers, real USDC, no accounts: the full results of our x402 GPU test"

Damian Dixon — Tue, 06 Oct 2026 18:42:14 +0000

On October 2, 2026, we completed the second live verification of the x402 pay-per-job service on Kilawatt Cloud. In Wave 1, every request went to a single supplier. This time we sent each request to a different one, so every supplier could be evaluated on its own.

As before: no simulation. An autonomous agent requested GPU capacity, paid in USDC on Base, and received machines with no account, no API key, and no human intervention. We are publishing everything, including the request that failed.

The test

Four placements across three additional suppliers: Lambda, Hyperstack, and RunPod. Each request was paid for on Base, ran for ten minutes, and went to the production endpoint. Every payment was a real USDC transaction, $4.88 in total.

Results

#	Supplier	Config	GPUs booked	GPUs ready	Time to ready	Paid	Outcome
1	Lambda	8x A100	8	8	5m 14s	$3.40	Delivered
2	Hyperstack	2x A100 PCIe	2	2	6m 15s	$0.58	Delivered
3	RunPod	8x A40	8	0	No capacity	$0.60	Not delivered, refunded
4	RunPod	4x A40 (retry)	4	4	13s	$0.30	Delivered

Delivery rate: 3 of 4 placements delivered, which is 14 of 22 requested GPUs.
Time to ready: delivered jobs reached a healthy state between 13 seconds and 6 minutes 15 seconds.
Combined with Wave 1: all four suppliers (Vast.ai, Lambda, Hyperstack, and RunPod) have now completed a successful multi-GPU x402 job, with 30 GPUs delivered in total.

What did not go perfectly

The first RunPod request, for eight A40 GPUs, could not be fulfilled because the supplier had no matching capacity. The platform returned the $0.60 payment automatically, as account credit, without any manual action. We then sent a follow-up request for four A40 GPUs, matched to confirmed availability, and it was fulfilled.

The refund was issued as account credit, not as USDC sent back to the wallet.

What this tells you, and what it does not

At the other suppliers, where the requested configuration was out of stock, the nearest in-stock multi-GPU configuration was used. That is why Hyperstack shows 2x A100 PCIe and not a larger node. So this test shows each supplier can deliver multi-GPU capacity through the payment flow. It does not show that each supplier can deliver the exact configuration you want at any moment.

Limits of this test

Small sample: four placements is not a benchmark. Treat the numbers as live data points.
Different configurations: the jobs were not identical, so the times are not a like-for-like speed comparison between suppliers.
Platform records: the figures come from Kilawatt Cloud's own records. The final RunPod job was running and healthy at the last status check, and we did not get independent confirmation from any supplier that each machine was terminated.

Read the full reports

Every live verification run we do is published in full, with the provider, GPU count, result, time and cost for each job, including the ones that failed. You can read all of them on our Super Intelligence page:

https://kilawattcloud.dev/super-intelligence

If you are building agents that need compute on demand, we would like to hear what you would want to see in a test like this.

Kilawatt Cloud: https://kilawattcloud.dev

[Boost]

Damian Dixon — Tue, 06 Oct 2026 18:32:48 +0000

Damian Dixon

Oct 6

"We let an AI agent pay for GPUs with USDC. Here is what happened (2 of 3 delivered, 1 auto-refunded)"

#ai #gpu #cloud #web3

2 min read

"We let an AI agent pay for GPUs with USDC. Here is what happened (2 of 3 delivered, 1 auto-refunded)"

Damian Dixon — Tue, 06 Oct 2026 18:31:32 +0000

On October 2, 2026, we ran a live verification of the x402 pay-per-job service on Kilawatt Cloud. No simulation. An autonomous agent asked for GPU capacity, paid in USDC on Base, and got machines back with no account, no API key, and no human intervention.

We are sharing the full results, including the part that did not go perfectly, because the failure is the most interesting part.

The test

Three requests for 8x NVIDIA A100 each, 24 GPUs in total. Each request was paid for on Base, ran for ten minutes, and went to the production endpoint. Every payment was a real USDC transaction ($1.55 per job, $4.65 in total).

Under standard routing, all three requests were served by a single supplier, Vast.ai.

Results

#	Supplier	Config	GPUs booked	GPUs ready	Time to ready	Paid	Outcome
1	Vast.ai	8x A100	8	8	4m 17s	$1.55	Delivered
2	Vast.ai	8x A100	8	0	Never became healthy	$1.55	Not delivered, refunded
3	Vast.ai	8x A100	8	8	4m 14s	$1.55	Delivered

Delivery rate: 2 of 3 requests, which is 16 of 24 GPUs.
Time to ready: both successful jobs reached a healthy state in about 4 minutes 15 seconds and ran their full ten-minute booking.
The failure: the third machine never became healthy. The platform detected it and refunded the $1.55 payment automatically, with no manual action. The refund was issued as account credit, not as USDC sent back to the wallet.

Why we are publishing the failure

Anyone can show a demo that works. What matters for agent-driven payments is what happens when a machine does not come up, because an agent has no one to complain to. The money is gone the moment the payment settles on-chain, so the refund path has to be automatic.

Limits of this test

Small sample: three requests is not a benchmark. Treat these numbers as one live data point.
Ready time: measured from placement to the first healthy status check, and checks run roughly once per minute, so figures have about a minute of resolution.
Platform records: the figures come from Kilawatt Cloud's own records. We did not get independent confirmation from the supplier that each machine was terminated.
Single supplier: standard routing sent all three jobs to the same place, so this test tells you about one supplier only.

Read the full reports

https://kilawattcloud.dev/super-intelligence

If you are building agents that need compute on demand, we would like to hear what you would want to see in a test like this.

Kilawatt Cloud: https://kilawattcloud.dev

Fists up: 9 live B200 and A100 jobs, 4 suppliers, 3 hits taken, every one refunded.

Damian Dixon — Wed, 30 Sep 2026 02:14:39 +0000

Today we ran live B200 and A100 jobs through Kilawatt Cloud's agent-exec API, the same path an AI agent uses to provision compute. Nothing simulated. Every job launched a real machine at a real supplier, and every machine was terminated and checked against the supplier's own records afterward.

The results: 6 of 9 launched jobs reached healthy

B200: both runs passed. RunPod was healthy in 0.5 minutes and Vast.ai in 1.6.
A100 (1 card): RunPod 0.2 min, Lambda 2.9, Hyperstack 3.5. Vast.ai never became healthy.
A100 (2 cards): RunPod passed in 1.0 min. Vast.ai failed twice.
Skipped: a 2-card A100 on Hyperstack, which our spend guard blocked because Hyperstack prices two cards as a whole machine.

What the run showed

B200 capacity is real and reachable through an API. Two live B200 jobs passed health checks on different suppliers.
Supplier speed varies a lot. The same A100 took anywhere from 0.2 to 3.5 minutes to become healthy depending on who supplied it. That gap is what a single-supplier setup makes you absorb.
We never substitute a card. Only RunPod and Vast.ai had B200 in stock. Lambda and Hyperstack reported no stock, so requests went only to suppliers that could deliver the exact card asked for.
Failed machines cost the customer nothing. All three Vast.ai machines that never finished booting were refunded in full, automatically.
Cleanup works. Every machine was confirmed gone against the supplier's own records.

The parts that aren't flattering

We're publishing these because a verification report that hides its problems isn't worth much.

Vast.ai boot reliability is still an open problem. Its A100 machines failed to boot on three launches, and it has failed on several runs across the day. Customers are always refunded, but we haven't solved the reliability itself yet.
Shutdown timing. During the run, one RunPod A100 finished its booking but wasn't shut down until the next 15-minute check. Customers were only billed for the booked time. We've since moved to a 1-minute shutdown check, and a live test afterward stopped a machine 6 seconds after its booking ended.
An extra Vast.ai launch. A supplier-pinning step didn't take effect on the first try, so one RunPod job landed on Vast.ai. It was a valid launch with no card substituted, and it was refunded. We've disclosed it in the report.
Vast.ai's marketplace moves fast. Its B200 price changed between quote time and launch. The report shows what customers were actually billed.

How we ran it: each job was booked for 10 minutes using a temporary API key on an internal test account, sent to the production endpoint, with the GPU pinned to an exact card. Other suppliers were switched off around each launch to test one at a time, then switched back on. All temporary keys were revoked afterward.

We'll keep running these and publishing the results, including the failures. Every verification report, with charts and raw numbers, is here:

👉 https://www.kilawattcloud.dev/super-intelligence

If you're building agents that need to provision GPUs on their own, what would you want to see in a report like this?

Kilawatt Cloud Super Intelligence: How We Closed Out a Real Provisioning Challenge

Damian Dixon — Sun, 27 Sep 2026 20:11:42 +0000

An outside AI assurance firm, OpsWatch, sent us a precise question: for an autonomous agent that pays real money and dispatches a GPU provider, what exactly is established before that money, or another provisioning attempt, is put at risk when a provider fails?

We treated it as a real audit brief, not a PR problem, and ran our own adversarial pass on top of it. Everything we found was fixed the same day and independently verified against live production, not asserted from a code review.

What we found

Five real defects in the provisioning and billing chain, including jobs getting billed before a machine was confirmed usable, and failover triggering on a single flaky signal instead of a corroborated pattern.

The most serious: a customer's own launch response leaked their machine's health-report token, letting them fake GPU faults from anywhere and collect automatic SLA credit. No evidence it was ever exploited by a real customer. Fixed with five layered changes, including requiring independent supplier-side corroboration before any credit pays out.

We also shipped a real MCP server with five tools an agent can call directly, tested against production with a real GPU job launched, billed, and auto-refunded live. And a genuine on-chain USDC refund path for x402 customers, first live payout verifiable on Base mainnet.

Where we landed

A fresh full security scan after every fix came back at zero findings across every severity level. All required incident reviews were completed and signed off. One narrow finding remains tracked openly rather than hidden, already contained by existing safeguards.

Every timestamp, transaction hash, and instance ID is in the full report: kilawattcloud.dev/super-intelligence

Kilawatt Cloud is a multi-provider GPU orchestration platform with automatic failover and MCP-native, x402 agent payments.

We settled 12 real GPU purchases with AI agents and real money. Here is what broke and what did not.

Damian Dixon — Fri, 25 Sep 2026 18:16:58 +0000

Most x402 demos I have seen are testnet toys. I wanted to know what actually happens when an autonomous agent pays real USDC for real GPU capacity across more than one supplier, live, on Base mainnet.

So I ran it. Twelve agent initiated GPU jobs, across four independent providers (RunPod, Vast.ai, Lambda, and Hyperstack), settled on chain via x402, pulled straight from production execution logs afterward, not from a demo script.

Result: 12 of 12 jobs settled. Two of them needed an automatic failover mid request. One was Hyperstack refusing a job over an insufficient credit block. The other was RunPod returning a genuine HTTP 500, create pod, there are no instances currently available, when I asked for an RTX 4090. In both cases the router caught the failure and moved to the next provider without anyone touching a keyboard.

A separate diagnostic check outside the live job flow confirmed RunPod had no price at all for A4000, A5000, or A6000 across three repeated checks. That is a real, persistent inventory gap, not a fluke. One open question I have not closed yet: RunPod had a working price for RTX 3090 during that same check, but the live router never attempted it on that job. Flagging that as a real bug hunt, not a mystery I am hiding.

Numbers from the batch: $0.80 billed, $0.50 real provider cost, $0.30 margin captured automatically by the routing logic, zero manual quoting involved.

Happy to go deeper on the routing and failover logic, the x402 signing flow, or the schema behind execution_logs and job_attempts if anyone is building something similar. Ask away.

X @kilawattcloud