Skip to content

Rate limits

The Compliance API allows 600 requests per minute per parent organisation — one budget shared across every key beneath it and every /v1/compliance/* endpoint. The remote session endpoints carry a second budget on top of that.

The SDK reads the server's anthropic-ratelimit-* response headers and waits for the stated reset when the budget is spent, rather than spending a request to discover a 429. Read the latest observation from client.rate_limit_status to pace your own workers.

page = client.activities.list(limit=100)
status = client.rate_limit_status
if status and status.remaining is not None and status.remaining < 50:
    ...  # Slow down: the budget is shared with every other consumer.

rate_limit_rpm on the client caps how fast this client will issue requests. Setting it to 0 disables that local window, but the server-reported budget is still honoured.

rate_limit

Client-side rate limiter for the transport layer.

Sliding-window over a 60-second period, sized by rate_limit_rpm. Defaults to 600 requests per minute to match the documented server-side limit, smoothing bursty callers so they do not have to choose between hitting a 429 and writing their own pacing layer. This limiter is not a substitute for handling 429s — the server remains the source of truth, and rare bursts can still trip its counter ahead of ours.

Two classes are exposed, one per concurrency model, since they need different lock primitives:

  • SlidingWindowLimiter uses Lock.
  • AsyncSlidingWindowLimiter uses Lock.

Both expose the same acquire semantics — block (sync) or suspend (async) until a slot is free, then record the timestamp.

Setting rpm to 0 or a negative value disables the limiter; its acquire becomes a no-op so test transports and integrations that want pure server enforcement can opt out. Note that 0 disables only the local window; observed server headers are still honoured, because those describe a limit the caller cannot opt out of.

On top of the local window, the limiter consumes the server's anthropic-ratelimit-* response headers. The real budget is shared across every key under a parent organisation, so a local counter can never see the whole picture — but once the server reports zero remaining, waiting for the stated reset beats spending a request to discover the 429.

RateLimitSnapshot dataclass

The server's view of the shared request budget, as last seen.

Read off the anthropic-ratelimit-* headers, which the API returns on every authenticated response. The budget is shared across every key under the parent organisation and across every /v1/compliance/* endpoint, so remaining reflects other clients' traffic too.

Attributes:

Name Type Description
limit int | None

The per-minute request budget, or None when the header was absent.

remaining int | None

Requests left in the current window, or None. Watch this to slow down before hitting a 429.

reset_at datetime | None

When the window resets and the budget is restored, or None.

observed_at float

monotonic reading from when this was captured, for working out how stale it is.