URGENT: Prolite account weekly Codex usage went 0% → 97% in one day with unstable reset windows #36528

What issue are you seeing?

Urgent account-metering / rate-limit report: my Codex account's visible weekly usage went from 0% used to 97% used in one day on 2026-08-01.

This is not just a confusing reset label. A near-total weekly allowance burn in one day is a real operational problem: I cannot use Codex reliably, cannot determine whether to wait/apply a reset/buy credits, and cannot reconcile local work with the visible account meter.

This is a follow-up to my earlier related report: #35816. I am opening this as a separate issue because the 2026-08-01 single-day 0% → 97% burn is urgent and materially worse than a generic reset-visibility problem.

Environment

• Product: Codex Desktop / local Codex session logs
• Platform: Windows
• Local telemetry plan type: prolite
• Visible usage bucket observed in local telemetry: window_minutes: 10080 / seven-day window
• Credits in local telemetry: 0
• Local logs scanned: Codex rollout JSONL files under the local .codex/sessions and .codex/archived_sessions folders
• Date range reviewed: 2026-07-12 through 2026-08-01 local days

I can provide account-specific screenshots, account identifiers, and raw local logs privately to OpenAI Support. I am intentionally not posting account/billing-identifying details publicly.

Key urgent symptom

On 2026-08-01, local Codex rate-limit telemetry showed:

The raw local token number is cache-heavy/local telemetry and may not equal billable usage. The critical point is the visible account usage percentage: 0% used to 97% used in one local day.

21-day visible usage/reset timeline

I reviewed local event_msg.payload.rate_limits.primary.used_percent and resets_at values from Codex rollout logs. The visible usage/reset window did not behave like a stable weekly cadence.

Why this looks wrong / high impact

Several things are happening together:

1. Near-total weekly burn in one day

   • 2026-08-01 went from 0% used to 97% used.
   • That is effectively the whole weekly allowance consumed in one local day.

2. Reset windows appear to move repeatedly

   • Examples:
     • 2026-07-21: visible usage 81% → 15%, reset target moved to 2026-07-28.
     • 2026-07-23: visible usage 77% → 4%, reset target moved to 2026-07-30.
     • 2026-07-27: visible usage 47% → 5%, reset target moved to 2026-08-03.
     • 2026-08-01: visible usage starts again at 0%, then ends at 97%, reset target 2026-08-08.

3. Users cannot reconcile actual usage to account metering

   • Local logs expose used_percent and resets_at, but not the server-side ledger explaining reset grants, banked resets, redemptions, expiration, delayed reconciliation, model weighting, cached input weighting, or subagent/thread attribution.

4. The product provides no safe operational warning

   • A single day/workflow can consume nearly the entire visible weekly allowance without a clear stop, cap, or warning threshold.

What steps can reproduce the bug?

I do not have a deterministic reproduction because this appears to be server-side account metering / delayed accounting / reset-window behavior. The observed review procedure was read-only:

1. Inspect local Codex rollout JSONL logs for the last 21 local days.
2. Extract event_msg entries where payload.type == "token_count".
3. Read payload.rate_limits.primary.used_percent and payload.rate_limits.primary.resets_at.
4. Group by local day.
5. Compare first and last visible usage percentages per day.
6. Observe 2026-08-01 going from 0% to 97% used in one local day.

What is the expected behavior?

• A weekly usage meter should not unexpectedly consume nearly 100% of the account's visible weekly allowance in one day without clear attribution and warnings.
• Reset windows should be stable and explainable, or the UI should clearly label when server-side corrections/reset grants/window changes are occurring.
• The Usage page / local telemetry should expose enough event history to explain:
  • reset grants
  • banked reset availability
  • reset redemption attempts
  • reset expiration
  • weekly-window changes
  • delayed server-side usage reconciliation
  • per-thread/per-agent/per-model consumption
  • cached-input/output/reasoning weighting, if those affect the visible percentage
• Long-running workflows should have a configurable warning or stop threshold before consuming a material share of weekly allowance.

Requested investigation

Please urgently investigate the account-side usage ledger for the last 21 days, especially:

1. Why did 2026-08-01 go from 0% used to 97% used?
2. Were any banked/full resets granted, consumed, expired, or lost during this period?
3. Were the visible reset-window movements on 2026-07-21, 2026-07-23, 2026-07-27, and 2026-08-01 expected?
4. Was usage delayed and then reconciled later?
5. Did subagents/reviewers or retained context loops multiply account-metered usage?
6. Did cached input count differently from what local token telemetry suggests?
7. Can incorrectly drained usage/reset credits be restored if this was an accounting or visibility bug?

Additional information

Related issues/reports I found or previously filed:

• Unexpected 50% Weekly Usage Drop During Subagent Review/Wait Workflow #35816 — my earlier weekly usage drop / subagent review loop report
• Multiple paid Codex accounts affected: limits drain after one prompt, company monthly credits burned in one day #31668 — multiple paid accounts / company credits burned in one day
• Codex Desktop misattributes GPT-5.6 usage to GPT-5.4 and updates weekly quota with large delays #32827 — delayed quota updates and local/account attribution mismatch
• Pro account: 5-hour usage bucket disappeared from Codex App and account/rateLimits/read #32707 — missing 5-hour usage bucket / weekly-only rate-limit telemetry
• Free Plan quota stayed near 95% for my entire 16-day usage history despite daily heavy Codex usage #27746 — delayed quota/accounting behavior over many days

Privacy note: I can provide screenshots, account identifiers, raw logs, and exact local file paths privately. Please do not ask me to post identifying billing/account details publicly.