Skip to main content
Sandbox rate limits use token buckets keyed by account and policy per server process. Multiple instances each grant an allowance; these numbers are not a fleet-wide quota. Live-mode limits and sessions are not available. Do not build against a promised live rate.

Current sandbox limits

Short bursts are absorbed until the bucket is empty. Test verification requires a key.

Headers

Every response carries the IETF RateLimit-Policy and RateLimit header fields for the limit the call counted against:
The supported policy names are checks, generations and default.

When you exceed a limit

The call fails with 429 rate_limited and a Retry-After header in seconds. Nothing ran: no check was decided and no object was created.
Wait Retry-After seconds, then retry with the same Idempotency-Key. The retry function in Idempotency does both. Sessions are planned and cannot be used yet.
A 429 on a check is not permission. Do not generate a named talent until a retry returns allow.

Stay under the limits

  • Read RateLimit and slow down before r reaches zero.
  • Retry unknown outcomes with the same persisted Idempotency-Key and body.
  • Poll an escalated check or asynchronous generation no faster than once every five seconds.
  • Webhooks, the name index and usage batching remain planned; they are not current alternatives to polling.
Service status is at status.reflections.ai. Rate-limit increases and production capacity require an explicit service agreement; they are not self-service features.

Errors

Every error code and what to do.

Caching and outages

Reuse windows, the revocation feed and retries.