Skip to content
Compresr docs

API reference

Rate limits

Compresr tier-based rate limits, per-model scaling, and how to handle 429.

Compresr rate-limits per user across three separate quotas: requests per minute (rpm), tokens per minute (tpm), and requests per day (rpd). Your tier is determined by monthly compressed-token volume; hitting any quota returns 429 with a Retry-After header.

Tiers

Here are the current limits per tier. To read them programmatically, use GET /billing/tiers.

Limits also scale with the model you call: latte_v2-family models run at roughly twice the base rpm/tpm. The per-model matrices are in the GET /billing/tiers response under scale_limits. Individual keys can also carry an optional daily request cap, set at key creation.

Handling 429

The Retry-After header (seconds to wait, mirrored as retry_after in the error envelope) is the only rate-limit signal the API sends — there are no X-RateLimit-* headers. Retry with exponential backoff that treats Retry-After as a floor.

429 also covers usage-balance exhaustion (the API pre-authorizes each request at worst-case cost). A rate-limit 429 clears when the window rolls over; a balance 429 does not — check the error message to tell them apart.

Need higher limits?

If you hit 429 routinely under normal load, retries won't fix it — contact us at [email protected] for a tier upgrade.

Retry pattern
python
429 response
text