Your agent didn't go rogue. It paid for the same call 340 times.

The shape of the failure

An x402-gated endpoint takes payment first and serves the resource second. That ordering is the whole point — it's what makes machine-to-machine payment work without an account, an API key, or a human in the loop. It also means there is a window, maybe a few hundred milliseconds wide, where your money is gone and your agent has nothing to show for it.

Now put a timeout on the client. Put a retry decorator on top of that, because of course there's a retry decorator, everyone has a retry decorator. The agent pays, the response is slow, the client gives up at 5s, the decorator fires again, the agent pays again. If the endpoint is genuinely degraded rather than just slow, that loop doesn't converge — it runs until something external stops it. A rate limit. A wallet balance hitting zero. You, waking up.

The individual amounts are what makes this so hard to notice. Four cents. Eleven cents. Nobody sets up an alert for eleven cents. Three hundred and forty of them in twenty minutes is a different object entirely, but it's made of parts that each look completely normal.

Why the bill is always the first alarm

Here's the thing that got me building this in the first place. In the normal API world, you find out from a dashboard or an invoice, and the invoice is at least monthly, which is late but bounded. With an agent wallet there is no invoice. There's a balance. The feedback mechanism for "you are spending too fast" is "you have no money," and it arrives after the fact, at full severity, with no warning shot.

And the transactions are individually valid. Nothing was hacked, nothing was exploited, no key leaked. Your agent authorized every single one of those payments correctly. There is no fraud signal to trip because there is no fraud. That's precisely why the standard tooling in your stack stays silent: it's all looking for something wrong, and nothing here is wrong. It's just too much of something right.

So the only place this shows up early is in the aggregate — the rate, the count, the trailing total — and nothing in a default agent setup is computing those.

What we actually watch for

We read USDC Transfer events out of the wallets you register, on Base and Solana, and we never touch a key or ask you to connect anything. From that stream, a retry loop has a very specific fingerprint: a burst of near-identical amounts to the same recipient inside a tight window. Not a big payment. A cluster of small identical ones. Once you've seen the pattern once you can spot it in a transfer list at a glance.

Worth being honest about what that means: a cluster like that often doesn't breach a spend ceiling at all, at least not on the first pass. Three hundred and forty payments at four cents is $13.60. It's under any sane budget. The ceiling catches it eventually, on hour six, which is exactly the kind of "eventually" this post is complaining about. Rate is the earlier signal. It's the one we think matters most, and it's next on our roadmap — what's live today is the ceiling-over-window check.

What we can't do, and I'd rather say it here than have you find out later: we don't sit in the request path, so we can't stop the loop. We see the transfers after they settle. If you need something that refuses to let the payment happen, you need a policy engine in front of your agent's spending, and that is a different product with a much deeper integration than pasting a public address into a form.

What this means for your fleet

Go look at your agent's retry logic before you look at anything else. Specifically: is there any point where a payment is sent and the response handling can fail in a way that triggers a re-send? If you can't answer that in under a minute, that's your answer. Idempotency on the paid call — some request identifier the provider honors — is worth more than any monitoring tool including ours, because it prevents the failure instead of describing it.

Then set a ceiling low enough to be insulting. People set budgets at their expected monthly spend, which means the alert fires when a month's worth of damage is already done. Set it at something you'd actually want to be interrupted about. You can always raise it.

And keep one wallet per agent. Every diagnosis in this post gets dramatically harder when four agents share an address, because then the spike you're staring at belongs to nobody in particular and you're back to guessing.

We've written before about the other quiet ways an agent overspends beyond retry storms — see "Three ways an autonomous agent quietly overspends" on this blog if a retry loop isn't your failure mode.