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

# Rate limits

> Gomry Cloud rate limits per API key, not per IP: the default budget, the headers to read, and how to back off correctly.

Rate limits are applied **per API key**, using a sliding window.

<h2 id="why-per-key">
  Per key, never per IP
</h2>

An IP-based limit is wrong in both directions: several customers behind one NAT throttle each other, and a caller distributed across many addresses evades it entirely. A key is the unit you control, so it is the unit we limit. Running two workers? Give them a key each and they get a budget each.

<h2 id="headers">
  Headers
</h2>

Every rate-limited response carries your remaining budget. Read these rather than counting requests yourself — the window slides, so your count and ours will not agree.

| Field                   | Description                                                |
| ----------------------- | ---------------------------------------------------------- |
| `x-ratelimit-remaining` | Requests left in the current window for this key.          |
| `x-ratelimit-reset`     | Unix timestamp in milliseconds at which the window resets. |

Exceeding the limit returns `429 rate_limited`. Back off until `x-ratelimit-reset`, with jitter — retrying the instant the window opens is how a fleet of workers synchronises itself into a thundering herd.

<h2 id="defaults">
  Limits
</h2>

The default is 120 requests per minute per key. If your workload needs more, ask — the limit exists to protect shared upstream capacity, not to sell you a tier.

<Note>
  A rate limit is not a spend control. It caps the rate of requests, not their cost. To bound what a project can spend, set a monthly budget — see [Billing](/billing).
</Note>