mirror of
https://github.com/fawney19/Aether.git
synced 2026-09-10 05:00:19 +08:00
`parse_codex_usage_headers` reads the unprefixed `x-codex-primary/secondary-*` headers as the account's own quota. They are not: they carry whichever limit governed the request, and `x-codex-active-limit` names it — `premium` for the plan's own limit, or a metered feature such as `codex_bengalfox` for a named per-model limit. On a request billed against a named limit the unprefixed headers repeat that limit's windows verbatim. So a single request to a model with its own limit writes that model's windows into the account slots. The paid-window swap then makes it worse: a named limit's secondary window is active, unlike the plan's disabled one, so the swap promotes the model's weekly window into the account's weekly slot — the slot the UI labels and the scheduler reads through `quota_usage_ratio`. It also sticks. Both weekly windows share `window_minutes`, so `codex_quota_same_window_identity` treats them as one window, and `codex_quota_merge_same_window` drops an observation whose deadline is earlier than the stored one. The two weeks start at different instants, so every later account observation looks like a stale sample of a window that already rolled over and is discarded until the model window's own deadline passes. Observed on a `pro` key running both model families: one `gpt-5.3-codex-spark` request replaced the account weekly window with the Spark weekly one, and the ~3000 plan-limit responses over the next 100 minutes were all discarded. The account's real weekly usage never landed, and its reset time was reported nine hours late. The header set describes itself — every named limit announces `x-codex-<feature>-limit-name` and carries its windows under the same prefix — so parse the named families directly and only claim the unprefixed windows for the account when no announced limit owns them. Responses without `x-codex-active-limit` keep the previous behaviour. This also stops the Spark windows from going stale: they were only ever written by the `wham/usage` admin probe even though every response carries them. Refs #746 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>