DEV Community: Damian Dixon

We Tested Our Own x402 Agent Payments With Real Money — Found a Bug, Fixed It, Here's the Proof

Damian Dixon — Mon, 21 Sep 2026 20:43:49 +0000

An AI agent doesn't fill out a checkout form. It hits an endpoint, gets a 402 Payment Required challenge, signs an authorization, and expects a real resource back within seconds. We tested that exact path against our own public endpoint — not a sandbox, real USDC on Base mainnet — and found a real production bug in the process.

What we ran: a batch of GPU jobs through our public x402 endpoint, the same one an external agent would hit. Different GPU classes, different providers (Vast.ai and RunPod), each paid for and torn down automatically.

Results — 7 settled payments, every one with an on-chain hash:

GPU Provider Real cost Charged Time Tx hash
RTX A4000 Vast.ai $0.001215 $0.01 80.1s 0x1aacdc35...05072b
RTX 4090 Vast.ai ~$0.0023 $0.01 ~100s 0xd190f93e...baa5f4
RTX A4000 Vast.ai $0.001215 $0.01 106.1s 0x76318a7e...4630de
RTX 3090 Vast.ai $0.001852 $0.01 109.4s 0x2875dcf1...7b9b8b
A40 RunPod $0.005667 $0.01 63.1s 0x8aea8983...965902
H100 Vast.ai $0.028959 $0.05 109.9s 0x1e595040...65f05ca
A10 (batch inf.) RunPod $0.005667 $0.01 110.7s 0xcfbb0dda...d9514

What broke: 2 of 8 jobs failed on a 120-second payment authorization window. Root cause wasn't price lookup or payment logic — it was our OFAC sanctions-list cache going stale, triggering a live 5MB Treasury re-download on every payment with no timeout. When that download hung, it added up to two minutes inside the payment path.

What we fixed: removed the live download from the payment path entirely, moved refresh to an hourly background job, widened the authorization window from 120s to 600s as a second layer. Re-ran the exact failing config: settled in 18.8 seconds. 0xa7c7ae02e2c4382b748c6736616f5570d7fd72520cb962b4b41434f0fd6f859a.

Independent verification: pulled Vast.ai's own billing ledger directly — every job shows up by contract ID, charge amount, and our own dispatcher's job label embedded in their record. That check also surfaced a second bug: RunPod silently substituted RTX 4090s for two jobs requested as an A40 and an A10, with no disclosure. Currently fixing that one too.

A payment rail is only as good as what happens when it breaks. This is what happened when ours did.

The Multi-Cloud Paradigm Shift: Why No Single GPU Provider Can Carry Serious AI Workloads Anymore

Damian Dixon — Sun, 20 Sep 2026 21:09:18 +0000

16 of 18 real GPU jobs required automatic failover mid-run. Zero were dropped.

That's not a number from a pitch deck. It's what we found when we audited our own infrastructure before saying a word about it publicly. Here's the full breakdown, and why it matters.

The paradigm shift, in one sentence

No single GPU provider, not RunPod, not Vast.ai, not Lambda, has enough of the right hardware, in the right place, at the right time, to carry serious AI workloads alone anymore. Most neoclouds, including CoreWeave, Lambda, and Nebius, are single-provider by design. When their capacity runs out or a job fails, there's no second provider to catch it. Multi-cloud stopped being a hedge and became the default for any team doing real AI work.

Kilawatt Cloud sits above the providers, RunPod, Vast.ai, Lambda, and Hyperstack, through a single API, and routes workloads to wherever real capacity exists, with automatic failover built in. Not zero failure, no infrastructure layer can promise that. No single point of failure.

The audits: what we actually checked

A multi-cloud broker is only as trustworthy as its weakest unverified claim. So we ran everything for real before publishing a word of it.

Live failover audit. Across a run of real completed jobs paid for through our x402 stablecoin rail on Base mainnet, 16 of 18 jobs (about 89%) required an automatic failover to a second provider mid-run. Zero jobs were dropped. On one day in that window, RunPod failed 100% of its attempts, all 11, and Lambda picked up the failover traffic for the first time in our logs. A separate database check confirmed two more real historical failover events on earlier dates, independent of that test run.

Provisioning speed audit. RunPod: 4.7 seconds to ready. Vast.ai: roughly 92 to 109 seconds depending on API vs. SSH-verified readiness. Lambda: about 260 seconds. Real gaps a routing layer has to account for, not smooth over.

