[Bug]: prolite account with secondary_window: null is cached as monthlyPercent: 100 and is never selected #8067

Activity

1. github-actions commented on Nov 1, 2026

   

   github-actionsBot

   on Nov 1, 2026 – with GitHub Actions

   Last edited by github-actions

   Contributor

   More actions

   _{Automated translation bookkeeping — detected language: English.}
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   account-poolOAuth, credentials, Codex pool, quota, failover, plansOAuth, credentials, Codex pool, quota, failover, plans

   on Nov 1, 2026
3. smdk000 commented on Nov 1, 2026

   

   smdk000

   on Nov 1, 2026

   Author

   More actions

   Partial fix confirmed on 2.96.0 — main path is clean, the pool path still synthesizes monthlyPercent

   Retested on 2.96.0 (same machine, macOS 27.0 / arm64) right after release.

   The same ChatGPT prolite subscription is present twice — once as __main__ (it is also the account signed in to the Codex app) and once as a stored pool entry. After ocx account refresh openai the cache now looks like this:

   entry	weeklyPercent	monthlyPercent	monthlyIsPrimaryWindow
   __main__	30	(absent)	—
   chatgpt-…8970810465 (pool)	30	100	true
   chatgpt-…5502746301 (plus)	100	(absent)	—

   Upstream for the prolite account is unchanged:

   plan_type        : prolite
   allowed          : true
   limit_reached    : false
   primary_window   : used_percent = 30, limit_window_seconds = 604800
   secondary_window : null
   

   What this shows

   • The main-account writer no longer invents the missing secondary window: __main__ has no monthlyPercent at all. That is exactly the change that removed the false "reached its usage limit" refusals for the main path — 320/326 requests OK over the last 3 hours, no phantom-window refusals.
   • The pool writer still stores monthlyPercent: 100, monthlyIsPrimaryWindow: true for the same account, so that entry is still classified exhausted by isCodexQuotaExhausted() and is never selected.

   In this configuration the user-visible symptom is gone only because the blocked pool entry duplicates the main login. Add any second account on a …_prolite plan and it should reproduce exactly as reported.

   If the two writers share a parser, the fix just needs to reach the pool path as well; if the pool quota comes from the response headers (x-codex-secondary-used-percent / x-codex-secondary-window-minutes) rather than the usage payload, that header path is the one still emitting the synthesized 100.

   Happy to re-test any build — I can check both entries within a minute of ocx account refresh.
4. lidge-jun

   added a commit that references this issue on Nov 3, 2026

   fix(codex): retire a pool account's carried monthly window when WHAM …

   ...

   e35572f
5. lidge-jun commented on Nov 3, 2026

   

   lidge-jun

   on Nov 3, 2026

   Owner

   More actions

   Fixed on dev by #8120 (e35572f): a pool account kept a stale monthly 100
6. lidge-jun

   closed this as completedon Nov 3, 2026
7. smdk000 commented on Nov 3, 2026

   

   smdk000

   on Nov 3, 2026

   Last edited by smdk000

   Author

   More actions

   cc @lidge-jun — thanks for landing #8120. One follow-up before 2.97.0 ships:

   Tried the dev fix on top of the published 2.96.0 — pool entry still keeps monthlyPercent: 100

   Since 2.97.0 is not on npm yet, I applied the code half of #8120 (e35572f, src/codex/quota.ts +22/−6) directly to the installed 2.96.0. The published package ships src/ and runs it through bun, so a patched file takes effect after a restart. All four hunks applied cleanly and the proxy boots normally (port up in 4 s).

   After restart + ocx account refresh openai, the carried tuple is still there:

   entry	weeklyPercent	monthlyPercent	monthlyIsPrimaryWindow
   chatgpt-…8970810465 (pool, prolite)	95	100	true
   __main__ (qq.com, pro — different account, now the app login)	84	(absent)	—
   chatgpt-…5502746301 (plus)	100	(absent)	—

   So the main-account side is already clean on 2.96.0, but the pool side does not retire on a refresh.

   Why it may not be taking effect

   The new gate is:

   return observation.shortWindowAbsent === true
     && !isExplicitMonthlyWindow(primary) && !isExplicitMonthlyWindow(secondary) && tertiary == null
     ? { ...observation, monthlyWindowAbsent: true }
     : observation;

   For this account WHAM returns a single 7-day primary_window and secondary_window: null, so isExplicitMonthlyWindow(primary) should be false (604800 s < 28 d) and tertiary is null. That leaves observation.shortWindowAbsent === true as the only thing that can fail — or the merge never reaches the new else if because the earlier quota.monthlyIsPrimaryWindow === true branch runs first while the stored entry still carries monthlyIsPrimaryWindow: true.

   Questions:

   1. Does retirement require a fresh observation (a probe that carries the full WHAM topology) rather than ocx account refresh? If so, a pool account that is never selected may never get one — which is the exact state this bug leaves it in.
   2. Is the monthlyIsPrimaryWindow: true carried from the previous Free-plan reading enough to route the merge into the first branch and skip the new gate?
   3. Does a plain refresh run poolWhamPolicyObservation? I traced pool-quota-probe.ts:380 → setAccountQuotaFromParsed(..., poolWhamPolicyObservation(data, quota), ...), so it should — happy to be told I patched the wrong copy or missed a second call site.

   I reverted to a pristine 2.96.0 afterwards, so the machine is back to a clean state. Happy to retest any dev build or a 2.97 preview within a minute — I can report both entries right after ocx account refresh openai.

   (Also noted while testing, unrelated: this prolite account is at 95 % of its weekly window with reset on 2026-11-07, so it needs to be usable soon.)
8. wongang2

   added a commit that references this issue on Nov 13, 2026

   fix(codex): retire Free-era monthly tuple when a Plus probe reports 5…

   ...

   f5f1dbe