This guide explains request limits in the development app. Your effective limits can differ from the defaults below.
Check the admission limits that apply to your inference requests. These controls determine whether a request can proceed; they are not an invoice.
Platform defaults
| Dimension | Default |
|---|---|
| Requests per minute | 120 |
| Requests per day | 25,000 |
| Tokens per day | 10,000,000 |
| Monthly spend cap | $250 |
| Request payload ceiling | 1,048,576 bytes |
The default policy is enabled. An account-specific policy can override every dimension, so your effective limits may differ from this table.
Read your effective policy
The authenticated account can read its own policy at GET /me/limit-policy.
| Response value | Meaning |
|---|---|
source: platform_default | No account-specific policy row exists; the platform defaults apply. |
source: tenant_policy | An account-specific policy applies. |
| A null token or spend cap | That dimension is unlimited. |
GET /me/limit-policy is a relative API path. To use this endpoint, you need the customer API base URL and authentication details. The development app does not expose a limits panel yet. Until you can call this endpoint, do not assume the defaults are your effective policy.
Respond to a limit error
Limit checks happen after authentication and before a provider call. An admission rejection does not create a provider-loss measurement.
| Response | Reason | Supported response |
|---|---|---|
413 | payload_too_large | The oversized payload cannot be retried unchanged. Keep the request within the effective payload ceiling. |
429 | rate_limited | Retry after the limit resets. |
429 | quota_exceeded | Retry after the quota resets. |
429 | spend_cap_exceeded | Retry after the spend cap resets. |
503 | policy_unavailable | The effective policy could not be read or validated, so no provider was called. Wait for Retry-After before trying again; contact support if the failure persists. |
Every JSON error includes code and message. Limit rejections (413 or 429) also include reason and limitType, and can include limit, used and resetAt. A Retry-After header is set when available; use the supplied reset information for the retry. A policy-read failure (503) supplies Retry-After: 1 and does not include limit or usage fields.
If neither resetAt nor Retry-After is present, do not loop the same request. Use limitType to identify whether the minute, day, token, or monthly spend window was exceeded, wait for that window to reset, and then try once.
If the needed limit is not documented
Support and contact explains how to get help with limits.
Continue
- Inferock Watch
- Inferock Serve
- Inference pricing
- Support and contact