> For the complete documentation index, see [llms.txt](https://docs.goassay.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.goassay.ai/developers/use-tools-get-started/spending-limits.md).
# Spending limits
Understand the local spending guards, wallet-approved payment-key caps and their defaults.
Paid calls must fit both the limits on your computer and the limits approved by your wallet. Raising one layer does not raise the other. Amounts below are dollar amounts paid in **USDG** on **Robinhood Chain**.
## Defaults and where they are set
| Limit | Default | What it controls | Where you change it |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Local per call | $0.50 | Maximum amount the proxy will sign for one call. | Interactive terminal: `limits set --per-call`. |
| Local rolling 24 hours | $5 | Sum of amounts recorded for signing in the preceding 24 hours, plus this call. | Interactive terminal: `limits set --per-day`. |
| Local confirm-above | Off | Above the threshold, you must approve the exact payment in your client. Equal to the threshold does not prompt. | Interactive terminal: `limits set --confirm-above`. |
| Payment key per call, on chain | $0.50 | Maximum payment amount authorized for this key. | **Per call** on the enable-paid page, approved with your wallet. |
| Payment key per 24 hours, on chain | $5 | Key's spending-window cap, enforced by the contract. | **Per 24 hours** on the enable-paid page, approved with your wallet. |
| Payment key expiry, on chain | 30 days | How long the key can authorize payments. | **Days** on the enable-paid page, approved with your wallet. |
| Account ceiling, on chain | Set to $0.50 per call and $5 per 24 hours during default approval if missing or too low; a sufficient existing ceiling is kept. | Account-wide caps that also bound the key. | Wallet approval on the enable-paid page when needed; **Money → Funding → Change account ceiling** for later changes. |
One local budget covers every Assay server on this computer in the default setup. Your agent's limits also apply across computers.
The local window counts amounts recorded for signing, rather than only successful tool results. It is a rolling total, with no midnight reset. An amount remains counted until it leaves that window, even if the paid call fails later.
The on-chain window works differently: its used-capacity counter drains gradually over 24 hours. It is not an exact sum of payments in the preceding 24 hours. The contract checks both the key's and the account's counters when redeeming a payment.
## Maximum before the key expires
The upper bound is:
```
per-24-hour key cap × (1 + days)
$5 × (1 + 30) = $155
```
At the defaults, the most the key can spend before expiry is **$155**. This bound includes initial spending capacity and the capacity restored over the key's lifetime. It is not a deposit or an extra budget; local limits, agent limits, the account ceiling and available funds can reduce what it can actually spend.
## Check your local limits
Run in a terminal:
```sh
npx -y @goassay-ai/mcp limits
```
For a new default setup, it reports $0.50 a call, $5 per 24 hours, confirmation off and providers unrestricted.
## Check it worked
Confirm that the terminal shows the defaults and that the approval page shows the intended key caps and expiry. A payment must pass all applicable caps; approving larger caps in your wallet does not change the terminal output.
Optional: change a local limit
Run this yourself in an interactive terminal. This example lowers the per-call limit to $0.25 and the rolling total to $2, and asks for confirmation above $0.10:
```sh
npx -y @goassay-ai/mcp limits set --per-call 0.25 --per-day 2 --confirm-above 0.10
npx -y @goassay-ai/mcp limits
```
Both `--per-call` and `--per-day` are required. The per-call amount cannot exceed the daily amount. Omit `--confirm-above` to keep its current value, or pass `--confirm-above off` to disable confirmation.
If confirmation is enabled and your client cannot show confirmation prompts, calls above the threshold are refused. Approval applies only to the exact payment shown.
Local limits are stored on your computer. The command requires both input and output to be interactive terminal streams. A web page, server reply, project config or MCP tool call has no supported way to edit them; ordinary AI subprocesses use pipes and are refused. This is a guard against remote instructions changing your budget, not protection from a program that already has control of your OS user or a terminal.
Optional: change the on-chain key caps
After a key exists, run:
```sh
npx -y @goassay-ai/mcp enable-paid
```
Open the returned link, check the payment key fingerprint, then edit **Per call**, **Per 24 hours** and **Days** (1 to 365) and sign in your wallet. [Turn on paid calls](https://docs.goassay.ai/use-tools/turn-on-paid-calls) shows each screen. Wait for confirmation before asking your client to make another paid call.
These signatures change on-chain permission. They do not change local limits.
## Errors
A refused payment reads **Assay asked for a payment this app refused:** followed by a reason. Find the reason below.
| Reason in the message | Code | Fix |
| ---------------------------------------------------------------- | -------------------------- | ------------------------------------------------------------------------------------------------ |
| the amount is above the local limit per call | `G7_PER_CALL` | Choose a cheaper call, or raise `--per-call` yourself in a terminal. |
| the amount would pass the local limit per 24 hours | `G7_PER_DAY` | Wait for older amounts to leave the rolling window, or raise `--per-day` yourself in a terminal. |
| the amount is above the confirmation limit and was not confirmed | `G7_CONFIRMATION_REQUIRED` | Approve the exact payment in a client that supports confirmation prompts. |
| the amount is above the payment key's on-chain cap | `G6_DELEGATE_CAP` | Use a cheaper call, or raise the key's cap with `enable-paid` and your wallet. |
| the amount is above the escrow's on-chain cap | `G6_ESCROW_CAP` | Use a cheaper call, or raise the account ceiling with your wallet. |
A settings command run through pipes is refused with **changes local safety settings, so it runs only in an interactive terminal**. Run it yourself in a terminal. For other reasons, see [Troubleshooting](/developers/use-tools-advanced/troubleshooting.md#payment-refusals).
## Go further
* Use tools: [Set limits and rules](https://docs.goassay.ai/use-tools/set-limits-and-rules)
## Next
* [Security model](/developers/use-tools-advanced/security-model.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.goassay.ai/developers/use-tools-get-started/spending-limits.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.