> ## Documentation Index
> Fetch the complete documentation index at: https://docs.anchorage.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Limits

> The spending and request limits an agent is most likely to hit.

The spending and request limits an agent is most likely to hit.

## Spending

| Limit | Who sets it | Approval path |
| - | - | - |
| Daily cap, per agent per UTC day | Anchorage, the same for every agent | None |
| Per-payment limit | Anchorage, the same for every agent | None |
| Budget cap | Your org admin | Admin raises the cap |

Every payment is checked against all three, and the tightest one declines it. A payment above the daily cap or the per-payment limit is declined outright, however much budget is left. To spend beyond them, a person pays directly. Revoking an agent's identity stops it immediately, with no grace window. See [Pause or revoke an agent](https://docs.anchorage.com/agentic-banking/guides/pause-or-revoke-an-agent.md).

The two Anchorage limits are separate controls, and both apply to every payment: the daily cap bounds what an agent spends across a UTC day, and the per-payment limit bounds any one payment. The daily cap is checked per request against the agent's running total for the day, so the two controls bind in different places. A payment over the per-payment limit is declined even on an agent that has spent nothing that day, and a payment within the per-payment limit is declined by the daily cap once that day's total is already close enough to it. A payment that would go past the agent's budget cap is declined with `budget_limit_reached`, or on inference with `payment_declined`; the per-payment limit sits above budgets and holds either way.

## Requests

| Limit | Value |
| - | - |
| Token requests per network address | 100 per minute |
| Request body, MCP and web | 2 MiB |
| Request body, chat completions, Anthropic Messages, and image, video, and audio generation | 1.5 MiB |
| Request body, typed judgments (`/v1/decide`) | 64 KiB |
| Questions per typed judgment | 20 |
| `Idempotency-Key` header, inference | 255 characters |
| Request body, public catalog MCP (`/public-mcp`) | 1 MiB |
| Streamed completion | 10 MiB |
| Paid API response | 10 MiB. A longer response is cut off and marked as truncated |
| Streamed response | Cut off after 120 seconds |
| Active API keys per agent | 10. Revoked keys don't count |

A few steps around connecting and paying are rate-limited:

* **Registering an MCP client and revoking a token** are rate-limited: repeated registration or revocation attempts are refused once they arrive faster than the limit allows. A normal connect — one registration, one consent — stays well inside the limit. A request that hits this limit comes back as a standard HTTP 429 with a `Retry-After` header and the `X-RateLimit-Limit`, `X-RateLimit-Remaining`, and `X-RateLimit-Reset` headers, so a client can wait exactly as long as the response asks and then retry.
* **Getting or refreshing an access token** is limited per network address. After more than 100 token requests in a minute from one address, token requests from that address get HTTP 429 for up to three minutes. Clients that share a network address share the limit. A client that refreshes its token when it expires uses one request an hour.
* **The first time an agent reaches a payment endpoint URL nobody has registered yet** counts against that agent's limit. Once an endpoint URL is registered — whether or not a payment on it completes — later calls to that URL are not limited. A new path under a merchant the agent already knows still counts as first contact if that exact URL hasn't been registered before. A payment tool call that hits this limit returns an error naming the limit; retry shortly.
* **Minting API keys** is rate limited per user. You can mint many keys in quick succession, and once that allowance is spent, further mints are refused for a short while.
* **Typed judgments** are rate limited per agent and across all callers, and too many requests waiting on a slow provider are refused too. A request over the limit gets HTTP 429; retry shortly. See [Typed judgments](https://docs.anchorage.com/agentic-banking/concepts/inference.md#typed-judgments).
* **Every request body is capped at 2 MiB.** A request that declares a body larger than that is refused with a `413` before it reaches the requested action — unless another protection, such as cross-origin request blocking, refuses it first. A request sent without a declared size — for example, chunked transfer encoding — that turns out to exceed the cap is refused once the cap is hit while reading it.


## Related topics

- [Errors, rate limits, and pagination](https://docs.anchorage.com/knowledge-base/porto/api-reference/errors-pagination.md)
- [Get trading account credit limit and usage](https://docs.anchorage.com/knowledge-base/porto/api-reference/v2/trading/get-trading-account-credit-limit-and-usage.md)
- [Agents](https://docs.anchorage.com/agentic-banking/concepts/agents.md)