Rate limits

Rate limits scale with your tier, and they exist for one reason: to keep latency predictable for everyone on shared CPU infrastructure. We apply them per account, per minute, across all services. A chained run counts as one request.

Reading the headers

Every response carries the current window state:

X-RateLimit-Limit: 600
X-RateLimit-Remaining: 598
X-RateLimit-Reset: 1725192000

Handling 429

When the window is exhausted, Chersus returns 429 with a Retry-After header in seconds. Back off and retry once the window resets. Chersus never bills a request it rejects for rate limiting.

{
  "error": {
    "code": "rate_limited",
    "message": "Too many requests. Retry after 3 seconds."
  }
}

Queue work client-side with a token bucket rather than retrying in a tight loop. For batch jobs, chain services so one request does the work of several.

rate_limited sits alongside every other error in errors, which covers what bills and what does not.

Retries and idempotency

Send an Idempotency-Key header with a unique value per logical request whenever a retry is possible. Chersus keeps the key and the resulting trace_id for 24 hours, with no content. A repeat with the same key returns status: "duplicate" and the original trace_id. It runs nothing, bills nothing, and your client keeps the first response.

Other limits

A single run accepts at most 100,000 characters of input. The validator rejects larger inputs before anything runs or bills. Region is an account setting, not a request field; the audit trace records the region that served each run.

Raising limits

Limits rise automatically with your monthly character tier. On the Corporate or Volume tier and need dedicated throughput, or a single-tenant European cluster? Ask about reserved capacity.