DEV Community: Damian Dixon

The Bottleneck Is Not the Chip. It Is the Layer Between the Rack and the Buyer.

Damian Dixon — Sat, 24 Oct 2026 16:36:27 +0000

GPU capacity is tight, scattered and expensive to reach. The next constraint is not silicon. It is selling, routing and recovering compute by the hour.

The squeeze

Moody's forecasts that six companies, Microsoft, Amazon, Meta, Alphabet, Oracle and CoreWeave, will spend about $785 billion on capital equipment in 2026 and close to $1 trillion in 2027.

Then look at what that spending runs into. The International Energy Agency puts data center electricity use at 415 terawatt-hours in 2024, about 1.5 percent of the world's electricity, and projects about 945 terawatt-hours by 2030. Gartner predicted in November 2024 that 40 percent of existing AI data centers would be operationally constrained by power availability by 2027.

Getting power to a site is slow too. One analysis of grid data found that the median wait to connect a power plant to the grid rose from under 20 months in 2005 to 55 months by 2023. That figure is for power plants, not data centers, but it shows how long connections can take.

Chips are not the sole constraint. Power and time are scarce too.

Borrow, buy, rack, repeat

That is the backdrop for the model that defines this cycle. CoreWeave, the sector's best-known player, reported these results for the second quarter of 2026:

Metric	Q2 2026
Revenue	about $2.58 billion
Net loss	$626 million
Interest expense	about $640 million, up from $267 million a year earlier
Revenue backlog	about $104 billion

Its 2026 capital spending guidance is $35 billion to $39 billion, according to press coverage of the earnings call.

That is what is happening now, not a verdict. The open question for 2026 into 2027 is whether financing and building every megawatt is the most viable, or the most feasible, way to serve a market where capacity already exists elsewhere. Growth tied to debt and construction schedules carries a different risk profile than demand routed to capacity that is already built.

Where the capacity sits

The capacity that does exist is spread across hyperscalers, neoclouds, regional operators and hosting companies. Much of it is committed under long contracts, and operators often have racks sitting idle between them.

To sell a GPU by the hour, an operator needs self-service provisioning, tenant isolation, metering, automatic payment settlement and failover when a machine dies. That is a software company bolted onto a facilities company, and many operators are not set up to build it.

The buyer is changing

Gartner's forecast, as reported, puts spending on AI-optimized infrastructure services at $42 billion in 2026 and $66 billion in 2027, with inference overtaking training in 2026. Inference demand is made of many small, automated purchases, and we expect software agents to make a growing share of them. An agent does not sign a multi-year reservation or fill out a sales form. It needs to find capacity, pay and run.

Payments are forming quickly. In July 2026 the Linux Foundation launched the x402 Foundation with 40 founding organizations, including Google, AWS, Visa, Mastercard, Stripe and Coinbase. x402 uses the HTTP 402 "Payment Required" status code so that software can pay for a web resource without an account or an API key.

Our route: point A to point B

Kilawatt Cloud owns no data centers and buys no GPUs. What it owns is the control plane.

request  ->  quote across six connected suppliers
         ->  pay per job with x402
         ->  launch the machine
         ->  watch it
         ->  if the supplier fails, move the job to another one

Nothing is financed, built or racked in between. Capacity moves from point A, the buyer's request, to point B, a running machine, through whichever supplier is available. Because the platform holds no hardware, it has no reason to favor one source over another, and adding a supplier is an integration rather than a construction project.

The evidence: 10 valid failover drills

We destroyed a running machine and measured what happened next.

Detection. The platform noticed the loss roughly 2 to 4 minutes after the kill. Eight drills run through the Goose extension recorded detection windows between 122 and 243 seconds. Kill times were logged to the minute, so each result is a range.
Failover. Once the loss was detected, the platform claimed the failover within about a second (0.5 to 0.7 seconds) in every Goose drill.
Resume. In one October 14 drill, the replacement resumed from checkpoint 4 in 12 seconds.

Every drill is logged, and the drill log closed on October 21, 2026.

Why this matters in 2027 and after

Any platform can add x402. What is hard to copy is a track record and a posture: published proof, neutrality, because we own no hardware, and safety by default, with the full cost of a job authorized before launch.

In 2027 and after, capacity stays tight, buying shifts to small automated purchases, and reliability data becomes the scarce asset. That is the market Kilawatt Cloud is built for. The category is funded: SF Compute, a marketplace that owns no GPUs, raised a $40 million Series A in December 2025.

Next for us: onboarding paying customers, widening the supplier base and bringing regional operators onto the network.

If you build agents that need compute, or run GPU capacity and want to talk, reach us at hello@kilawattcloud.dev or kilawattcloud.dev.

Sources

Moody's hyperscaler spending forecast, as reported by Data Center Dynamics (2026).
International Energy Agency, Energy and AI (2025), executive summary.
Gartner power-constraint prediction (November 2024), via All About Security; power-plant grid wait via Works in Progress and Let's Data Science.
CoreWeave Q2 2026 results release (investors.coreweave.com); capex guidance per 24/7 Wall St (August 12, 2026) and Crypto Briefing (September 1, 2026).
Gartner AI-optimized infrastructure spending forecast, via Clover Infotech; x402 Foundation launch coverage by BIIA.
SF Compute Series A, Data Center Dynamics (December 2, 2025).
Drill figures: Kilawatt Cloud platform records.

