What bounds cumulative spend when using max_amount?

[tronicspay]

Reading the Payment Policies section — max_amount(1_000_000) caps a single
request at 1 USDC, which is clear. What I can't work out is what's meant to
bound the total.

As I read it, that policy permits one payment of 1 USDC and equally permits ten
thousand of them — there's no counter or window in the policy set. So an agent
in a retry loop, or one that simply does a lot of work, is bounded per-call but
not in aggregate.

Is the intent that the caller owns cumulative accounting? Or have I missed
something in the transport layer?

Asking because I've been working on the other side of this problem and I'd
rather understand your design than assume it's a gap.

---

Possibly more useful to you than my question: in r402, upto is only honoured
by SettlementMode::Sequential — Concurrent and Background charge the signed
maximum. Background is the recommended mode for LLM token streams, which is also
the canonical upto case, so a seller can follow two correct pieces of advice
and end up billing every caller the ceiling.

Your docs do state this. I'd suggest it deserves a louder warning right next to
the streaming recommendation.