Codex web weekly allowance flips 58% → 16%; usage responses differ in account_id and report 42% vs 84% used #49349

Summary

On my ChatGPT Pro 20x subscription (USD 200/month), the Codex web usage dashboard repeatedly shows 58% remaining immediately after a reload or opening a new page, then automatically changes to 16% remaining after the page has been left open. Reloading restores 58%, and the cycle repeats.

Captured responses from GET /backend-api/wham/usage show two different weekly usage values. The response reporting 42% used has a populated account_id; the response reporting 84% used has an empty account_id.

This is a correlation in the captured responses, not a confirmed root cause. I have not yet verified whether the requests differ in their account-selection headers.

Environment

• Subscription: ChatGPT Pro 20x, USD 200/month
• Surface: Codex web usage dashboard, https://chatgpt.com/codex/cloud/settings/analytics#usage
• Browser/device: Chrome 152 on a Chromebook
• UI language: Swedish (sv-SE)
• Observed: September 29, 2026, approximately 20:00–20:39 CEST (18:00–18:39 UTC)
• The behavior was observed before opening DevTools. Some later diagnostic screenshots were taken with mobile emulation enabled.

Reproduction

1. Open or reload the usage dashboard.
2. Observe 58% weekly allowance remaining.
3. Leave the page open.
4. Observe the displayed allowance automatically change to 16%, without manually changing accounts or applying a reset.
5. Reload the page: 58% returns.
6. Inspect the usage requests in DevTools.

Earlier in the same observation period, the corresponding values were 59% and 18%.

Captured API evidence

The following excerpts omit user identity, credentials, and unrelated fields. The populated account ID has been replaced with a placeholder.

Response associated with 58% remaining:

{
  "account_id": "<redacted-nonempty-account-id>",
  "plan_type": "pro",
  "rate_limit": {
    "allowed": true,
    "limit_reached": false,
    "primary_window": {
      "used_percent": 42,
      "limit_window_seconds": 604800,
      "reset_after_seconds": 339877,
      "reset_at": 1791046910
    },
    "secondary_window": null
  },
  "credits": {
    "balance": "18.7907035000"
  }
}

Response associated with 16% remaining:

{
  "account_id": "",
  "plan_type": "pro",
  "rate_limit": {
    "allowed": true,
    "limit_reached": false,
    "primary_window": {
      "used_percent": 84,
      "limit_window_seconds": 604800,
      "reset_after_seconds": 340035,
      "reset_at": 1791046910
    },
    "secondary_window": null
  },
  "credits": {
    "balance": "18.7907035000"
  }
}

Both responses identify the same user (identity omitted), report plan_type: "pro", and have the same weekly window length, reset timestamp, and credit balance. The difference in reset_after_seconds reflects that the captures were taken at different times.

The reset time displayed in the UI remains October 3, 2026, 19:01 CEST.

Expected behavior

Initial loading and subsequent automatic updates should use consistent account context and report a consistent weekly allowance for the subscription.

Actual behavior and impact

The reported used percentage switches between 42% and 84%, producing 58% versus 16% remaining. The earlier UI pair of 59% versus 18% remaining also corresponds mathematically to 41% versus 82% used; API captures for that earlier pair are not included.

This makes it impossible to reliably plan work against the remaining allowance. I have not established which value governs actual usage enforcement, or that the subscription has been downgraded. Both captured responses still permit usage.

Requested investigation

Please investigate:

• Why the usage responses alternate between a populated and empty account_id.
• Whether initial loading and background updates send or resolve different account context.
• Why the reported weekly used percentage differs by exactly a factor of two.
• Which allowance and account context actually govern usage enforcement for this Pro 20x subscription.

Related reports

• Weekly Codex quota oscillates between two different reset windows (Sep 15 ↔ Sep 12) with large usage jumps #44251 — weekly quota oscillating between different states, documented in server response headers.
• [Usage accounting] 5-hour and weekly quota state changed together, then reverted (39% → 75% → 38%; Sep 15 → Sep 14 → Sep 15) #44245 — quota state changing and then reverting.

These reports have similar symptoms, but their reset timestamps also change. In my captures, the reset timestamp remains identical. I am not claiming a shared root cause.

Only sanitized response excerpts are included here; no authorization headers, cookies, or cURL exports are attached.