Billing and provisioning safety audit. Before trusting our own metering, we went looking for ways it could fail and found seven real gaps: launches that weren't fully pre-authorized against balance, no per-key rate or concurrency limits, no customer-set spend caps, no automatic reaping of abandoned instances, a broken Vast.ai provisioning endpoint, a failover path that silently dropped instead of falling through, and gateway-launched instances that weren't tracked for termination. All seven were fixed and re-verified against real instance creation and destruction on RunPod and Vast.ai, not just reviewed in code.

Where the audits found real gaps, we published the before-and-after instead of quietly patching them. That's the standard: a number we haven't tested against live infrastructure doesn't go in front of a customer.

The ROI on our roadmap for enterprise

Everything above is live today. What we're building toward is where the ROI case for enterprise compounds. We're actively sourcing dedicated GPU capacity to broker larger B300 and B200 clusters for enterprise teams whose needs sit above what any single spot marketplace can reliably fill. Every brokered deal is structured with an upfront prepayment covering supplier cost plus our margin before we ever pay a provider, so an enterprise customer gets a fixed, predictable number instead of a variable bill that moves with provider pricing swings.

The math is straightforward once you sit with it. A stalled training run on a single-provider cloud costs real money sitting idle while a team scrambles for capacity elsewhere. A vendor relationship built one supplier at a time costs real engineering hours. Kilawatt collapses both into one relationship, one API, and one bill, backed by a routing layer that's already proven it catches failures before they become the customer's problem.

Where this is headed

As GPU demand keeps outpacing any single provider's supply, this shift only accelerates. The operators who win won't be the ones with the most hardware, they'll be the ones buyers can actually verify. We're building toward a real, multi-million-dollar infrastructure company, and the work above is exactly what that's built out of.

The Same H100s Powering Ground AI Are Now Training Models in Orbit.

Damian Dixon — Sat, 19 Sep 2026 18:17:47 +0000

In December 2025, Starcloud (NVIDIA-backed) trained the first LLM ever trained in space, on an H100, roughly 500km above Earth. Same GPU class we orchestrate across RunPod, Vast.ai, Lambda, and Hyperstack every day for ground-based AI teams.

The infrastructure story here is genuinely interesting: orbital compute is still experimental (thermal management, radiation, power constraints are hard problems), but the model development behind space-bound AI, satellite imagery analysis, autonomous navigation, mission planning, still happens on Earth, on the same class of hardware we already route jobs to.

We're not building orbital infrastructure. We're the ground layer serving teams building toward it, using the exact multi-provider GPU orchestration we've been live-testing and publishing results on all week.

Curious if anyone here is building for space/aerospace AI applications and what your actual GPU requirements look like, happy to compare notes.

We Fired 3 GPU Deployments at Once — One Failed. Here's What Happened Across Japan, Romania & Canada.

Damian Dixon — Sat, 19 Sep 2026 17:40:12 +0000

Ran real provisioning tests against our own infra. Verified results:

• RunPod: hard caps every pod at 8 GPUs (confirmed via direct API — 9 and 16-GPU requests rejected)
• Vast.ai: real on-demand capacity up to 16 GPUs (workstation-class: A4000/A5000/A6000/3090/4090/A40) and up to 4 GPUs (B200), confirmed with live rentals
• Ran 3 simultaneous 9-12 GPU deployments across Japan, Romania, and Canada — all held concurrently; one request failed cleanly when it collided with another over the only 12-GPU machine on the marketplace (no charge)

We're kilawattcloud.dev — multi-provider GPU orchestration.

Happy to answer questions on methodology in the comments.

Curious what other GPU brokers' actual concurrency limits look like under real load — most don't publish this.

Case Study: Architecting Neocloud Compute for the MCP & Agentic Workload Era

Damian Dixon — Wed, 16 Sep 2026 18:46:26 +0000

Salesforce and Anthropic used Dreamforce 2026 to push MCP toward becoming the enterprise standard interface for agents. That shift creates a real infrastructure problem most platforms aren't built for.

Frontier models handle reasoning. But running continuous agentic work, the actual multi-step loops where an agent calls tools, checks results, and calls more tools, needs infrastructure that standard serverless and monolithic VMs were never designed for. Those were built for stateless web requests, not bursty, stateful, multi-agent loops executing tool calls in real time.

