x402 can now charge for what an agent actually used

The upto scheme lets a seller advertise a ceiling, take one signature for it, then settle the real amount. It landed on Solana on August 12 — and it collides with the new one-dollar client cap.

By XAgent Team · 2026-08-19

Most things an agent buys do not have a price until after they are delivered. A model call costs whatever the token count turns out to be. A dynamic query costs whatever it reads. The exact scheme, which is what almost every x402 integration runs today, cannot express that: it takes one fixed number, signs it, and settles it.

The upto scheme is the answer x402 has been building toward, and on August 12 its Solana implementation merged — 126 files, most of a working payment-channel flow. The scheme documentation describes it in one sentence: "The upto scheme lets a seller advertise a maximum price for one request, then settle for the actual amount used. The buyer signs once for the maximum, and the server chooses a final amount that is less than or equal to that maximum."

What the buyer signs is a ceiling, not a price

The server side is small. From the same document: "Set the route price to the maximum authorized amount. In the handler, use settlement overrides to charge the actual amount."

app.get("/api/generate", (req, res) => {
  const actualUsage = computeActualCost();
  setSettlementOverrides(res, { amount: String(actualUsage) });
  res.json({ result: "..." });
});

The override accepts three forms, which is more flexible than it first looks: raw atomic units ("50000"), a percentage of the route maximum ("50%"), or a dollar-denominated price ("$0.05"). The percentage form is the one worth noticing — it lets a handler settle proportionally without knowing the token's decimals.

Zero is a legal amount, and the docs are careful about what it costs: "Setting the amount to "0" means no charge for that request. On SVM, a zero-amount close still lands a transaction to release the escrowed deposit and channel rent." A free response is not a free settlement. Someone still pays to unwind the escrow.

The intended workloads are named explicitly: "Use upto for one-request usage metering, such as LLM token generation, bandwidth, compute time, or dynamic data queries." One request. This is not a subscription or a running tab.

The two chains solve the same problem differently

On EVM the mechanism is an allowance: "upto on EVM uses Permit2 because the settled amount is not known when the buyer signs. The facilitator advertises a facilitatorAddress in the payment requirements, and the client binds the authorization to that facilitator." The buyer authorises a specific facilitator up to a ceiling, and trusts it to pull only what the server declares.

On Solana it is an escrow. Per the docs: "The client escrows the ceiling amount in an onchain channel (open), and the server settles the actual amount with a signed voucher (settle_and_seal + distribute). The facilitator sponsors transaction fees and channel rent as a zero-share channel payee, and can always close abandoned channels to recover rent."

Two operational details fall out of that sentence, and both matter if you are running the seller side.

The server needs a signing key that never holds funds: "The server must supply a receiverAuthorizerSigner — a hot key that signs settlement vouchers after metering. This key does not need to hold SOL or tokens." That is a good separation. The key that meters is not the key that can be drained.

And the facilitator is carrying float. It sponsors fees and channel rent as a zero-share payee, which means every open channel is capital it has posted and has to reclaim. If you run your own facilitator, abandoned channels are your problem, not the buyer's.

The claim transaction is the one that can fail expensively

Two days after the flow merged, a follow-up fixed something easy to miss. None of the three SVM upto transaction types set a compute budget, so the runtime derived one: "so every upto transaction reserved 400,000–403,000 CU while consuming ~600–50,000." The reference client, the PR notes, was reserving the spec ceiling "while using ~12% of it."

Over-reserving compute is a cost problem. The second finding is a revenue problem, and it is stated plainly in the PR: "With no SetComputeUnitPrice these transactions have zero priority and pay base fee only. The claim is time-critical — the resource has already been served and the voucher expires — so on a congested mainnet a dropped claim is a served-but-unpaid window until retry."

Read that ordering again, because it is the structural risk in every settle-after-delivery design. The goods ship first. The payment transaction goes out second, into a fee market the seller does not control, carrying an expiry. exact does not have this exposure — it verifies before the handler runs. upto moves the settlement after delivery, and buys pricing accuracy with a window in which you have delivered and not been paid.

Your ceiling is what the spend cap sees

Here is the part that will surprise people, and it is a direct interaction with the client-side spend controls that shipped the following day.

The default client cap is a constant in x402Client.ts: export const DEFAULT_MAX_AMOUNT_PER_PAYMENT: Money = "$1";. The filter that applies it reads the amount off the payment requirement. For an upto route that amount is the maximum, because the docs tell you to set price to the maximum authorized amount.

Nothing in the filter exempts a scheme. It resolves the default asset per scheme, then applies the same ceiling to whatever amount the requirement advertises. So an upto route that advertises a $2 maximum and settles a tenth of a cent on a typical call is filtered out by a default client before signing. The buyer never learns your real price, because your real price does not exist until after a request the client refused to make.

Mixed offers survive this — the filter's own comment says it "Keeps any accept that fits so a mixed offer can still pay the affordable option." And when every option is rejected the client throws rather than failing quietly, with a message naming the fix: "All payment requirements were rejected by spendControls: only default assets or entries in spendControls.allowedAssets are allowed." That string is worth grepping your logs for.

The practical rule: your advertised ceiling is your effective price for default clients, not your average settlement. Price the maximum as if it were what you charge, because to the gate, it is.

What's next

upto is the first x402 scheme whose pricing model matches how agent workloads actually bill, and that makes it the one to watch. It also introduces the first real post-delivery credit risk into the protocol, which is a different kind of operational burden than exact ever imposed.

For anyone metering an agent-facing service, two things need deciding now. Where your ceiling sits relative to a one-dollar default, and who eats the settlement transaction when the chain is busy. Neither is a protocol question — they are the operations layer, and they are exactly the surfaces we build the open execution market around. If you are quoting usage-metered work to agents, test against a default client, not your own.

Correction, 2026-08-19: an earlier version of this post introduced the upto definition as coming from "the spec". The sentence is from docs/schemes/upto.mdx, the scheme documentation — not from specs/x402-specification-v2.md. The quotation was accurate; the attribution was not, and the two are different documents with different authority. The source is now named and linked at first use.