Codex: wham/usage reports 0% while the model-level weekly limit is exhausted (plan_type: prolite)

[JefSantiago]

Summary

On a prolite plan, the live read (chatgpt.com/backend-api/wham/usage) reports 0% used while the account is actually rate-limited. The notch shows "0% Used · 100% left" for a weekly window that is fully consumed.

Windows 11, Codenotch v1.15.0.

Live endpoint response

"plan_type": "prolite",
"rate_limit": {
  "allowed": true,
  "limit_reached": false,
  "primary_window": { "used_percent": 0, "limit_window_seconds": 604800 },
  "secondary_window": null
}

Rollout log (the real numbers)

"limit_name": "GPT-5.3-Codex-Spark",
"primary": { "used_percent": 0.0, "window_minutes": 300 },
"secondary": { "used_percent": 100.0, "window_minutes": 10080 }

The limit that actually blocks the user is model-level (GPT-5.3-Codex-Spark) and is not represented in the live payload. Because the live path takes priority, the correct value from the rollout is discarded.

Suggestion

When the live response has secondary_window: null but a recent rollout carries a secondary window, prefer the rollout value (or surface both). Optionally also display credits.balance.

Side note

With an HTTPS-inspecting antivirus (Kaspersky), the live read fails with invalid peer certificate: UnknownIssuer because ureq/rustls uses bundled roots instead of the Windows certificate store. rustls-platform-verifier would fix that.

[dinicleyaguiar]

I’d like to take this one.

I traced the Windows Codex path in codex.rs:
ead_once() returns as soon as wham/usage yields any window, so a partial live response never gets a chance to use the rollout data even when the live secondary_window is missing.

My proposed fix is deliberately narrow:

• keep the live wham/usage reading as the source of truth for every window it actually returns;
• only when the live secondary window is absent, look at the newest recent rollout snapshot for the missing weekly/model-level window;
• do not replace a live primary/secondary value that exists;
• preserve the rollout window's model/bucket identity (for example Spark) rather than silently presenting a model-level limit as the account-wide Codex limit;
• ignore stale or malformed rollout data instead of letting it override a fresh live reading.

I’d add regression coverage for the prolite shape from this issue: live primary at 0%, live secondary
ull, rollout weekly/model limit at 100%, plus tests that an existing live secondary still wins and that stale/malformed rollout data is not merged.

If that shape matches what you want surfaced in the UI, I can send the implementation as a small Windows-only PR.