Here's how we built Kilawatt Cloud to be that hosting layer.

Three things an agent infrastructure layer actually needs

Stateful context holding: persistent bidirectional connections (Stdio or SSE) so a multi-step loop doesn't drop mid-task.

Low-latency burst compute: tight feedback cycles for code execution and database queries, without latency compounding across a pipeline.

Programmatic machine settlement: machine-to-machine micro-billing (HTTP 402 / X402) so an agent can pay for compute on its own, no human in the loop.

How the MCP pipeline works

An Express service boots paired with the MCP SDK. It registers tools like execute_sandboxed_compute across hardware tiers (CPU-high-freq, GPU-V100, GPU-A100). Incoming tool calls dispatch to that hardware and return structured JSON. SSE endpoints (/sse and /messages) keep the channel alive so long-running agent loops don't time out.

Payment is the auth

An agent calls the API. We respond with an HTTP 402 challenge, priced live off the real-time cost of whichever provider will actually serve the job, not a static rate card. The agent signs and sends a payment token. We verify it instantly, execute, and return results in milliseconds.

Real numbers, not theoretical ones

Fastest logged provisioning time across three GPU providers: 4.7 seconds.

Across 18 real, autonomous agent purchases, 16 (89%) needed an automatic failover when the first-choice provider couldn't deliver. Every one was caught and completed on a backup. Zero dropped requests.

Pricing is live, not fixed. Every job charges real cost plus margin at the moment of the request, so identical job specs can land at different prices depending on real market conditions.

What this means if you're building in this space

If you're building agent tooling, standardize on MCP instead of custom connectors. If you're building infrastructure, the leverage is in the stateful hosting layer and machine payments, not the model itself. If you're a technical leader, plan for high-concurrency, short-duration compute spikes, since that's what agent traffic actually looks like.

kilawattcloud.dev
github.com/kilawatt-mcp-server

We Tried to Break Our Own Payment Pipeline. Here's What We Found.

Damian Dixon — Wed, 16 Sep 2026 15:33:59 +0000

We spent two days running deliberate, adversarial testing against our live production payment and provisioning system — real agent purchases, real concurrent load, real market conditions. Not a staged demo. The goal was simple: find out where it actually breaks.

It broke in three places. Here's the full account.

The audit trail had a real gap

Our system only recorded which provider a job landed on — not what a failed provider actually returned, or when. If a job failed over twice before succeeding, that middle part of the story was gone.

We built a new append-only audit table: every provider attempt now gets logged with its verbatim response, precise timestamps, and outcome. It's enforced at the database level — we tried to directly UPDATE and DELETE a real row ourselves, and the database rejected both, no exceptions even for us.

A rejected request could still get charged

Found during live testing: a request that hit our concurrency limit and got rejected still resulted in a real, settled on-chain payment. Root cause — payment was settling before the system confirmed the job was even allowed to run.

We fixed the ordering. Then we stress-tested the fix with genuinely simultaneous requests and found a second, narrower version of the same bug — a race condition where multiple parallel requests could all pass the check before any of them locked in a slot. Fixed that too, this time making the check and the reservation a single atomic operation.

Verified by firing six real simultaneous requests: five jobs, five payments, a clean 1:1 match, zero orphaned charges.

Unprofitable requests were still getting charged

A separate issue: when every available provider was briefly unprofitable at current market rates, the job correctly failed to place — but payment still went through anyway. Fixed with a live profitability check that runs before settlement, not after.

The deeper fix: real dynamic pricing

Both billing bugs shared a root cause — a fixed rate card that couldn't track live market movement in either direction. We replaced it with real-time pricing: every job now prices off the actual live cost of the provider that will serve it, with the exact quoted price matching exactly what gets recorded on the ledger. No more flat numbers.

The standard we're holding ourselves to

Every fix above was independently re-verified against real production data after shipping — not assumed to work because the code looked right. That's what "real over convincing" means to us in practice.

kilawattcloud.dev

We let an AI agent buy its own GPU compute 18 times. It never once walked away empty-handed.

Damian Dixon — Tue, 15 Sep 2026 23:26:27 +0000

We let an AI agent buy its own GPU compute 18 times. It never once walked away empty-handed.

Real x402 agent, real USDC on Base, no human involved. Over 4 days:

