Concepts
Rate Limits and Quotas
How request limits, token scopes, and dynamic quota policies work.
TENSORAXIS rate limits and quotas are determined by deployment configuration, user groups, and token scopes. Exact values can vary by account, group, model, and operations policy, so this documentation does not hard-code RPM, TPM, RPD, or pricing values.
Limits That May Affect Requests
| Limit Type | Description |
|---|---|
| Token scope | Tokens can be scoped by model, group, IP, quota, and rate policy |
| Account quota | Requests can fail when balance, subscription quota, or granted quota is insufficient |
| Model/group limits | Deployments can enforce request windows by user and group, including successful request counts and optional total request counts |
| Upstream limits | Upstream providers may also return rate-limit or capacity errors |
When You Hit a Limit
Rate-limit failures usually return 429. Clients should:
- Retry with exponential backoff, such as 1s, 2s, 4s, and 8s.
- Control concurrency so multiple workers do not exhaust the same token at once.
- For asynchronous video tasks, rate-limit both task submission and polling.
- Avoid infinite retries on failed requests; log the response body and investigate repeated failures.
Finding the Real Limits
Actual limits come from the console and the current deployment configuration:
- Use the Tokens page to view or configure token-level access.
- Use the model plaza for current model availability and pricing.
- Enterprise or private deployments may use administrator-managed rate-limit policies.
Demo data shown in the console or model detail pages is not an API contract. For production integrations, rely on token settings, account quota, and actual server responses.