Quotas and limits
SREDSimplify protects the platform with two different mechanisms:
- short-lived request rate limits
- longer-lived product usage quotas
Rate limits vs quotas
Rate limits protect bursty behavior on specific endpoints. Quotas protect plan-level consumption such as AI runs, storage, and project counts.
Both can surface as 429, but they mean different things:
- request-rate limit: usually short-lived, may include
Retry-After - quota exhaustion: plan or period budget exhausted, usually requires waiting for reset or changing plan/usage
Current user quota snapshot
Current user quota is available at:
GET /api/v1/quotas/me
Returned fields include:
| Field | Meaning |
|---|---|
tier | Current membership tier |
storageUsedBytes / storageLimitBytes | Storage usage vs cap |
projectsUsed / projectsLimit | Project count vs cap |
filesPerProjectLimit | Maximum files per project |
aiRunsMonthlyUsed / aiRunsMonthlyLimit | Monthly AI-run usage vs cap |
fileSizeLimitBytes | Maximum allowed size for a single file |
periodKey | Current usage period key, formatted like YYYY-MM |
Current tracked quota metrics
The quota subsystem tracks these metric families:
PROJECT_COUNTFILES_PER_PROJECTSTORAGE_BYTESAI_RUNS_MONTHLYFILE_SIZE_BYTES
Membership tiers
Current tiers are:
FREESTARTERPROFESSIONALENTERPRISE
Tier-specific limits are managed by the backend quota policy configuration and surfaced through the snapshot endpoint.
AI runs and reservation behavior
AI runs use reservation semantics rather than optimistic post-hoc counting:
- reserve quota before calling the Python worker
- confirm the reservation on success
- cancel the reservation if the run fails
This prevents failed runs from silently consuming paid usage.