# x402 exact vs upto, and when to use each

The exact scheme charges a price the server states before doing the work, and the client signs for that amount. The upto scheme authorises a maximum and settles for the actual cost once the work is done, which suits metered output. Exact is simpler and safer for buyers; upto is necessary when cost is unknowable in advance.

Published: 2026-10-14
Last reviewed: 2026-10-14
Publisher: Roundhouse AI Ltd.
Source: https://roundhouseai.io/resources/x402-exact-vs-upto-schemes

---

## What is the difference?

Both schemes produce a signed authorisation and both settle on-chain. They differ in when the price is known.

| | `exact` | `upto` |
| --- | --- | --- |
| Price known | Before the work | After the work |
| Client signs for | The price | A ceiling |
| Server settles for | The price | The actual cost |
| Buyer's exposure | The stated price | Anything up to the ceiling |
| Natural fit | A query, a page, a file | Token-metered inference |

With `exact`, the server says ten thousand smallest units and the client signs ten thousand smallest units. Nothing can surprise either party.

With `upto`, the client signs a ceiling of, say, fifty thousand, the server generates a response that happens to cost twelve thousand, and it settles twelve thousand. The remaining authorisation is never spent.

## Why does upto exist at all?

Because some prices genuinely cannot be computed before the work.

The clearest case is language-model inference priced per output token. The server cannot know how long the answer will be until it has produced it. Under `exact` it would have to quote a worst-case price for every request, which means overcharging on almost all of them, or quote an average and lose money on the long tail.

The same shape appears in anything with variable work: a crawl whose page count depends on the site, a query whose cost depends on rows scanned, a render whose cost depends on resolution.

> [!NOTE]
> This is the same reason cloud billing is metered rather than quoted. What is new is that the meter now has to be settled in one HTTP exchange with a counterparty that has no account, which removes the usual option of billing monthly in arrears.

## What does upto cost a buyer?

Trust, which is a real price for an agent buying from a stranger.

Under `exact`, a buyer evaluating a seller it has never used risks exactly the stated amount. Under `upto`, it risks the ceiling, and the only thing stopping a seller from settling the full ceiling every time is the seller's honesty and the buyer's ability to notice afterwards.

That asymmetry is worth designing against on both sides.

**As a seller using `upto`:** publish your rate, return the usage in the response, and keep the ratio of settled to authorised high. A seller that routinely settles ninety-five percent of every ceiling is indistinguishable from one charging a flat fee, and buyers will treat it as one.

**As a buyer:** set the ceiling from your own estimate rather than accepting the seller's suggestion, cap the ceiling as a fraction of your budget, and check settled against authorised afterwards. A seller whose settlements cluster at the ceiling is telling you something.

## Which should a new seller use?

`exact`, unless the price genuinely cannot be known in advance.

Most things sold over x402 have a fixed cost per call: a lookup, a page of results, a data point, a verification. For those, `exact` is simpler to implement, simpler to reason about, easier to compare against competitors, and does not ask a buyer for trust it has no basis for extending.

Reach for `upto` when the alternative is quoting a worst case that makes you uncompetitive. Inference is the clear case. "My responses vary a bit in size" usually is not, because you can price the average and accept the variance yourself.

## How does the choice affect discoverability?

More than you would think. A buyer comparing endpoints that do the same thing has to compare prices, and an `exact` price is directly comparable while a ceiling is not.

Two sellers advertising `exact` at two thousand and three thousand smallest units can be ranked instantly. A seller advertising `upto` fifty thousand looks more expensive than both to anything doing naive comparison, even if it settles at one thousand in practice. [Pricing an endpoint for agents](https://roundhouseai.io/resources/x402-payment-requirements-accepts-schema) is where this matters commercially: automated comparison rewards legibility.

If you use `upto`, publish a typical settled amount somewhere a buyer can read before it signs. A catalogue entry, your documentation or a free metadata endpoint all work. Letting the ceiling be the only visible number is leaving money on the table.

## Frequently asked questions

### Can one endpoint offer both schemes?

Yes. The `accepts` array can carry an entry for each, and the client picks. This is reasonable if you have a cheap deterministic path and an expensive variable one, though it doubles what you have to implement and test.

### What happens to the unspent part of an upto authorisation?

Nothing moves. The authorisation names a maximum; settling a smaller amount transfers only that amount and consumes the nonce. There is no refund step because there was no overpayment.

### Can a server settle more than the authorised ceiling?

No. The ceiling is in the signed message and the token contract enforces it. A settlement above it simply fails, which is a protocol-level guarantee rather than a promise from the seller.

### Does upto work on every chain and facilitator?

Support is less universal than for `exact`. Check your facilitator's documentation before building on it, and advertise an `exact` entry alongside it so a client that does not implement `upto` still has a way to pay.

### How does an index record an upto payment?

By the settled amount, because that is what moved. A record built from authorised ceilings would overstate volume, sometimes by a lot. If you are reading someone's figures, it is worth knowing which of the two they counted.

## Where to check this yourself

The [schemes and networks](https://roundhouseai.io/docs/x402/schemes-and-networks) documentation lists what Roundhouse's facilitator implements and on which chains. For the market side, [/services](https://roundhouseai.io/services) shows the price distribution across the indexed catalogue, and [/transactions](https://roundhouseai.io/transactions) shows settled amounts rather than advertised ones, which is the comparison that tells you whether a seller's ceiling means anything.

---

Roundhouse indexes x402 settlements and ERC-8004 identities into one public record.

- Every article: https://roundhouseai.io/resources.md
- Every surface on this site: https://roundhouseai.io/llms.txt
- The index, endpoints and schema: https://api.roundhouseai.io/v0
- A key of your own, $0.01 over x402, no account: https://api.roundhouseai.io/v0/test/x402
- Limits and the SQL surface: https://roundhouseai.io/docs/api
