›_ Codex Issues
Codex Issues / #37934

429 Too Many Requests on /backend-api/wham/rate-limit-reset-credits blocks reset-credits UI in both desktop app and web (Pro)

Open 💬 4 comments Opened Aug 11, 2026 by Suhaibinator
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From "About Codex" dialog)?

Version 26.803.61601 (Released Aug 8, 2026) — "Powered by Codex & OWL"

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

GET https://chatgpt.com/backend-api/wham/rate-limit-reset-credits is returning 429 Too Many Requests, and this reproduces in both the desktop Codex app and the web app on the same account.

The consequences in the UI:

  1. The reset-credits UI never loads — the credits/usage panel fails to populate because the request that backs it is rejected.
  2. Reset credits cannot be redeemed/applied — the action that depends on this endpoint fails.
  3. 429 retry loop — the client keeps re-issuing the request rather than backing off, so the failure repeats continuously instead of surfacing once.

Failing request details:

Request URL:     https://chatgpt.com/backend-api/wham/rate-limit-reset-credits
Request Method:  GET
Status Code:     429 Too Many Requests
Remote Address:  172.64.155.209:443
Referrer Policy: strict-origin-when-cross-origin
x-oai-request-id: 830faf4a-fa22-4941-98f7-231bdf217d8f

Notably this is a read endpoint for reset credits, so a 429 here blocks visibility into credits rather than throttling any expensive operation.

What steps can reproduce the bug?

  1. Sign in to a ChatGPT Pro account.
  2. Open the Codex desktop app (v26.803.61601) or go to the Codex web app at chatgpt.com.
  3. Open the view that displays reset credits / usage limits.
  4. Observe in DevTools (web) or the network log that GET /backend-api/wham/rate-limit-reset-credits returns 429, the credits UI does not load, and the request is retried repeatedly.

Reference request id: 830faf4a-fa22-4941-98f7-231bdf217d8f

What is the expected behavior?

  • GET /backend-api/wham/rate-limit-reset-credits should return the account's reset-credit state for a Pro account rather than 429.
  • If the endpoint genuinely must rate limit, the client should honor Retry-After and back off instead of looping, and should surface a clear, actionable error rather than an empty/stuck credits panel.

Additional information

  • Reproduces on both surfaces (desktop app and web), which suggests the problem is server-side on the endpoint rather than in a single client.
  • Possibly related existing reports about reset-credit/usage accounting: #37455, #37250, #30456, #30726.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 17 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #37928

Powered by Codex Action

Jack-wenxie · 17 days ago

Additional Windows reproduction on the current app build:

  • Windows x64; Codex app UI version 26.803.81509 (MSIX package 26.803.10989.0); ChatGPT Pro.
  • At 13:22 UTC+8, the profile menu successfully showed 1 available reset. About 15 minutes later, the row disappeared even though no reset had been used.
  • At approximately 13:37 UTC+8, four consecutive GET /wham/rate-limit-reset-credits attempts all returned HTTP 429 with connector_rate_limit / Connector rate limit exceeded. No POST /wham/rate-limit-reset-credits/consume was made.
  • A read-only account/rateLimits/read call still returned the ordinary rateLimits payload, while rateLimitResetCredits was null.
  • In the desktop bundle, the menu count is normalized through rate_limit_reset_credits?.available_count ?? 0, and the menu row is rendered only when the resulting count is greater than zero. Consequently, a missing field or fetch error becomes indistinguishable from a confirmed zero balance, so the emergency reset entry silently disappears.

This has operational impact: a user cannot reliably tell whether a banked reset is available when the normal usage limit is reached.

Requested behavior:

  1. Keep a fixed Usage & resets entry visible.
  2. Represent loading, fresh value, stale last-known value, confirmed zero, and error as distinct states.
  3. Retain the last-known-good count with its observation timestamp when refresh fails.
  4. Honor Retry-After and avoid the current rapid retry/refetch amplification.
  5. Add structured diagnostics for fetch failure, missing fields, and the final render decision.

This comment intentionally omits account identifiers, request IDs, local paths, screenshots, and raw logs.

Sgt-Friedrich · 17 days ago

Additional sanitized reproduction from a ChatGPT Plus account:

  • Platform: Windows 11 x64, build 26200
  • Codex MSIX package: 26.803.10989.0
  • App-server client version reported in the desktop log: 26.803.81509
  • Subscription: ChatGPT Plus

After restarting the desktop app, the following read request continued to return HTTP 429:

GET /backend-api/wham/rate-limit-reset-credits
HTTP 429
{"detail":{"type":"connector_rate_limit","message":"Connector rate limit exceeded"}}

The failure was observed repeatedly at approximately 2026-08-11 05:28, 06:02, 06:46, and 07:08 UTC. A direct read of the same endpoint reproduced the 429 response.

The main Codex rate-limit data still loaded successfully and reported:

  • plan type: plus
  • weekly window: 10080 minutes
  • usage: approximately 22%
  • reset time: 2026-08-18 03:00:15 UTC

This indicates that the account/rate-limit payload is available while the reset-credit subresource is unavailable. The desktop UI therefore cannot distinguish between ?no reset credits?, ?data unavailable?, and ?request rate-limited?, and the reset-credit section remains unavailable/loading.

No account identifiers, authentication data, local paths, screenshots, or raw logs are included here.

Dong-Fang-Bu-Bai · 17 days ago

Additional independent Windows reproduction:

  • Windows 24H2, build 26100.8037
  • Codex MSIX package 26.803.10989.0
  • Both Codex desktop and the Codex web usage page fail to load the Usage limit resets section, while the ordinary weekly usage row still loads normally.
  • A single read-only GET /backend-api/wham/rate-limit-reset-credits at 2026-08-11 16:18:15 UTC+8 returned HTTP 429 with connector_rate_limit / Connector rate limit exceeded. No retry was performed and no consume POST was sent.
  • The affected account previously showed one Full Reset expiring on August 13, 2026, so the outage prevents the user from verifying or accessing it before expiry.

This independently confirms that the reset-credit subresource can fail while ordinary usage data remains available, and that the same account is affected on both desktop and web. Please preserve or restore resets that expire while this service-side failure is unresolved.

Account identifiers, authentication data, credit IDs, request IDs, and local paths are intentionally omitted.