• 18 real purchases, 18 completed jobs
• 16 of 18 (89%) hit a failed first attempt — RunPod couldn't fulfill — and were automatically rerouted to a backup provider
• Zero dropped requests
• $0.88 in real settled payments

The agent never knew anything went wrong. It asked for compute, paid, and got it — every time.

For more pioneering news for us on X @kilawattcloud

RunPod boots a GPU in under 9 seconds. Here's what 27 real runs across three providers actually showed.

Damian Dixon — Tue, 15 Sep 2026 00:20:04 +0000

We logged every GPU provisioning run against Kilawatt Cloud's gateway over two days (Sep 6–7) — real submissions to real providers, measured from request to confirmed-ready state, then automatic teardown. No staged runs, no cherry-picking. Here's what actually happened.

The numbers

Provider Runs Median Fastest Slowest
RunPod 8 7.65s 5.8s 8.8s
Vast.ai 15 64.5s 20.7s 197.0s
Lambda 1 153.9s — —

RunPod: tight and predictable

Every single RunPod run landed inside a 3-second window — 5.8s to 8.8s, all on RTX 4090s. That consistency is the interesting part, not just the speed. A provider that's fast and predictable is easier to build reliability guarantees on top of than one that's fast on average but spiky.

Vast.ai: the spread tells its own story

Vast.ai's 15 runs ranged from budget cards (GTX 1050 Ti, GTX 1060, GTX 1660S) up to H200 and B200 — so the wide spread (20.7s–197s) isn't noise, it's mostly explained by card tier and host state:

• Warm hosts, high-end cards: H200 runs landed at 20.7s and 21.0s
• Cold-start penalty: one B200 run hit 197.0s because the host had to pull the container image first — the same card warm-started at 26.0s and 41.3s
• Budget cards, cold hosts: the GTX 1660S runs clustered around 121–128s

Cold start vs. warm host is roughly a 5-9x difference on the same hardware. Worth knowing if you're timing anything against a Vast.ai node cold.

Lambda: too early to call

One logged run at 153.9s. That's a single data point, not a trend — we're not going to dress it up as one. More runs needed before this is representative of anything.

Why this matters for automatic failover

Kilawatt's gateway routes across all four providers with automatic failover — if one is slow or unavailable, the job lands on the next. Numbers like these are what makes that routing decision meaningful instead of arbitrary: knowing RunPod is consistently fast lets the router lean on it for latency-sensitive jobs, while Vast.ai's breadth of card tiers makes it the better fit when price matters more than speed.

Full run log with every timestamp is available on request. Real over convincing.

kilawattcloud.dev

We post the raw runs as they happen, not just the summaries — follow @kilawattcloud on X if you want the numbers before they make it into a report like this one.

Four Real x402 Settlements: What Actually Happens When an Agent Pays for a GPU

Damian Dixon — Mon, 14 Sep 2026 03:13:44 +0000

We ran 4 real x402 settlements tonight against our production endpoint. Sharing the raw data, successes and one rejection included, because this community tends to want the receipts, not the summary.

What we ran

Each transaction is a genuine on-chain USDC payment on Base, confirmed by a real transaction hash and a matching Stripe PaymentIntent. Endpoint: kilawattcloud.dev/api/public/x402/exec.

Run	GPU	Billed	Notes
1	nvidia-a10	$0.0400	Baseline settlement
2	nvidia-a10	$0.0400	Repeat run, confirms repeatability
3	nvidia-a10	$0.0400	Third consecutive success
4	h100	$0.0408	Failed over from 2 nodes before landing on a 3rd

The interesting one

Run 4: the agent requested an h100. First candidate node (US-East-04) didn't complete the assignment. Second (US-East-09), same. System automatically routed to a third node (US-West-07), which succeeded.

Response body (trimmed):


json
{
  "id": "50966748",
  "gpu_type": "h100",
  "failover_from": ["Node US-East-04", "Node US-East-09"],
  "billed_usd": 0.040793,
  "payment": {
    "transaction_hash": "0x393506ceac2a59adc1369b45c7c315215a44a4b45847110dc885ba9cc0513692",
    "network": "base",
    "stripe_payment_intent": "pi_3UFPpFRWTRbdvB4M0AaC1UoE"
  }
}

61% of Americans don't want a data center near them. Here's why that doesn't touch us.

