Setup: codexbar 0.48.0, Windows 11, Claude Max 5x, OAuth source.
The exact-100% symptom from #210 (fixed for the all-models weekly lane in 0.48.0) appeared today on the session (5h) window. Timeline, all times UTC on 2026-08-13:
- 04:53Z — session window read 98%,
resets_at 07:50Z. This was genuine (a CLI session really did hit the limit).
- 07:50Z — window reset; a new session window anchored shortly after (
resets_at 2026-08-13T12:49:59Z).
- 08:14Z —
usage --provider both --json returned used_percent: 100.0 for the session window, minutes into the fresh window.
- 08:15Z — claude.ai/settings/usage showed Current session: 5% used, resets in 4h 31m. Note it agreed on the reset time — only the percentage differed.
- 08:50Z — a fresh CLI call returned
used_percent: 10.0 (plausible). So the bogus reading is transient and self-corrects.
08:50Z raw output (bug no longer showing):
{"primary":{"is_informational":false,"reset_description":"Aug 13 at 12:50PM","resets_at":"2026-08-13T12:50:00.181641Z","used_percent":10.0,"window_minutes":300}}The 08:14Z reading was captured through a thin wrapper that camelCases the CLI JSON (values verbatim): {"usedPercent":100,"resetDescription":"Aug 13 at 12:49PM","resetsAt":"2026-08-13T12:49:59.578826Z","windowMinutes":300}
Given the #210 root cause (stale legacy seven_day.utilization reporting 1.0 while the truth lived in limits[]), this looks like the same pattern on the session lane — a stale five_hour-style utilization field winning over the fresh limits[] value, transiently, right after a window rollover.
Setup: codexbar 0.48.0, Windows 11, Claude Max 5x, OAuth source.
The exact-100% symptom from #210 (fixed for the all-models weekly lane in 0.48.0) appeared today on the session (5h) window. Timeline, all times UTC on 2026-08-13:
resets_at 07:50Z. This was genuine (a CLI session really did hit the limit).resets_at 2026-08-13T12:49:59Z).usage --provider both --jsonreturnedused_percent: 100.0for the session window, minutes into the fresh window.used_percent: 10.0(plausible). So the bogus reading is transient and self-corrects.08:50Z raw output (bug no longer showing):
{"primary":{"is_informational":false,"reset_description":"Aug 13 at 12:50PM","resets_at":"2026-08-13T12:50:00.181641Z","used_percent":10.0,"window_minutes":300}}The 08:14Z reading was captured through a thin wrapper that camelCases the CLI JSON (values verbatim):
{"usedPercent":100,"resetDescription":"Aug 13 at 12:49PM","resetsAt":"2026-08-13T12:49:59.578826Z","windowMinutes":300}Given the #210 root cause (stale legacy
seven_day.utilizationreporting1.0while the truth lived inlimits[]), this looks like the same pattern on the session lane — a stalefive_hour-style utilization field winning over the freshlimits[]value, transiently, right after a window rollover.