> ## Documentation Index
> Fetch the complete documentation index at: https://docs.trylimitless.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Limits and spending controls

> Control request rate, concurrency, output bounds, and monthly spend.

Limits protect the workspace's balance and shared inference capacity. The values shown in your console are the configuration for your deployment; this page does not promise fixed subscription tiers.

## Requests and concurrency

The backend checks request rate and concurrent in-flight inference at workspace level. Multiple keys share the same workspace limits. Creating another key does not create more capacity.

| Control | What it limits | Rejection |
| - | - | - |
| Request rate | Admitted inference requests in the rolling time window. | `429` |
| Concurrency | Inference requests currently occupying a workspace slot. | `429` |
| Available credits | Funds available after existing reservations. | `402` |
| Monthly spend | Settled charges and relevant reservations against the configured cap. | `402` |

If `Retry-After` is present, wait at least that many seconds. Otherwise, back off with jitter and a bounded retry count. Avoid automatically replaying a stream that already produced content.

## Monthly spending cap

Owners and admins can select **Edit cap** on **Rate and spending limits**, enter an amount or choose no cap, and select **Save spending cap**. A `$0` cap blocks new billable requests; requests already admitted may finish.

The accounting month follows UTC calendar boundaries. The check includes charges finalized in the current month and all currently held reservations, including unresolved holds from earlier months. A top-up increases the wallet balance but does not increase the spending cap. Organization and per-project caps can also be managed through the [Administration API](/guides/administration). A project cap is checked alongside the shared organization cap. API cap setters accept positive amounts; the console can additionally set a zero organization cap to block new requests.

In-flight reservations are included in admission checks so simultaneous requests cannot all spend the same remaining allowance. A request can be blocked before its expected final cost would reach the cap because admission uses a conservative reservation.

## Output limits

Use `max_tokens` or `max_completion_tokens` for Chat, `max_output_tokens` for Responses, and `max_tokens` for Messages. Messages requires this field. Chat and Responses default to 1,024 tokens, or the configured model maximum if smaller. The maximum accepted bound comes from the model price configuration. Send only one output-bound field; conflicting fields are rejected.

The current configuration allows up to 262,134 output tokens for `abliterated-model` and 999,990 for either large model. These are request ceilings, not a guarantee that a response can reach that length. The input context, backend capacity, and gateway deadline still apply.

Chat accepts `n` from 1 to 128. Admission reserves the output allowance for every requested completion. Responses and Messages return one response. Model-specific context limits still apply independently of the gateway's 8 MiB HTTP body limit.

## Scope of protection

API and console playground inference share the workspace's balance and admission controls. Catalog reads do not generate inference usage. Separate upstream provider limits can still cause `429` or temporary unavailability even when your workspace has capacity.

See [errors](/errors) for the response format and [billing](/billing) for reservation behavior.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.