Rate Limits

Both apply simultaneously — whichever you hit first is the one that blocks the request. Limits are sliding windows, not fixed resets at midnight: making 10 requests at 9:00:00 and then waiting means you can make more starting around 9:01:00, not at the top of the next clock minute.

Every response that got past authentication (even a 429) includes:

Not included on a 401 from an unrecognized key — revealing bucket state to a caller who hasn't proven they hold a valid key would help an attacker probe key guesses more efficiently.

Exceeding either limit returns 429 with both a standard Retry-After header and a retry_after_seconds field in the JSON body — use either, they carry the same value:

{
  "error": {
    "code": "rate_limited",
    "message": "Rate limit exceeded.",
    "retry_after_seconds": 12
  }
}

The reference Discord bot handles this by catching the 429 and telling the user how long to wait instead of erroring — see RateLimited in Discord Bot for the pattern, and Examples for a standalone retry snippet.

Separately from per-key limits, the API applies a temporary, account-wide capacity safeguard during periods of unusually high overall demand across every key combined — this protects the service's shared infrastructure, which the main chat app also depends on. It surfaces as 503 capacity_exceeded (see Errors) and, unlike a 429, isn't about anything you personally did — just retry after a short backoff.

The free tier is intentionally modest. If you need higher limits for a legitimate production use case, reach out via the contact address in the Terms of Service — there's no self-serve paid tier yet.