The test

What happens when an agent sends 100 paid requests at once?

We tested POST https://x402.agentutility.ai/token-count, priced at $0.005 per call. Each request carried unique text ranging from 64 to 4,096 characters and selected gpt-4o as the target model. 

{
  "text": "Request 047: Estimate the token count for this unique test payload...",
  "model": "gpt-4o"
}

All 100 jobs entered the client queue together. Dispatch took 38 milliseconds. The x402 client handled each 402 Payment Required response, signed its USDC authorization, then repeated the request with payment attached.

Total authorized spend: $0.50 on Base mainnet.

We recorded the HTTP status and full request duration for every call. Phase timing separated the payment exchange from the endpoint response.

The latency distribution

The full burst finished in 5.12 seconds. All 100 paid calls returned HTTP 200. 

Calls started:          100
Successful results:     100
Failed results:           0
Total wall time:       5.12s
Throughput:            19.5 successful calls/s

End-to-end latency:
p50                    1.84s
p95                    3.92s
p99                    4.61s
max                    4.88s

Paid-request work:
p50                      74ms
p95                     121ms
max                     168ms

The median call took almost two seconds, while the answer itself arrived in 74 milliseconds after payment cleared. That gap matters.

Settlement was the slowest phase. It wasn’t a failure point.

The distribution rose gradually rather than splitting into a fast group and a stalled tail. That’s what you want from a burst. A sharp second wave would suggest queue saturation or a connection cap. We saw neither in the final run.

And every successful response carried a payment receipt. The client matched each receipt to its request before accepting the result.

What broke first

Our load generator did.

The first attempt used the client’s default connection pool, which allowed ten active connections to the host. The resulting chart looked awful: ten requests finished, then the next ten, followed by another batch. Its p95 exceeded 14 seconds.

That wasn’t endpoint pressure. It was local serialization.

We raised the per-origin connection limit to 100 and repeated the run. The staircase disappeared. If you’re testing x402 throughput, inspect your socket pool before blaming Base or the seller.

Another trap sits in timeout handling. A client can lose the response after payment has cleared. Creating a fresh authorization immediately may buy the same result twice. Record the request ID and payment receipt, then check the prior attempt before issuing another payment.

For a read-only endpoint such as token-count, a duplicate result is harmless. A duplicate charge still isn’t.

What agents should do with this

A router shouldn’t treat $0.005 as permission to fan out without limits. One hundred calls still cost $0.50, and a retry bug can turn that into $1.00.

Use bounded concurrency for normal workloads. Twenty active calls will often give an agent most of the available throughput while leaving room for unrelated work. Reserve a 100-call burst for batch jobs that actually need it.

Track end-to-end latency separately from post-payment response time. If the second number stays flat while the first grows, changing the endpoint won’t fix your queue. Look at the payment path and client connection limits.

Agentutility currently lists 799 endpoints across 17 clusters, priced from $0.001 to $0.50 per call. Cheap endpoints make this kind of paid load test affordable. They don’t make measurement optional.