Bug Report: Global Rate Limit Exhaustion (4000 RPM) for `gpt-image-2-codex` Affecting Most Image Requests

Subject: gpt-image-2-codex returning 200 OK with Rate Limit Error for the vast majority of image requests due to shared 4000 RPM limit

Description:
There is a critical issue affecting Codex accounts (including Plus and Pro 20 tiers) when attempting to generate images using image-2 via Codex. Since yesterday, the vast majority of image generation requests have been failing due to a continuous rate limit error.

The API returns an HTTP status code 200 OK, but the response body contains a rate limit error message indicating that the input-images per min limit has been fully exhausted (4000/4000 used). It appears that the 4000 RPM limit is being globally shared or incorrectly pooled across user accounts in the organization. This causes a persistent bottleneck, blocking most users from successfully generating images.

Error Message / Log Output:

Rate limit reached for gpt-image-2-codex (for limit gpt-image) in organization org-BOvpEHVcDPTe8h4lZnwMO5Ly on input-images per min: Limit 4000, Used 4000, Requested 1. Please try again in 15ms. Visit [https://platform.openai.com/account/rate-limits](https://platform.openai.com/account/rate-limits) to learn more.

Environment / Context:

  • Affected Service/Model: gpt-image-2-codex (image-2 via Codex)

  • Account Tiers Affected: Multiple tiers (including Plus and Pro 20)

  • Organization ID mentioned in error: org-BOvpEHVcDPTe8h4lZnwMO5Ly

  • HTTP Status Code: 200 OK (Expected a 429 status code for rate limits, but it returns 200 with the error payload instead)

  • Time of Occurrence: Ongoing since yesterday

Steps to Reproduce:

  1. Use a Codex account (Plus or Pro 20) to initiate an image generation request using image-2.

  2. Observe the network response.

  3. For most attempts, the request completes with an HTTP 200 status but fails to generate the image, returning the “Rate limit reached… Limit 4000, Used 4000” error message.

Expected Behavior:

  1. Individual user limits should be isolated, or the organization-wide limit should not be constantly maxed out at 4000/4000 by shared traffic.

  2. If a rate limit is actually triggered, the API should return a proper HTTP 429 Too Many Requests status code instead of an HTTP 200 OK.

I am getting the exact same issue.
This has to be handled.

Worth noting that the web version actually works (not rate limited, for the same account) which confirms the bug further.

Hitting the same wall here, and the 200 OK part is what threw me off the most initially. Spent a good hour thinking my code was broken before realizing the response body itself had the rate limit error buried inside a successful looking status code.
The org-wide pooling theory checks out on my end too. Multiple people on my team using different API keys under the same org are all getting maxed out around the same time, which wouldn’t make sense if limits were actually per-key or per-user like they’re supposed to be for other models.
Also confirming the web version workaround mentioned above, ChatGPT’s own image gen through the web UI isn’t affected at all, only requests going through the Codex/API path hit this. So it’s pretty clearly something on the backend pooling side rather than an actual capacity issue, since the same account can generate images fine through one path and get blocked on the other.
Would really help if OpenAI could at least fix the status code in the meantime, even if the underlying limit issue takes longer to sort out. A proper 429 would let people build retry logic around it instead of silently failing requests that look successful on the surface.