Skip to main content
Quotas cap how much your organization may spend, and how many tokens it may use, in one quota period. They are separate from credit: credit is what you have paid for, a quota is what you are allowed to use. This page is for anyone who needs to know why a run got 429, how much room is left this period, and how to keep a pipeline inside its limits.

The three limits

  • The quota period is the current UTC calendar month, from the first of the month at 00:00:00Z to the first of the next month at 00:00:00Z. Consumption starts again from zero when the next period begins.
  • The per-request ceiling is what every run holds while it is in flight. It is at most 20,000 micros and can be set lower, never higher.
  • Every amount is an integer in micro-USD: 1,000,000 micros is 1 US dollar.
There is no request-rate limit. A 429 from OpenType is always one of the quota refusals on this page.

Read your quota

GET /v1/quota takes no parameters and needs the usage_read scope.
Spend counts against the limit as the larger of settled and reserved spend. Runs in flight hold their ceiling, so they count against the limit before they settle. That stops a burst of concurrent runs from overshooting it.

The two refusals

POST /v1/runs checks quota after it validates the request and before it checks credit. A refusal is a 429 with one of two codes.

organization_spend_quota_exhausted

The run’s per-request ceiling, not its likely cost, is compared with remaining_spend_micros:
A run that would settle at 19 micros is still refused when fewer than 20,000 micros of the period’s limit remain (with the default ceiling). In practice, once less than one ceiling of the limit is left, no further run is admitted that period.

organization_token_quota_exhausted

The run’s token estimate is compared with remaining_tokens:
The input estimate is the request’s prompt bytes divided by 4, rounded up, plus its question set (or schema) bytes divided by 4, rounded up. max_output_tokens counts in full, whether or not the model uses it.
A lower max_output_tokens can get a run under the remaining token allowance. A decision run’s answers are short, so set max_output_tokens close to what the answers need, not to a large default.

What a refusal leaves behind

  • Nothing is created or charged. The refusal happens before a run exists.
  • The Idempotency-Key stays free. Retry with the same key and the same body later.
  • A replay is never refused. If the key already owns a run, you get that run back without a quota check.
  • Branch on the code. It tells you which limit refused the run; the table below says what to do.

What to do

Do not retry a 429 in a tight loop. Back off, or better, read GET /v1/quota and wait until there is room. See the retry policy in Error handling.

Quota, credit and size limits compared

Watch it before it bites

  • Poll GET /v1/quota on a schedule and alert when remaining_spend_micros or remaining_tokens falls below what a normal day uses. Read a normal day from GET /v1/usage/daily.
  • Keep max_output_tokens tight on every run. It counts in full against the token limit at admission.
  • Limit how many runs you have in flight at once. Each one holds up to 20,000 micros of the period’s spend until it settles.