Weekly quota window is recomputed to a rolling 7-days-from-now anchor, and a reset restores only a fraction of the window

Start by inspecting the local rollout files and the rate_limits and token_count fields described in the report, then compare the related issues #35952, #36307, #34066, and #31601. Check whether the reset anchors, window capacity, and reset-credit visibility can be reproduced from the CLI's existing telemetry. Done means the affected behavior is localized and the expected reset and accounting behavior is clearly established.

Plan: Pro. Client: Codex CLI. Period: 2026-07-20 to 2026-07-31.

All values below are read from the rate_limits block and the token_count
events the CLI writes to its own rollout files on every turn
(used_percent, window_minutes, resets_at, plan_type,
info.total_token_usage). Counts are from my local files only.

Nine weekly windows in one week

My primary account reported NINE distinct weekly reset anchors in a single
week, all with window_minutes = 10080. Each anchor I can test falls
exactly 7 days after a moment I was actively using Codex, to the minute:

reset Aug 5 05:30Z = my activity Jul 29 05:30Z + 7d
reset Aug 5 19:07Z = my activity Jul 29 19:07Z + 7d
reset Aug 6 13:10Z = my activity Jul 30 13:10Z + 7d

That is a window recomputed as "now + 7 days", not one anchored to the start
of a billing period — the mechanism described in #35952. Three windows whose
resets_at was already in the past kept accumulating usage to 100% instead
of rolling over.

A reset does not restore a full window

This is the part I could not see from the UI, and it is measurable from the
client's own telemetry. Each token_count event carries the session's
cumulative token counter AND the window's used_percent. Summing each
session's own consumption over a window, and dividing by how far the
percentage actually travelled, gives how many tokens a full 0→100% window
holds.

Four windows on the same account, same plan, same week, each observed across
its entire 0→100% span (no extrapolation):

window opened Jul 23  ->  236,664,271,653 tokens to fill
window opened Jul 25  ->  239,521,232,281 tokens to fill
window opened Jul 29  ->  106,815,111,514 tokens to fill
window opened Jul 29  ->   91,165,406,177 tokens to fill

The two windows opened after the reset cascade began hold roughly 2.4x
less than the two before it. Nothing in the UI communicates this: both
report the same window_minutes, both display as a full bar, and both count
as "a reset". Empirically I work until exhaustion every cycle, so I noticed
the working time per window collapsing; the numbers above are what that
looks like in the telemetry.

Caveats, stated so they can be checked: this assumes the percentage moved
only from this machine's usage, the token counter includes cached input, and
I excluded three further windows whose percentage span was partial and would
have required extrapolation.

Timeline

Jul 20   1 usage_limit_exceeded   (first of the month, on my largest usage day so far)
Jul 28   2
Jul 29   4
Jul 30   379 usage_limit_exceeded + 47 unauthorized
Jul 31   1
Total for July: 387

The resets are not auditable

I redeemed all three weekly reset credits. None of them appears in
/usage daily, and no telemetry field ties a reading to a specific window or
credit: limit_id is the literal string codex in essentially every
reading, and limit_name is always null. A reset that restores a partial
window is indistinguishable from one that works.

Control case

After exhaustion I created a second account on a different tier, which the
telemetry does distinguish, via plan_type. It existed for four hours on
Jul 30 (13:12–17:15 UTC), had no prior usage history, and reached 100% of
its weekly cap within a single task. By the same measurement as above its
full window holds 5,799,558,969 tokens — an order of magnitude below the
smallest window on the primary account.

That account is corroboration, not the complaint: it did not exist until
Jul 30, and the problem on the primary account had been running for ten days
by then.

Related

#35952 describes the same recomputed-anchor mechanism.
#36307, #34066 and #31601 report the same symptoms; I left data on each.

I can share the extraction method — it only reads fields the CLI already
writes locally.