OpenAI API Rate Limits: GPT-6 Astra Tiers and 429/503 Recovery

GPT-6 Astra now has published API rate limits, but the largest number in its table is not necessarily the capacity available to your API key. A successful diagnosis has three parts: confirm that the key has access to gpt-6-astra, read the effective organization and project limits, and classify the failed response before retrying it.

That distinction matters because several unrelated conditions can block the same workload. Ordinary RPM or TPM exhaustion, a ramp-rate 429 slow_down, billing restrictions, and a temporary 503 server_is_overloaded each require a different response. ChatGPT Work and Codex allowances are a separate product boundary again; they do not define Platform API throughput.

GPT-6 Astra's published Standard limits

OpenAI's GPT-6 Astra model page publishes the following high-level limits for Standard API processing:

Treat this as a published ceiling for capacity planning, not a promise to a particular key. API limits apply at organization and project scope, models may have different limits, and some model families may share capacity. The OpenAI rate-limit guide directs operators to the Platform Limits page for their current values. The public Astra page does not say that its capacity is always dedicated or that every eligible account already has access.

The Batch column is also easy to misread. It counts the input tokens in all pending Batch jobs for the model, not the number of jobs, requests, or tokens allowed per day. When a job finishes, its input tokens stop occupying that model's queue allowance. A Tier 1 project submitting 50,000 input tokens per job would therefore fill a 1,500,000-token queue with roughly 30 such pending jobs, not 1.5 million jobs.

The checked public pages do not publish an Astra-specific RPD, TPD, concurrent-request ceiling, or separate long-context RPM/TPM table. That is a disclosure boundary, not proof that no internal or account-specific constraint exists. Do not infer concurrency from RPM, TPM, context length, or Batch capacity.

Confirm access before treating the problem as a rate limit

The API changelog records GPT-6 Astra's API release on September 3, 2026, while the contemporaneous rollout language says access for API and several ChatGPT plans is arriving over the following days. Those statements can both be true: a model can be released while entitlement is still reaching individual accounts. See the OpenAI API changelog and the current model page for the two sides of that status.

As a result, a visible documentation page does not prove that your organization can call the model. Neither does seeing Astra in a ChatGPT workspace or local client. Before tuning traffic, verify all of the following:

1. The request uses the intended API key, organization, project, endpoint, and exact model ID gpt-6-astra.
2. The Platform Limits page for that organization and project shows the model and its effective limits.
3. A direct request from that project succeeds, or its response identifies the actual access problem.

If the model is absent or the key is not entitled during rollout, exponential backoff cannot create access. Rotating keys inside the same organization is not a capacity strategy either. Resolve the account or project assignment first. Our organization and project setup guide covers that scope boundary in more detail.

Use the Limits page and response headers as the live truth

The public tier table answers, “What does OpenAI currently publish for this model and tier?” The Platform Limits page and the headers on your requests answer, “What can this request path use now?” Keep both in the incident record.

OpenAI documents these core headers:

• x-ratelimit-limit-requests
• x-ratelimit-remaining-requests
• x-ratelimit-reset-requests
• x-ratelimit-limit-tokens
• x-ratelimit-remaining-tokens
• x-ratelimit-reset-tokens

Applicable responses may also include project-token variants. Log every returned x-ratelimit-* header rather than assuming the six common fields are the complete set. Also retain Retry-After when present. The examples in the documentation illustrate the header format; their numeric values are not fixed Astra limits.

For each failed call, capture the timestamp, HTTP status, error.type, error.code, model, endpoint, organization or project context, Retry-After, and all remaining/reset values. That record usually separates the common cases quickly:

Limits are not user-level buckets, so adding another user or API key does not necessarily create another allowance. A wrapper or gateway may impose an additional limit of its own, but that does not change which organization and project OpenAI evaluates underneath.

Classify 429 and 503 before choosing recovery

OpenAI's rapid-traffic and overload guidance makes an operational distinction that generic “rate limit” messages often hide.

