x402: AI Agents Can Now Pay to Use the Cloud Simulation API

When we launched on Product Hunt last month, we mentioned x402 as a “what's next” item. The implementation went live on July 17. IT WORKS. Here's how we built it and what the first real-traffic run looked like.

What x402 is

x402 is an open HTTP payment protocol that lets servers request micropayments directly inside the HTTP response cycle. When an unauthenticated request hits a payable endpoint, the server returns HTTP 402 with a payment header that describes the price and the settlement network. The client pays on-chain, attaches a payment receipt to the retry, and the server verifies the receipt before processing the request.

No API key. No billing dashboard. No subscription flow. The agent reads a 402, pays, and retries — all inside the same tool call.

Launch day: July 17 — confirmed working on Base

5 paid calls confirmed on Base mainnet via PayAI. Here's the complete simulation summary from the launch run:

The table above is from the actual run. Here's the data:

The system stayed healthy across the full 10x ramp (25→250 req/s). The transcoding worker (bottleneck at 800 req/s max) and VPS (1,500 req/s max) both had headroom to spare at 250 req/s peak — saturation would kick in closer to 800 req/s inbound.

One honest note from the run: the AI analysis endpoints returned “unavailable” during the test — that's a separate backend issue unrelated to the payment flow. All 5 x402 payments verified and settled on Base mainnet correctly. More on this in the known limitation section below.

The first transaction, confirmed on BaseScan:

tx: 0x9011e4d153aa6dcee1d8bb05d80646118080f9fbb585f648b64e868a31398bd0  • block 48766818 • Jul-17-2026 09:16:23 PM UTC

What's payable — and what it costs

All pricing is denominated in USDC on Base. The pricing table as shown in the product:

Non-payable endpoints — creating simulations, listing scenarios, reading metrics — remain free with an API key. The 16 pre-built scenarios are always available without credentials.

The 4-step payment flow

Here is the raw HTTP exchange. The wrapFetchWithPayment client library handles steps 2 and 3 automatically.

# Step 1 — hit the endpoint without credentials → 402
curl -si -X POST \
  https://www.cloudworldmodel.ai/api/simulations/sim-abc/step-hybrid \
  -H "Content-Type: application/json" -d '{"steps":1}' | head -3

HTTP/1.1 402 Payment Required
X-Payment-Required: eyJtYXhBbW91bnRSZXF1aXJlZCI6IjEwMDAiLCJhc3NldCI6
  eyJhZGRyZXNzIjoiMHg4MzNlZjRiMjE3M2I4MjcyMThhMTE2YzkwMDhiMzlhNWM1ODlhYTUi
  LCJjaGFpbklkIjoiZWlwMTU1OjgwMDQifSwicGF5VG8iOiIweC4uLiIsIm5vbmNlIjoiYWJjIn0=

# X-Payment-Required decoded:
# { "maxAmountRequired": "1000",
#   "asset": { "address": "0x833ef4b2173b82721...", "chainId": "eip155:8453" },
#   "payTo": "0x554d5760fe8512014e43de13ef36ea5ff79c9e23",
#   "nonce": "abc123", "expires": 1753228800 }

# Step 2 — pay $0.001 USDC on Base, get a signed receipt
# (wrapFetchWithPayment handles this automatically)

# Step 3 — retry with X-Payment header containing the signed receipt
curl -s -X POST \
  https://www.cloudworldmodel.ai/api/simulations/sim-abc/step-hybrid \
  -H "Content-Type: application/json" \
  -H "X-Payment: eyJ0eXBlIjoiZXZtIiwidmVyc2lvbiI6IjEiLCJwYXlsb2FkIjp7..." \
  -d '{"steps":1}'

# Step 4 — server verifies on-chain → 200 with results + settlement block
{
  "cpu": 0.72,
  "latency_p95": 124,
  "cost_usd_hr": 0.48,
  "error_rate": 0.002,
  "throughput": 9800,
  "autoscale_events": 1,
  "settlement": {
    "transactionHash": "0x9011e4d153aa6dcee1d8bb05d80646118080f9fbb585f648b64e868a31398bd0",
    "network": "eip155:8453",
    "amountUSDC": "0.001"
  }
}

The settlement block is returned only on x402-authenticated requests and contains the on-chain proof. API-key-authenticated requests omit it.

What an x402 agent call looks like

Here is what it looks like when an AI agent discovers the API on its own, reads the schema, picks a scenario, and plans the paid run — without any human-provisioned credentials:

The agent reads GET /openapi.json, discovers the payable step endpoint and its price ($0.001 USDC), creates a simulation, and plans the run — all autonomously. Using Coinbase's x402 TypeScript client, the wrap-pay-retry loop is handled by the library:

