Sliding Window Rate Limit Policy • AI Agent SDK

SlidingWindowRateLimitPolicy: Config-driven sliding-window rate-limit policy.

SlidingWindowRateLimitPolicy

Defined in the protocols module.

Config-driven sliding-window rate-limit policy.

The default referenced by `gateway.rate_limit blocks in gateway.yaml and the WebSocketGateway(..., rate_limit_policy=...) Python surface. It is intentionally minimal and dependency-free so the decision lives in core and is provable in isolation; heavy wrapper limiters (gateway/rate_limiter.py sliding window, bots/_rate_limit.py` token bucket) may adopt this protocol while keeping their own state and side effects.

The decision, keyed by `(scope, identity)`:

• `allowed while fewer than max_requests` have been seen in the
• current `window_seconds` window.
• Once the window count exceeds `max_requests`, the key enters a
• `lockout_seconds cooldown and every :meth:check` returns
• `allowed=False with a retry_after_seconds` hint until it elapses.

A `max_requests of 0` disables limiting entirely (every request is allowed) — the legacy default when no rate limit is configured.

This class is not internally synchronised; the wrapper owns any locking it needs for concurrent hot paths (the built-in limiters already do).

State ownership: per-`(scope, identity)` window/lockout entries are reclaimed lazily — a key’s entry is dropped or overwritten the next time that key is checked. It keeps one entry per active key and is intended for a bounded identity space (endpoint classes, authenticated tenants). A wrapper exposing it to an unbounded/untrusted identity space (e.g. raw per-IP keys) owns periodic reclamation, exactly as it owns locking.

Example::

SlidingWindowRateLimitPolicy(max_requests=5, window_seconds=60,
                             lockout_seconds=300)

Constructor

Methods

Source