Ordinary request or token exhaustion

An ordinary 429 can mean the request path has exhausted RPM or TPM for the current window. Request pressure usually comes from concurrency, tight loops, fan-out, or retries that align on the same boundary. Token pressure can arrive with far fewer calls when prompts, retrieved context, or expected outputs are large.

Use the remaining and reset headers to determine which dimension is tight. Waiting is appropriate for a short-lived window. For a sustained load, smooth admission, cap concurrency, and reduce token demand before requesting more capacity. Buying credits does not by itself raise RPM or TPM.

429 rate_limit_error / slow_down

slow_down is a ramp-rate branch. It can appear even when the minute-level request and token counters still show room, because traffic reached the service too abruptly. Honor a valid Retry-After, lower the arrival rate, and bring traffic back gradually. Simply widening the worker pool or sending the same burst from more keys makes the traffic shape worse.

This is also why averages can mislead. Being below a calculated per-minute total does not prove that a sharp burst is acceptable. Admission control should smooth the requests before they reach the API, not rely on a retry storm to smooth them afterward.

Billing, spend, and usage restrictions

Some 429 responses describe account state rather than a recoverable rate window. If the error body points to exhausted credits or an organization/project spend or usage limit, follow that account action. Waiting for a reset or increasing backoff will not repair billing. The OpenAI spend-limit guide is the relevant first-party path for those cases.

503 service_unavailable_error / server_is_overloaded

server_is_overloaded is documented as HTTP 503, not 429. It means temporary model-side capacity is unavailable. Honor Retry-After; if none is returned, use a longer bounded backoff with jitter. When the condition persists, check the OpenAI status page and decide whether the job can wait.

Do not treat a fallback model as an automatic retry. A fallback can change behavior, cost, latency, context handling, or output quality. Use one only when the application has already approved and tested that change. The retry-versus-fallback guide helps make that policy explicit.

Make retries quieter, bounded, and error-aware

Retry-After takes priority when it is valid. Without it, exponential backoff with jitter prevents many clients from returning at the same instant. Both branches also need a maximum attempt count or elapsed-time budget.

This small TypeScript helper handles either a numeric delay in seconds or an HTTP date, then falls back to capped exponential delay:

ts
function retryAfterMs(value: string | null): number | null {
  if (!value) return null;

  const seconds = Number(value);
  if (Number.isFinite(seconds)) return Math.max(0, seconds * 1000);

  const at = Date.parse(value);
  return Number.isNaN(at) ? null : Math.max(0, at - Date.now());
}

function nextDelayMs(attempt: number, header: string | null): number {
  const instructed = retryAfterMs(header);
  if (instructed !== null) return instructed;

  const capped = Math.min(30_000, 750 * 2 ** attempt);
  return capped * (0.75 + Math.random() * 0.5);
}

Call the retry path only for an error the application has classified as temporary. Stop and surface the problem for billing, spend, entitlement, invalid input, or a wrong project. Coordinate SDK, gateway, queue, and application retries so one original call cannot multiply into several independent loops.

Traffic recovery should normally proceed in this order:

1. Respect the server's reset or retry instruction.
2. Lower concurrency and smooth new admissions.
3. Reduce unnecessary prompt context and expected output when TPM is tight.
4. Queue non-urgent work instead of holding synchronous workers open.
5. Move eligible asynchronous work to Batch.
6. Request a higher account limit only after the traffic shape and request scope are correct.

Plan Astra capacity with the first binding constraint

RPM and TPM constrain the same stream from different directions. A useful planning estimate is:

text
token-bound requests/minute = effective TPM / tokens counted per request
sustainable requests/minute <= min(effective RPM, token-bound requests/minute)

Use the effective values from your account, not automatically the public table, and leave operational headroom for variation. For example, the public Tier 2 table lists 5,000 RPM and 1,000,000 TPM. At an average of 2,000 limit-counted tokens per request, the token side reaches about 500 requests per minute before any safety margin—one tenth of the published RPM. Optimizing request count alone would miss the real bottleneck.

