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

​
Spending

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. 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

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.
  • 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.