Metered inference

The situation

A coding agent calls a large language model and does not know in advance how many tokens the answer will take. A per-request price does not fit, and an on-chain payment per token would cost more than the tokens. The seller wants to stop serving the moment money stops; the agent wants to stop paying the moment the answer ends. No human is present during the stream: the owner set a budget earlier.

The Machine Payments Protocol (MPP) handles this with a payment channel on the Tempo chain. The agent deposits into an escrow, signs off-chain vouchers that raise a running total as tokens arrive, and the server settles on chain when it chooses.^{Source [1]} One correction up front: “session” is not a standardized MPP intent. The only intents in the specification folder are charge and subscription, and a pull request for a generic session intent was closed without merging on 2026-09-28.^{Source [2, 3]} The session in this scenario is the one defined by the Tempo payment method.^{Source [1, 4, 5, 6, 7, 8]}

Actors

• Client agent with a Tempo wallet, or with a delegated authorizedSigner key that signs vouchers.^{Source [1]}
• Inference API server, the payee, which issues challenges, keeps per-channel accounting and settles.
• Tempo channel escrow: a contract in session v1 and a TIP-20 channel reserve precompile in v2.^{Source [1]} Tempo mainnet is chain 4217 and produces blocks about every 600 ms with deterministic finality.^{Source [9, 10, 11]}

Step by step

All thirteen steps belong to MPP (core draft plus the Tempo session method).

1. The agent sends the request, optionally with Accept-Payment naming method and intent pairs such as tempo/session.^{Source [12]}
2. The server answers 402 with WWW-Authenticate: Payment; the challenge requires id, realm, method, intent and request.^{Source [12]} For a session, amount is a price per unit, with unitType, suggestedDeposit, currency, recipient and a required methodDetails.escrowContract.^{Source [1]}
3. The agent chooses a deposit and signs the open transaction plus a voucher for zero.^{Source [1]}
4. It retries with Authorization: Payment and payload action open.^{Source [1]}
5. The server broadcasts the open transaction. It pays that fee only if its challenge set feePayer.^{Source [1, 13]}
6. The stream starts. Every paid response carries a Payment-Receipt with challengeId, channelId, acceptedCumulative and spent; its reference is the channelId.^{Source [1]} For SSE the receipt arrives in the headers and again as a final event.^{Source [1]}
7. As tokens arrive the agent signs vouchers with channelId, cumulativeAmount and an EIP-712 signature; amounts are running totals, not deltas.^{Source [1]} Vouchers go to the same URI and may ride on HEAD requests.^{Source [1]}
8. When the deposit is used up, the server pauses and emits payment-need-voucher.^{Source [1]}
9. The agent sends action topUp with additionalDeposit. A top-up needs a fresh challenge, which a HEAD request can fetch.^{Source [1]}
10. The server broadcasts the top-up and may settle at any time. It pays the fees for settle and close.^{Source [1, 13]}
11. The agent sends action close with a final voucher.^{Source [1]}
12. In session v2 the server captures max(spent, settled on chain) and refunds the rest of the deposit to the payer.^{Source [1]}
13. The final receipt includes the close txHash.^{Source [1]}

Which protocol does what

The current core draft is draft-httpauth-payment-01, published 2026-09-09; it is an individual submission, not an IETF standard.^{Source [14]} Session v2 text was merged on 2026-06-25.^{Source [15, 16]}

Where controls apply

• Before authorization. A policy reads the decoded challenge: recipient allowlist, price per unit, method preference.^{Source [12]} Every top-up is a new spending decision and deserves the same check.
• At signing. The deposit is the hard cap: vouchers cannot exceed it, so exposure is bounded by what the agent locked.^{Source [1]} MPP has no budget object of its own; limits come from the rail, here the deposit.^{Source [1, 17, 18]}
• At the edge. A 403 means the payment was valid but policy denies access, with no new challenge.^{Source [12]}
• At settlement. TIP-20 policy allow and block lists on Tempo act on the token transfers.^{Source [19]}
• After the fact. Receipts carry spent and acceptedCumulative, so the agent can reconcile them against the close transaction. Channels have no expiry and vouchers have no validUntil, so idle channels need a policy to close them.^{Source [1]}

What is observable from outside

Tempo settlement is public, and MPPscan by Merit Systems indexes MPP servers, agents, transactions and volume.^{Source [9, 20]} MPPscan reported 998,771 transactions and 8,774 USD of volume in the 30 days to 2026-10-11.^{Source [20]} On chain an observer sees the open, each top-up, any settle and the close, with payer, payee and amounts.^{Source [1]} The vouchers themselves stay off chain, so per-token pricing and the timing of use stay between agent and server.^{Source [1]} Challenges, credentials and receipts are bilateral HTTP headers.^{Source [12]}

What can go wrong

• The server stops answering. The agent calls requestClose, waits a grace period of at least 15 minutes during which the server can still settle, then calls withdraw.^{Source [1]} The spec advises waiting at least 16 minutes.^{Source [1]} The agent loses time, not money beyond what it signed.
• A top-up during a pending close. It cancels the close request and emits CloseRequestCancelled.^{Source [1]}
• Bad vouchers. A wrong signer, a total above the deposit or a too-small increase is rejected; the server serves nothing more and carries the risk of anything it delivered beyond its last accepted voucher.^{Source [1]}
• SDK bugs. CVE-2026-34209 let a close voucher equal to the settled amount close or grief a channel for free in mppx before 0.4.11.^{Source [21, 22]} Both MPP SDKs had critical advisories within two weeks of launch.^{Source [23, 24]}
• Wrong cost model. Session v2 cut gas for opening a channel with an existing reserve balance by 72.1 percent, but raised gas for settling to a new payee balance by 79.4 percent. The 72 percent figure is a best case for one operation, not a general saving.^{Source [15]}

Costs: MPP defines no protocol fee.^{Source [12]} For a 50,000-gas transfer Tempo’s base fee is capped at about $0.0006 (as of 2026-10-11).^{Source [25]}

Variants

MPP’s own documentation names x402 upto and EVM batch-settlement as the usage-based counterparts to the session.^{Source [26]}

In upto the client signs a Permit2 authorization for a ceiling and the server settles the metered charge, which must not exceed it.^{Source [27]} The client must trust the server to charge fairly up to that ceiling.^{Source [27, 28]} batch-settlement opens a channel with a deposit, carries a cumulative voucher on each request, and claims many vouchers in one token transfer.^{Source [29]} Its exit is initiateWithdraw and then finalizeWithdraw after a withdrawDelay of 15 minutes to 30 days.^{Source [29]} With mppx one server route can offer both MPP and x402 challenges and accept either credential.^{Source [26, 30]}

# Illustrative example, spec version draft-httpauth-payment-01.
POST /v1/chat/completions HTTP/1.1
Host: api.llm-service.example
Accept: text/event-stream
Accept-Payment: tempo/session, tempo/charge;q=0.5
Content-Type: application/json