Estimates, opinions and plans are labeled as such. Kilawatt Cloud is a trade name of Right Recruit LLC.

Borrow, Buy, Rack, Repeat. One Founder Wants to Skip All Four.

Damian Dixon — Fri, 23 Oct 2026 04:31:52 +0000

CoreWeave reported $5.13 billion in 2025 revenue, more than 850 MW of active power and a $66.8 billion backlog. It also reported a $1.17 billion net loss and spent about $14.9 billion on capital equipment in one year. Its model: borrow, buy, rack, repeat.

At Kilawatt Cloud we are testing the opposite. We own no data centers and buy no GPUs. We build the control plane: software that provisions machines in minutes, controls who can act on each job, reroutes workloads when hardware fails, meters every hour and settles payment automatically.

Under our proposed terms, an operator keeps the hardware, the building and 80 to 85 percent of the revenue. No operator capacity is under contract yet, and the report says so.

Every number is labeled as reported, our own arithmetic, or an estimate, with sources listed. The per-megawatt figures cite NVIDIA and Supermicro power specs and a July 2026 GPU price survey.

Our control plane can also be operated by AI agents through our MCP server, with per-job x402 payments.

Full case study (3 pages): https://www.kilawattcloud.dev/super-intelligence

Self-published by Kilawatt Cloud. Not independent reporting.

Damian Christopher Dixon
Founder, Kilawatt Cloud

Inside the Kilawatt Report: 10 GPU Failover Drills, 6 Excluded Attempts, Every Number Published

Damian Dixon — Wed, 21 Oct 2026 20:45:59 +0000

Disclosure: I'm the founder of Kilawatt Cloud. I ran and timed every drill below on an internal test account, so this is our own test record and not independent reporting.

The question

Chip makers all sell the same promise: more compute, faster. For anyone buying GPUs through software, the next question matters more: what happens when a rented machine disappears halfway through a job?

For an agent that bought the job on its own, a failed job is a lost purchase and a reason not to buy again. I wanted measurements, so I destroyed ten live GPU machines mid-job and timed what the platform did next.

How the drills worked

Eight drills ran through the goose agent app on October 20. Each job was bought over x402 (USDC on Base) through our MCP server, and an operator destroyed the Vast.ai machine by hand after a health check passed. Two earlier drills ran on October 14, with a checkpointing job on a RunPod A100.

I measured two things:

Detection: the time from my kill to the platform marking the machine failed.
Failover claimed: the time from detection to the platform claiming a replacement on a different supplier.

The results

Drill (Oct 20)	Detected (UTC)	Detection after kill	Failover claimed after detection
1	04:34:02	184 to 243 s	0.6 s
2	04:38:03	124 to 183 s	0.5 s
3	05:10:03	184 to 243 s	0.7 s
4	05:28:02	184 to 243 s	0.7 s
5	05:30:03	184 to 243 s	0.7 s
6	05:36:01	122 to 181 s	0.6 s
7	05:46:01	182 to 241 s	0.5 s
8	05:54:01	183 to 242 s	0.6 s

On October 14, detection took 238 seconds in the first drill (RunPod to Hyperstack) and 121 seconds in the second (RunPod to Vast.ai). In the second, the job resumed automatically from its saved checkpoint 4, 12 seconds after the replacement was ready. It then went on to write checkpoints 5, 6 and 7.

Across all ten drills, the platform placed a replacement on a different supplier every time.

Why the ranges are wide

I recorded the minute I clicked Destroy, not the second, so each detection figure is a window of about a minute. Health checks also run every 2 minutes, which puts detection near 3 to 4 minutes after a kill.

What these drills do not show

Replacement-ready time. The database wasn't recording it. Replacements passed later health checks, but I have no timing, so I'm not claiming a recovery time for the October 20 drills.
Resume on the October 20 jobs. Jobs bought through x402 don't save checkpoints, so those eight measure detection and replacement only. Resume was shown only on October 14.
A median or worst case. Ten drills are too few, so I'm giving exact counts and ranges.
A supplier-removal drill. Not run yet.
Fully autonomous buying. A person typed each buy prompt and destroyed each machine. This shows the pay-per-job path and failover working together.

The 6 jobs I excluded

I paid for 14 jobs on October 20 and counted 8:

Four never booted on one Vast.ai host. They were auto-refunded, and I blocked that host in code.
One 600-second window was too short.
One was a replacement stopped at the end of its window, which isn't a drill.

What the drills broke

The endpoint said "rate limiting requests" for several different refusals. It should name the real limit and when it clears.
A job's concurrency slot stayed held until its 15-minute window ended, even after the instance was destroyed.
The never-ready refund didn't fire on time for two jobs.
Some hosts stall pulling the Docker image. Pre-caching it is on the list.

What's next

Detection is slower than I want at about 2 to 4 minutes, and shortening it is first on the roadmap. After that:

Record when each replacement is ready.
Run a larger set with median and slowest times.
Run a supplier-removal drill and publish it.

The full case study, with the method and the excluded attempts, is here: https://www.kilawattcloud.dev/super-intelligence

About the author: Damian Dixon is the founder of Kilawatt Cloud, based in Los Angeles.

"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