Metered and streaming x402 payments
One call, one payment was never the only shape. Sessions and streaming authorizations change how a paid endpoint should be priced and budgeted.
DIRECT ANSWER
x402 v2 added session support so a client authenticates once instead of repeating a payment handshake per call, and providers have begun shipping streaming authorizations where one signed approval carries a hard cap and usage is metered by the second or token. Both break the assumption that every request carries its own settlement.
Key takeaways
- Per-call settlement is a default, not a requirement of the protocol.
- Sessions move cost off the per-request path, which changes what a low headline price means.
- A cap bounds how much an agent can spend; it does not bind spend to a useful outcome.
The assumption worth revisiting
Most published guidance on pricing x402 endpoints, including our own, assumes a clean one-to-one relationship: a request arrives, a requirement is returned, a payment settles, a response comes back. That model is easy to reason about and it is what the majority of deployed endpoints still do.
It is not the only shape the protocol supports, and two developments in 2026 moved meaningfully away from it. Anyone setting a price today should know which model they are pricing for, because the arithmetic differs.
What v2 sessions changed
In the first version of the protocol every API call required a full on-chain transaction, which made high-frequency patterns like streaming data or rapid successive queries impractical. The cost and latency of settlement dominated the cost of the work.
x402 v2 introduced session support: a client authenticates once and makes subsequent requests without repeating the payment handshake, reducing both latency and on-chain cost. The same release separated the protocol specification from its SDK implementation and from facilitators, so a new chain or payment model can ship as a standalone package rather than as a change to the core.
What streaming authorizations add
A separate pattern has appeared on the buyer side. One provider shipped a model where an agent gives a single signed authorization carrying a hard spending cap, and usage is then metered by the second or by the token, settled in increments and never above what was actually consumed.
That is closer to how metered infrastructure has always been sold than to how per-call APIs are sold. The buyer commits to a ceiling rather than to a quantity, and the seller collects against consumption rather than against request count.
| Model | Settles | Buyer commits to | Suits |
|---|---|---|---|
| Per-call | Every request | Nothing in advance | Occasional, discrete lookups |
| Session | Once per session | A session | Bursty or high-frequency querying |
| Streaming with cap | In increments | A ceiling | Continuous or long-running consumption |
What this does to a headline price
A per-call price is only comparable against another per-call price for the same unit of work. Once settlement overhead moves off the request path, a provider can charge less per request without earning less, and a buyer comparing two headline figures may be comparing different things entirely.
Our current benchmarks show a provider-weighted median of one cent per call across all categories, with capability medians ranging from half a cent for web scraping and inference up to a little over two cents for video and audio generation. Those figures describe published per-call quotes. They are not directly comparable with a metered rate quoted per second or per token.
Pricing a session honestly
The temptation with a session is to price the session and stop thinking about the calls inside it. That works until a buyer discovers that one session covers ten requests for one user and ten thousand for another, at which point the model either loses money or gets quietly rewritten.
The usable approach is to decide what the session is a container for. A session bounded by time, by request count, or by volume of returned data is priceable. A session bounded by nothing is an unmetered subscription wearing a payment protocol, which may be what you want but should be a deliberate choice.
- State what ends a session: time, count, volume or explicit close
- State whether an expired session fails closed or silently re-authenticates
- State whether unused capacity is refunded, which for x402 usually means it is not
- Publish the per-unit equivalent so buyers can compare with per-call sellers
Caps bound spend, not outcomes
A hard cap on a streaming authorization is a genuinely useful control. It means an agent that misbehaves, loops, or is manipulated cannot spend more than a stated amount, and that bound is enforced by the authorization rather than by the agent's own good behaviour.
It does not make the spending productive. Community discussion of agent payment protocols keeps returning to the same gap: these schemes are single-shot and pay-per-call with no escrow layer anywhere, so payment is bound to a request rather than to a result. A cap answers how much, and nothing yet answers for what.
Budgeting on the buyer side
An agent operating against a metered endpoint needs a different budget model from one calling discrete paid routes. Per-task caps stop working well when consumption is continuous, and a per-period ceiling with a per-task sub-limit is usually the more workable shape.
Buyer-side infrastructure is moving in the same direction, with delegated wallets that let an account owner fund a pool and give individual agents scoped, capped access to it. That model composes naturally with streaming authorizations and awkwardly with per-call settlement, which is another reason to know which one an endpoint expects.
What to do now
For a provider, decide which model your endpoint is actually offering and say so in your documentation and your requirement. A per-call requirement returned to a buyer expecting a session is an integration failure that looks like a pricing disagreement.
For a buyer, check what the endpoint returns before assuming per-call settlement, and re-check when call volume changes, since a route that was cheap at low frequency can be structured very differently at high frequency. Claims here are as of 5 August 2026 and this area is moving quickly.
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.
- x402 v2 launch note — First-party description of session support and the modular spec, SDK and facilitator split.
- x402 protocol documentation — Networks and assets available to any settlement model.
- x402 rate card — Per-call benchmarks by capability, for comparison against metered quotes.
- r/AI_Agents on single-shot payment and escrow — Community discussion of binding payment to outcome rather than to a request.