Damian Dixon — Sat, 12 Sep 2026 21:32:41 +0000

A University of Pennsylvania poll found 61% of Americans now oppose new data center construction in their communities, up 12 points in a single year. It's reportedly become significant enough to be called a "sleeper issue" heading into the 2026 midterms.

At the same time, U.S. data center construction spending hit $75B in July alone, up 57% year over year. The industry is racing to build directly into a wall of growing public resistance.

Texas told its grid operator to stop approving new data center connections pending an audit. New York passed the first statewide moratorium on large new data centers. These aren't fringe events, they're becoming a pattern.

Why this doesn't touch Kilawatt Cloud

We don't build data centers. Kilawatt routes GPU workloads across RunPod, Vast.ai, Lambda, and Hyperstack, with automatic failover if one provider runs dry. Every GPU we route to already exists, already has power, already cleared whatever zoning and community approval it needed to get built.

That's not a workaround, it's a structural difference. While hyperscalers navigate grid interconnection queues, zoning boards, and now voter backlash, an aggregation layer over already-built capacity doesn't hit that same wall. We're not competing for the same scarce resource everyone's fighting over, we're routing around whoever already won that fight.

The honest caveat

This doesn't mean unlimited GPU supply forever. If community and political resistance genuinely slows new capacity coming online industry-wide, the existing capacity we route across becomes more valuable and more contested too. We're insulated from the fight, not immune to its downstream effects.

But there's a real difference between "our growth is capped by permitting delays" and "our growth is capped by how much of the internet's existing GPU capacity we can route to intelligently." The second problem is a much better one to have.

Curious if other infra-layer builders are thinking about this the same way, or if I'm missing a real exposure here.

An AI agent just paid me $0.04 and I watched it happen live

Damian Dixon — Sat, 12 Sep 2026 17:19:04 +0000

Four hours in, I was ready to give up.

Funded wallet. Correct payment challenge. Every field verified twice. And still:

"invalid_payload: contract call failed: unable to call contract: execution reverted"

No reason. No hint. Just reverted, like the blockchain equivalent of a shrug. I'd built something that should work, on paper, and it didn't, and I had no way to see why.

This morning, that same code let an AI agent pay me $0.04 in USDC and get a GPU running in under a second. No signup. No API key. No human anywhere near it. Here's the part nobody writes about: everything that broke first.

What I was actually trying to build

Kilawatt Cloud routes GPU compute across RunPod, Vast.ai, Lambda, and Hyperstack, failing over automatically when one provider runs dry. It already had a normal API. What it didn't have was a way for something with no hands, no email address, and no credit card to pay for compute on its own.

That's what x402 exists for. And it turns out the hard part isn't the protocol. It's everything underneath it that the protocol assumes you've already solved.

The status code that sat unused for 30 years

HTTP has had 402 Payment Required since 1997. Nobody used it. Not once, not really, for almost three decades. x402 finally gives it a job: request comes in, server answers 402 with an exact price, client signs a crypto payment, resends, server settles, work happens.

\POST /api/public/x402/exec → 402 Payment Required { "scheme": "exact", "network": "base", "maxAmountRequired": "40000", "payTo": "0x...", "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913" } → agent signs payment, resends → 200 OK, job running \\

40000\ is USDC's smallest unit, six decimals deep, so that's four cents. Base mainnet. Real money, real chain, from the first test.

The SDK was already a ghost

I built the first version on @coinbase/coinbase-sdk\. Coinbase had quietly deprecated it in February. Every call came back with a 404 that told me exactly nothing: no matching operation was found\. I spent an hour debugging code that was never going to work again, no matter how correct it was.

The real fix wasn't a fix. It was throwing the whole thing out for @coinbase/cdp-sdk\ v2, which doesn't just want an API key. It wants a second, separate credential called a Wallet Secret, and nothing in any error message tells you that's missing until you already know to look for it.

I tried to steal a key that was never mine to take

My instinct, once the new SDK was in, was to rip out a raw private key and feed it to viem\. CDP-managed accounts don't have one to give. No exportPrivateKey()\. Not a missing feature. A locked door, on purpose.

I fought that door for longer than I want to admit before I noticed I didn't need to open it. The CDP account already speaks the exact language viem\ wants to hear:

