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

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:

| Local day | Local tracked turns | Local tracked tokens | Visible weekly usage start → end | Net visible change | Last visible reset target |
|---|---:|---:|---:|---:|---|
| 2026-08-01 | 25,466 | 3,530.4M | 0% → 97% | +97 pts | 2026-08-08 02:08 MDT |

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.

| Day | Visible usage start → end | Net visible change | Last visible reset target |
|---|---:|---:|---|
| 2026-07-12 | 1% → 31% | +30 pts | 2026-07-19 14:33 MDT |
| 2026-07-13 | 31% → 47% | +16 pts | 2026-07-19 14:33 MDT |
| 2026-07-14 | 47% → 51% | +4 pts | 2026-07-19 14:33 MDT |
| 2026-07-15 | 0% → 2% | +2 pts | 2026-07-22 23:05 MDT |
| 2026-07-16 | 2% → 11% | +9 pts | 2026-07-22 23:05 MDT |
| 2026-07-17 | 11% → 58% | +47 pts | 2026-07-22 23:05 MDT |
| 2026-07-18 | no local events | — | — |
| 2026-07-19 | 0% → 25% | +25 pts | 2026-07-26 16:56 MDT |
| 2026-07-20 | 25% → 81% | +56 pts | 2026-07-26 16:56 MDT |
| 2026-07-21 | 81% → 15% | -66 pts | 2026-07-28 11:03 MDT |
| 2026-07-22 | 15% → 77% | +62 pts | 2026-07-28 11:03 MDT |
| 2026-07-23 | 77% → 4% | -73 pts | 2026-07-30 14:29 MDT |
| 2026-07-24 | 4% → 33% | +29 pts | 2026-07-30 14:29 MDT |
| 2026-07-25 | 0% → 10% | +10 pts | 2026-08-01 14:41 MDT |
| 2026-07-26 | 12% → 47% | +35 pts | 2026-08-01 14:41 MDT |
| 2026-07-27 | 47% → 5% | -42 pts | 2026-08-03 21:51 MDT |
| 2026-07-28 | 5% → 7% | +2 pts | 2026-08-04 22:09 MDT |
| 2026-07-29 | 7% → 43% | +36 pts | 2026-08-04 22:09 MDT |
| 2026-07-30 | 43% → 69% | +26 pts | 2026-08-04 22:09 MDT |
| 2026-07-31 | 69% → 71% | +2 pts | 2026-08-04 22:09 MDT |
| 2026-08-01 | 0% → 97% | +97 pts | 2026-08-08 02:08 MDT |

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.

1. 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.

1. 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.

1. 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:

• #35816 — my earlier weekly usage drop / subagent review loop report
• #31668 — multiple paid accounts / company credits burned in one day
• #32827 — delayed quota updates and local/account attribution mismatch
• #32707 — missing 5-hour usage bucket / weekly-only rate-limit telemetry
• #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.