The retry problem: when should a 402 fire?

Where the question comes from

The sharpest objection raised against paid agent tooling in recent community discussion was not about price levels. On a thread announcing a set of x402-payable MCP tools, one commenter asked how the provider decides what counts as a non-chargeable call, noting that agents retry a lot, and that if invalid is not deterministic you end up in disputes over whether a 402 should have fired.

That is the whole problem in two sentences. It is an operational question, it has no answer in the protocol, and every provider charging per call has to answer it themselves.

Why agents retry more than people

A human who gets a bad result usually stops, looks at it, and changes something. An agent loop treats a bad result as a signal to try again, often immediately and often with a slightly different argument. Frameworks encourage this: retries with backoff are the default in most HTTP client wrappers an agent will be built on.

The consequence is that a route with an ambiguous failure mode does not get called once and complained about. It gets called five times in four seconds, and if each attempt is chargeable, the buyer sees a bill they did not expect for a result they did not get.

The outcomes that need a rule

Most disputes come from a small set of outcomes that sit between clear success and clear failure. Deciding these in advance is cheap; deciding them after a buyer complains is not.

The useful test for each row is whether the buyer could have known the answer before making the call. If not, the outcome should default to non-chargeable, because the buyer had no way to avoid the cost.

Empty results are the genuinely hard case

A search that runs correctly and returns nothing consumed real resources. A provider charging for it is not being unreasonable. A buyer who paid for a lookup and received an empty array will still feel they paid for nothing, and both positions are defensible.

The resolution is not to find the objectively correct answer but to publish whichever answer you chose, before the buyer calls. An agent can budget for a rule it knows about. It cannot budget for a judgement call made later by someone else.

Idempotency is the mechanism, not the policy

Charging an identical retry once requires recognising that it is a retry, which means a request identity that survives the network. An idempotency key supplied by the caller and honoured for a stated window is the conventional answer, and it works the same way here as it does in ordinary payments.

The window length is a real decision. Too short and a legitimate backoff retry is charged twice. Too long and a buyer who genuinely wants the same query again gets a cached answer they did not want. Publishing the window is more important than choosing a particular value.

• Accept a caller-supplied idempotency key
• State the window over which the key is honoured
• Return the original result for a repeat within the window
• Say plainly whether a repeat inside the window is charged

There is no dispute layer to fall back on

Card payments have chargebacks. Invoiced services have credit notes. Current agent payment protocols have neither. x402 and comparable schemes are single-shot and pay-per-call, with no escrow layer, which community discussion has repeatedly identified as the structural gap: payment is bound to a request rather than to an outcome.

That absence is exactly why the rules above have to be published in advance. When there is no mechanism to unwind a charge, the only protection either party has is having agreed what a charge means before it happened.

What a buyer can do about it

Read the provider's stated policy before wiring an endpoint into a loop, and if none exists, treat that as a pricing risk rather than a documentation gap. Cap retries explicitly rather than inheriting a framework default, and cap spend per task so an ambiguous failure mode cannot run away.

For a workflow that will run at volume, test the failure paths deliberately: send a malformed request, send a query you know returns nothing, and see what you are charged. That is cheaper to learn during evaluation than in production.

What a provider should publish

A short, plain statement of which outcomes are chargeable, whether idempotency keys are honoured and for how long, and what happens on provider-side failure. Four sentences is usually enough, and it converts an argument into a specification.

The commercial case is straightforward. A buyer choosing between two comparable endpoints will prefer the one whose costs they can predict, and unpredictable billing is a stronger deterrent than a slightly higher price. Publishing the rule is a cheaper differentiator than undercutting the market.

Related directory entries

Sources and methodology

TOLL·402 distinguishes public claims, registry discovery, unpaid quote checks and settled paid-call verification. Sources below support the visible claims; presence in a registry is not treated as verification.

1. x402 protocol documentation — Request and payment flow that retries operate against.
2. r/mcp discussion on chargeable calls — Community thread where the non-chargeable-call question was raised.
3. r/AI_Agents on single-shot payment and escrow — Discussion of the missing escrow layer in agent payment protocols.
4. x402 rate card — Per-call benchmarks that a retry policy directly affects in practice.