\`javascript
import { CdpClient } from "@coinbase/cdp-sdk";
import { createWalletClient, http } from "viem";
import { base } from "viem/chains";
import { wrapFetchWithPayment } from "x402-fetch";

const cdp = new CdpClient({ apiKeyId, apiKeySecret });
const account = await cdp.evm.getAccount({ address });

const walletClient = createWalletClient({
account,
chain: base,
transport: http(),
});

const fetchWithPayment = wrapFetchWithPayment(fetch, walletClient);
`\

Hand the account over as-is. Stop trying to take something that was never meant to leave the vault.

The bug that was mine, hiding behind one that wasn't

Which brings me back to that revert. Wallet funded. Challenge correct. Still dead.

Turned out my own server was catching Coinbase's actual rejection reason and throwing it away, replacing it with a generic "verify failed" that told me nothing, same as the SDK's dead 404 had. I was debugging a system that had learned to lie to me by omission.

I logged the facilitator's real invalidReason\ field and the truth fell out immediately: not enough USDC, because an earlier transfer had gone to the wrong wallet entirely. One transposed character in a pasted address. The oldest bug there is, dressed up in a blockchain costume so it could sneak past me twice.

The bug I wasn't even looking for

While I was making sure payment always happened before a single GPU spun up, I found something worse sitting quietly on the other payment path, the normal prepay one that had been live the whole time. Balance check and balance deduction were two separate steps. Two requests landing close enough together could both pass the check before either one actually paid.

That's not a bug that fails loud. That's a bug that quietly loses you money for months before anyone notices. I collapsed it into one atomic step. x402 was never exposed to this, it's one-shot by nature. Everything else I'd built wasn't, and I didn't know that until I went looking for something else entirely.

What actually happened this morning

\json { "status": "running", "billed_usd": 0.041625, "payment": { "transaction_hash": "0xbf51d133509977ae561aa9957c1eaedffba3cc318dfe8cc5b1c43edc1cff3001", "network": "base", "amount_usd": 0.04 } } \\

Real hash. Check it yourself on BaseScan. Real payout landed on the Stripe side an hour later. Nothing about it was staged, because there was no version of this I could fake convincingly enough to bother trying.

If you're about to build this

@coinbase/cdp-sdk\, not the old one. Half of what's indexed online right now will walk you straight into a wall.
Don't fight the account object for a key it was built not to give you. Hand it to your wallet client whole.
Log the facilitator's real rejection reason before you trust your own error message. Mine lied to me for an hour.
If you have any other payment path running alongside x402, go check it for this exact race. x402 can't have it. Nothing stops your other code from having it quietly, for a long time.

Full docs: kilawattcloud.dev/docs/x402

If you're building x402 on the server side and not just the client, tell me where it broke for you. Everything I found while debugging this was written by someone standing on the other side of the request.
**

We're building the toll booth for machine-to-machine compute

Damian Dixon — Tue, 08 Sep 2026 20:02:04 +0000

Every GPU cloud today assumes a human is the one deciding to spend money. Log in, pick an instance, click confirm. That assumption breaks the moment agents start provisioning compute on their own, mid task, with no person in the loop.

When that happens, something still has to be the toll booth. Verify there's balance, pick the right provider in real time, route around failures, settle the payment. All of it invisible, machine to machine.

That's not just a thesis for us. It's what we've already built. Kilawatt routes jobs across four GPU providers (RunPod, Vast.ai, Lambda, and Hyperstack) through a single API, with real automatic failover. If one provider goes down, the job lands on another with no human stepping in. We've tested this live, not in theory. Real instances provisioned and torn down on RunPod and Vast.ai, timed down to the second. RunPod's consistently 7 to 9 seconds. Vast.ai runs 20 to 60 seconds typical. Every customer prepays into a wallet, and every job checks balance and pre authorizes cost before it runs. That's the same verification a machine to machine toll booth would need, and it's already working today for human requests.

The MCP native part is what points this at the agent future specifically. Our control layer, kilawatt mcp server, is published and live on npm and the official MCP registry. An AI agent can already provision compute directly through MCP, not just a developer clicking through a dashboard.

We're not saying machine to machine billing is the dominant model yet. It isn't. But the toll booth mechanics, balance checks, provider routing, automatic failover, real time settlement, aren't hypothetical for us. They're running in production today, just triggered by human requests instead of autonomous ones. If that shifts, we don't need to rebuild anything. It just means a different kind of request shows up at the same booth.