Rate limits

Three limits apply independently: how fast you may send requests, how many may be in flight at once, and how many tokens you may consume in a billing period.

Three separate limits

Limit	Window	Error when exceeded
Requests per minute	Fixed 60-second window	`rate_limit_error`
Concurrent requests	In-flight at any instant	`rate_limit_error`
Token allowance	Billing period	`quota_exceeded`

The exact numbers come from your plan and are shown on the pricing page. They can be raised on your account without changing plan — ask.

Rate limit headers

Every response carries your current position in the per-minute window.

anthropic-ratelimit-requests-limit: 600
anthropic-ratelimit-requests-remaining: 587
anthropic-ratelimit-requests-reset: 2026-07-30T17:04:00+00:00

A 429 from the per-minute limit also carries Retry-After in seconds. Honouring it is the fastest way through — it is the exact time until the window rolls over, not a guess.

Concurrency

A concurrency slot is held for the whole life of a request, including a long streamed completion. Slots carry a timeout, so a client that disconnects mid-stream cannot leak a slot and slowly starve your account.

If you are running a batch job, cap your worker pool at your concurrency limit rather than relying on 429s to throttle you. It is faster and it leaves headroom for your interactive traffic.

Monthly allowance

Tokens count against the allowance with cache reads weighted at 10% and cache writes at 125%, matching how they are priced upstream. Prompt caching therefore stretches your allowance as well as reducing your bill.

Once the allowance is used, behaviour depends on your plan. If overage is enabled you keep serving and the excess is billed per million tokens. If it is not, requests are refused with quota_exceeded. Either way there is a hard ceiling — a runaway loop on your side cannot run up an unbounded bill.

Checking your usage

GET /v1/usage is free and not rate limited. Poll it to degrade gracefully rather than discovering the limit through a 429.

curl https://ai.dijitul.uk/v1/usage -H "x-api-key: $GATEWAY_API_KEY"

{
  "period": { "start": "2026-07-14T00:00:00+01:00", "end": "2026-08-14T00:00:00+01:00" },
  "plan": "studio",
  "residency": "eu",
  "privacy_mode": "tokenise",
  "tokens": {
    "allowance": 14000000,
    "used": 8420117,
    "remaining": 5579883,
    "percent_used": 60.14,
    "overage_allowed": true
  },
  "rate_limit": { "requests_per_minute": 600, "remaining": 587, "concurrency": 12 },
  "by_model": [
    { "model": "claude-sonnet-4-6", "requests": 4120, "billable_tokens": 7900112, "cost_gbp": 61.2841 }
  ]
}

Handling limits well

Retry rate_limit_error with backoff; never retry quota_exceeded.
Use Retry-After when present rather than a fixed sleep.
Add jitter, or a fleet of workers will retry in lockstep and collide again.
Watch percent_used and warn your own users before you hit the ceiling.
Use a cheaper model for bulk work — allowance is counted in tokens, not requests.