Skip to main content
An agent without a subscription can pay for one request and get one answer. No sign-up, no card, no plan — the payment rides on the HTTP request itself, using x402. This is the path for software that needs an answer now and cannot pause to have a human create an account.

What happens

Run out of free queries and the API answers 402 instead of 429, with what it wants:
The client signs an EIP-3009 transferWithAuthorization for that amount and repeats the request with an X-PAYMENT header. The server verifies the signature, runs the query, and only then settles on-chain — so a failed request is not charged. maxAmountRequired is in atomic units: USDC has six decimals, so 5000 is $0.005.
The signature is not a transaction. A facilitator submits it and pays the gas, so the paying wallet needs USDC and no ETH.

Prices

Streaming is excluded on purpose rather than by omission: settling every tick would cost more in fees than the tick is worth. It needs a subscription. Free accounts get 10 queries, then one per day. Payment only enters the picture once that is spent — check with GET /api/cli/billing/tier.

From the CLI

The recipient is shown before you sign, on purpose: if a compromised server ever redirected payment elsewhere, the address is where you would see it.

Unattended

--agent implies --auto-pay. Two guards worth knowing: SHUMI_MAX_PRICE_USDC refuses anything above a ceiling, and the wallet only ever holds what you put in it.

Why the login wallet is not the paying wallet

Signing has to happen in the process making the request, and a wallet you signed in with — Trust, MetaMask, a phone app — keeps its key where the CLI cannot reach it. So shumi login establishes who you are, and shumi wallet is what pays. They are deliberately separate. For an agent this is the useful shape: the paying wallet is a small, funded key it holds, with no human in the loop and no bearing on identity.