Our agent pays for LLM inference and other metered APIs with MPP (the Machine Payments Protocol) sessions through the mppx client, reserving stablecoin once and paying per request or per streamed token. Which settings actually cap what it can spend, which ones only look like a cap, and how do we set a total budget?

What should I check, step by step?

1. Give each agent runtime its own Tempo access key with a daily (or shorter) token spending limit, recipient scopes and an expiry of days, not months. That is the only limit in the MPP docs that holds across channels, processes and restarts.

2. Set maxDeposit to what one job should be able to spend with one API, remembering that it is per channel. The client reserves the smaller of the seller's suggested deposit and your maxDeposit.
3. Set maxAmount (price per request or token) together with currencies and decimals, and list the seller addresses you expect in expectedRecipients, so a changed price or a different payee is rejected before anything is signed.
4. Pin origin and use one channel store per API origin, so one API's session can't be reused against another.
5. For per-token streaming with tempo.session.manager, stream only from APIs you trust and rely on maxDeposit plus the access-key limit, because the manager ignores currencies, expectedRecipients and maxAmount.
6. Decide which code is allowed to pay. Mppx.create patches the global fetch by default, so any tool, plugin or MCP transport using fetch can answer a 402 challenge with the agent's money; keep paid calls behind a wrapper that checks the task's budget first.
7. Close each session with the same manager instance when the job is done (not between requests) and check the receipt's spent value, so unspent reserve comes back and the next job starts from a known balance.
8. Use the SDK's payment hooks to log every challenge, amount, currency and receipt reference with the task that caused it, without logging keys.
9. Test the whole setup on the Moderato testnet with npx mppx before funding a mainnet account.

What do maxDeposit and maxAmount cap in an mppx MPP session?

MPP, co-authored by Stripe and Tempo, is an open protocol in which a server answers a request with HTTP 402 and a payment challenge, the client authorizes payment and retries, and the server returns the resource with a receipt. A session is the pay-as-you-go form: the first paid request opens a payment channel and reserves funds on-chain, later requests or streamed tokens are paid with signed off-chain vouchers, and closing settles what was spent and returns the rest.

• In the mppx client, maxDeposit caps the funds reserved per channel and is explicitly not a cap on total spend across channels. maxAmount caps the price per unit, a request or a token, and requires currencies and explicit decimals; it is not a total either. expectedRecipients rejects offers to any other seller address before signing, and origin pins the API origin that saved channels belong to.
• The docs add that explicit session closes bypass the price and recipient limits, so a client can always get its funds back.

How do you set a total daily budget for an AI agent paying with MPP?

The MPP guide on managing agent spend points to Tempo access keys: delegated signing keys authorized by a wallet, with token spending limits per period, limits on which contracts or functions can be called, recipient restrictions and an expiry. Its example key can spend up to 10 OUSD per 86,400-second period, can only transfer OUSD to one recipient and expires after seven days. Separate keys for separate apps, tools or deployments each get their own budget, scopes and revocation path, and pinning a key to a runtime keeps two deployments from sharing one budget by accident.

• That key-level limit is what stops an agent that opens many channels, restarts and opens them again, or is tricked into paying a new API. Treat maxDeposit and maxAmount as per-API guards on top of it, and keep a running total per task in your own code if a task budget is smaller than the key's daily limit.

Does the mppx session manager enforce price and recipient limits when streaming?

For streamed responses the guide uses tempo.session.manager with .sse(), which signs new vouchers and tops up the channel within maxDeposit without interrupting the stream. The same guide says the manager doesn't enforce currencies, expectedRecipients or maxAmount, so a streaming API can raise its per-token price and the client keeps paying until the reserve or the access-key limit runs out.

• By default Mppx.create installs a payment-aware global fetch. That is how existing HTTP tools and MCP transports pay without code changes, and it also means any code in the process that uses fetch, including a third-party tool or a page the agent was told to open, can trigger a payment when the server returns an MPP challenge. The same client can also pay compatible x402 exact endpoints if you add that method, which widens what a 402 can charge.
• Reserves stay locked until the channel closes, and close() only works on the manager instance that made the requests (or one that has loaded the channel from a shared channelStore on its next request). If a seller stops responding, the payer can request a close on-chain and, after Tempo's 900-second grace period, withdraw whatever the seller hasn't settled; the seller can still settle what was spent until then. On the seller side, Stripe's docs note that usage accrues in units as small as 0.000001 USDC but settles to the Stripe balance in whole cents, with sub-cent remainders forfeited.