Allowances and spending

An allowance provides bounded payment authority. A balance is an observation of funds, not a grant of permission. A tier determines service entitlement and resource limits; it is not the wallet balance. Existing profiles retain their payer and policy rather than being reset by a tutorial.

run402 allowance balance
run402 tier status
run402 status

A fresh supported Cloud setup can use the free prototype tier on testnet. Testnet settlement is not a real-money payment. Before production operations, inspect the selected payer, network, allowance and tier; follow the billing reference for the chosen payment rail. An unavailable balance read means unknown, not zero or “funded”.

A prepaid balance and configured spending limits constrain the operations governed by that payment path. Do not assume one allowance caps external APIs called by application code, every provider-side charge, or all application billing. Replenishment, holds, settlement, refunds and revocation depend on the selected payment flow. Inspect its returned state; a timeout or pending receipt does not prove payment failed.

For a paid retry, preserve the operation’s idempotency key and heed safe_to_retry, mutation state and timing. Do not issue a new payment merely because the response was lost. Revoking future authority does not reverse a settled payment. Use the error and retry contract to distinguish those outcomes.