Batch has a different admission constraint. Add the input tokens of all pending jobs for gpt-6-astra and compare that total with the effective queue limit. A finished job releases its contribution. Splitting the same pending input across more Batch jobs does not create more queue capacity.

Long context changes cost and pressure, not the published table

The model page lists a 1,050,000-token context window, up to 922,000 input tokens, and up to 128,000 output tokens. It also states that requests above 272K input tokens use 2× input/cache pricing and 1.5× output pricing for the whole request. The 272K threshold is a pricing boundary; it is not the context limit, maximum input, TPM allowance, or a separate published rate limit.

Large requests can still consume TPM quickly. OpenAI's general rate-limit guide notes that long-context models may have separate limits in the developer console, but the checked Astra public pages do not publish an Astra-specific long-context RPM or TPM value. Check your Limits page rather than deriving one from the context window or pricing multiplier.

Fast mode does not create another rate-limit pool

OpenAI's Fast mode guide says Standard and Fast processing for the same model share a rate limit, and Fast traffic remains subject to ramp-rate controls. For Astra API usage, Fast costs 2× the corresponding Standard token rate; it does not buy 2× RPM or TPM. Astra Fast also has no latency SLA and does not support EU data residency. Those restrictions can make Fast unsuitable even when the account can select it.

Keep Platform API limits separate from ChatGPT Work and Codex

An API key and a ChatGPT sign-in can reach related model experiences through different entitlement and billing systems. Access in one does not grant access in the other.

For the Platform API, gpt-6-astra usage is metered through the API organization/project and constrained by its RPM, TPM, Batch, billing, and rollout state. For ChatGPT Work and Codex used with a ChatGPT identity, Astra consumes a shared plan allowance. The official Work and Codex pricing page gives these estimated local-message ranges per five hours:

These are estimates, not fixed message caps, API RPM/TPM, or the ordinary Chat message limit. Local messages and cloud chats share the allowance, weekly limits may also apply, and consumption varies with context, reasoning, tools, retrieval, and caching.

The same page lists Astra Work/Codex token rates of 250 credits per million input tokens, 25 per million cached input tokens, and 1,250 per million output tokens. Fast uses 2.5× the Standard credit amount in that product. Do not mix those credits with API dollar pricing: API Fast is documented as 2× the Standard API token rate, while Work/Codex Fast consumes 2.5× Standard credits.

Enterprise has another rollout gate. During Astra's initial Enterprise rollout, eligible workspaces need Daybreak access, and the model is initially off by default; an administrator can enable it for users or groups in Chat, Work, and Codex. The workspace availability documentation also states that workspace enablement does not grant API access. Early API access may require configuration from the OpenAI account team.

So a five-hour Work/Codex estimate cannot explain an API 429, and an API Tier 5 table cannot explain why a ChatGPT workspace stopped accepting work. Use OpenAI Codex usage limits for the signed-in product allowance and Codex API key vs subscription when choosing the authentication and billing path.

An operator's sequence for the next failure

When an Astra request fails, work from the response outward:

1. Confirm product and access. Is this a Platform API call from the intended organization/project, and does that project currently have gpt-6-astra access?
2. Record effective capacity. Compare the Limits page with the public Standard table; do not substitute one for the other.
3. Read the response. Capture status, type, code, Retry-After, and all returned rate-limit headers.
4. Name the binding constraint. Separate RPM, TPM, ramp rate, billing/usage state, entitlement, and temporary service capacity.
5. Apply the smallest matching action. Wait, smooth traffic, trim tokens, repair account state, or queue the work.
6. Escalate with measurements. Request higher limits only when the current project, traffic shape, average token demand, and failed dimension are known.

This sequence remains useful after Astra's launch numbers change. The public table sets expectations; the Limits page and response headers describe the request path you actually operate. The error branch determines whether retrying is recovery or merely more load.