import { wrapFetchWithPayment } from "x402-fetch";

const fetch402 = wrapFetchWithPayment(fetch, walletClient);

// First call: library intercepts 402, pays $0.001 USDC on Base, retries
const res = await fetch402(
  "https://www.cloudworldmodel.ai/api/simulations/sim_abc/step-hybrid",
  { method: "POST", body: JSON.stringify({ steps: 1 }) }
);

const result = await res.json();
// {
//   simulation: { id: "sim_abc", currentTime: 1, ... },
//   metrics: { cpuUsage: 0.72, latencyP95: 124, costPerHour: 0.48, errorRate: 0.002 },
//   events: [],
//   settlement: { status: "confirmed", transactionHash: "0x9011..." }
// }

How we implemented it

The server-side implementation follows the x402 spec draft. When a request to a payable endpoint lacks a valid API key, our middleware returns 402 with an X-Payment-Required header. The header is a base64url-encoded JSON payload that includes:

• The price in USDC atomic units (6 decimal places — 1000 = $0.001)
• The accepted token contract address on Base
• Our settlement wallet address
• A nonce and expiry window to prevent replay attacks
• An EIP-712 domain for typed-data signature verification

When the client retries with an X-Payment header, the middleware verifies the on-chain transfer via the PayAI facilitator before allowing the request through. Verification completes before the route handler runs — from the handler's perspective, the request is either authorized or rejected, the same as API key auth. The settlement block is then injected into the response.

We implemented a session model on top of this: after a valid x402 payment, the server issues a short-lived wallet-scoped session token. Subsequent requests within the session window don't require a new payment. This cuts latency for agents running multi-step simulations where paying per step would be unnecessarily chatty.

Discovery

An agent that's never seen the Cloud World Model API before can discover what's payable from a single endpoint: GET /.well-known/x402.json returns a curated OpenAPI subset covering the 11 payable routes, with price fields embedded in each operation. x402scan-compatible agents pick this up automatically.

The same spec is served at GET /openapi.json — the canonical discovery path that most AI tooling hits first. We serve the curated 11-route agent spec there rather than the full 90-route developer spec, so an agent's context window isn't filled with UI-internal routes it can't use anyway.

The API is also listed on the Try Poncho agent storefront — a machine-readable merchant page that surfaces all 11 payable endpoints, live pricing, and the curated OpenAPI spec in one place. Agents that index Try Poncho will find and price the API without any additional configuration.

RL training agents

The reinforcement learning endpoints deserve special mention. An RL agent running a training loop might call /api/rl/environments/:id/step hundreds of times per episode. The session model handles this — the first step payment establishes a session, and subsequent steps within the session window are covered. The session expires after inactivity, at which point the agent pays again and a new session opens.

Batch step is also available: POST /api/rl/environments/:id/batch-step processes up to 50 steps in a single call and a single payment. For training agents running thousands of episodes, this is the more practical path.

Launch day issue: AI analysis endpoints — resolved

On launch day the explain, optimize, troubleshoot, and analyze-bottlenecks endpoints returned “unavailable” due to a backend LLM connectivity issue unrelated to the x402 payment flow. All 5 x402 payments verified and settled correctly — the LLM calls simply didn't go through. This is now resolved. The AI analysis endpoints are live and working.

The simulation step endpoints (step-hybrid, rl/step, etc.) do not depend on the LLM and were unaffected throughout.

Security notes

Replay protection. Each 402 response includes a nonce. We track verified nonces server-side and reject duplicate submissions within the expiry window. An attacker who intercepts a valid payment receipt can't reuse it.

SSRF guard. The facilitator URL is not caller-controlled — it's set server-side. We don't forward caller-supplied URLs to the verification service, which prevents an attacker from pointing verification at an internal endpoint.

Session hardening. Sessions are wallet-scoped and time-bounded. A session token cannot be transferred between wallet addresses, and the server re-checks the wallet signature on session creation, not just on first payment.

What comes next

The current implementation settles on Base mainnet with USDC. We're evaluating additional networks based on where agent wallets are actually funded in practice. If you're building an agent that would benefit from settlement on a different chain, let us know.

We're also working on: (1) a degraded mode for the AI analysis endpoints that returns rule-based analysis when the LLM is unavailable, and (2) bulk-purchase receipts — a single payment that pre-authorizes N simulation steps, more durable than sessions across long training runs.

The x402 spec is an open draft. If you're implementing payable APIs and have questions about replay protection, session semantics, or facilitator trust model — the implementation took more iterations than expected and the documentation for some patterns is sparse.

cloudworldmodel.ai →Explore the agent API →Agent-curated OpenAPI spec (11 payable routes) →Full API reference for LLM context →