Added spend limits for organizations and projects, and noted the September 28, 2026, shutdown date for gpt-3.5-turbo-instruct.

Summary by gemma-4-12b. It may be wrong; the diff below is what actually changed. Raw: 4d56389c9d-openai-rate-limits.diff · commit 4d56389c9d

diff --git a/snapshots/openai/rate-limits.md b/snapshots/openai/rate-limits.mdindex 653162a..a7e544c 100644--- a/snapshots/openai/rate-limits.md+++ b/snapshots/openai/rate-limits.md@@ -43,4 +43,13 @@ You can view the rate and usage limits for your organization under the limits se To view a high-level summary of rate limits per model, visit the models page. +### Spend limits++Consider setting spend limits for your organization or projects to control monthly API spend. These controls are separate from the monthly usage limits above.++| Control | What happens at the configured amount | Use it when you want to |+|---|---|---|+| Spend alert | Sends a notification; API traffic continues | Track spend without interrupting traffic |+| Hard spend limit | Affected API requests return a `429` error | Enforce a monthly organization or project cap |+ ### Rate limits in headers @@ -131,4 +140,6 @@ This approach has many benefits: Note that unsuccessful requests contribute to your per-minute limit, so continuously resending a request won't work. +The legacy Completions examples below use `gpt-3.5-turbo-instruct`, which has a scheduled shutdown date of September 28, 2026. After that date, retain the retry pattern but migrate the request to Responses or Chat Completions with `gpt-5.6-terra`; changing the model ID in a Completions request is not sufficient.+ The Python examples below demonstrate fallback backoff. They don't inspect `Retry-After`: before using them, add handling for valid server hints so the wrappers don't retry sooner than requested. Disable SDK retries or account for them in your application's retry limits. @@ -345,5 +356,5 @@ Your rate limit is calculated as the maximum of `max_tokens` and the estimated n #### Batching requests -If your use case does not require immediate responses, you can use the Batch API to more easily submit and execute large collections of requests without impacting your synchronous request rate limits.+If your use case does not require immediate responses, you can use the Batch API to submit and execute large collections of requests without impacting your synchronous request rate limits.  For use cases that do requires synchronous responses, the OpenAI API has separate limits for requests per minute and tokens per minute.

← OpenAI timeline