[Codex app][Windows][Pro] Weekly quota jumped 14% to 88% used in one server update; 98.1% cached Astra telemetry

What version of the Codex App are you using (From “About Codex” dialog)?

Windows package OpenAI.Codex_26.903.8094.0; bundled codex-cli 0.153.4.

What subscription do you have?

ChatGPT Pro. Local rate-limit records report plan_type: "pro" and a 10,080-minute weekly codex window.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

My remaining weekly Codex allowance fell from approximately 89% remaining to 10% remaining in about one hour on September 9, 2026. The server-provided rate-limit snapshots show the critical discontinuity precisely:

America/Toronto	Weekly used
11:45	9%
11:47	10%
11:56	11%
12:10	12%
12:18	13%
12:29	14%
12:43:51	88%
12:49	89%
12:58	90%

The meter therefore posted a 74 percentage-point jump in a single server response, from 14% used to 88% used. This was not a UI-only estimate: the values are in token_count.rate_limits.primary.used_percent in the local rollout records.

The response immediately associated with the jump was:

timestamp:   2026-09-09T16:43:50.993Z
response_id: resp_0deed235f76e50d9016aa18cbc098087d1899f85f0f84d403d
input:       199,922
cached:      197,760
output:      201
reasoning:   97 (subset of output)
total:       200,123

At 2026-09-09T16:43:51.540Z, the following token_count event reported used_percent: 88. The preceding global snapshots had reported 14% used. A 200,123-token response cannot by itself explain a 74-point weekly deduction, so this looks like delayed server-side reconciliation, duplicated accounting, an entitlement/weighting transition, or an incorrect rate-limiter state.

Request-level telemetry for the affected hour

I deduplicated token_usage_record entries by response_id. I did not sum cumulative total_token_usage snapshots.

All three background tasks used GPT-6 Astra, xhigh reasoning, and service_tier: "default". Fast mode was not enabled.

Task	Successful responses	Input	Cached input	Fresh input	Output	Total
Task A	70	22,425,111	22,183,424	241,687	96,196	22,521,307
Task B	130	23,949,590	23,566,208	383,382	103,827	24,053,417
Task C	32	8,704,547	8,549,376	155,171	57,334	8,761,881
Total	232	55,079,248	54,299,008	780,240	257,357	55,336,605

98.1% of input was reported as cached. The local records therefore show substantial real model traffic from long-context autonomous work, but they do not show a cache failure. Only about 0.78M input tokens were fresh.

Raw local tokens are not the same as allowance-weighted usage, and I am not claiming that they prove an incorrect charge. Only OpenAI has the server-side conversion and ledger. What needs investigation is why this account's weekly meter posted 74 points at once and whether the size of the accumulated deduction is correct.

What steps can reproduce the bug?

This is a tightly measured production observation, not yet a deterministic clean-room reproduction:

1. Start with approximately 89% of the weekly Codex allowance remaining.
2. Run three Codex Desktop tasks concurrently using GPT-6 Astra at xhigh reasoning and standard/default service tier.
3. Observe the server rate-limit snapshots move gradually from 9% to 14% used.
4. At 12:43:51 America/Toronto, observe the next completed response report 88% used.
5. Continue to observe 89% to 90% used over the following 15 minutes.

Affected task IDs for internal correlation:

01a0861c-1495-7a10-8c38-aeb01f4a0591
01a086b5-6317-7c23-8ec0-c5f3fd738b31
01a086ce-035a-7c41-b6bf-8d51cede4a48

No other known device or client was intentionally started for this work. The investigation itself began after the drop and is not included in the 232-response table.

What is the expected behavior?

Usage should be charged according to the documented plan and model rules, and the meter should provide enough attribution to explain large deductions. If accumulated usage is posted asynchronously, a 74-point weekly adjustment should be traceable to per-task and per-response ledger entries.

For the same account, heavier prior workflows involving approximately five simultaneous tasks, Fast mode, and Astra at max reasoning took roughly two to three hours to consume about 80% of the allowance. The September 9 result represents a sharp same-account effective-consumption change, although I do not have a complete request-level export for that earlier comparison window in this report.

Requested investigation

Please reconcile the affected interval against the server-side usage ledger and determine:

1. Event time versus accounting-post time for the 74-point adjustment.
2. Per-response and per-task weekly-meter deltas.
3. The effective GPT-6 Astra xhigh weighting and the rate-policy version applied.
4. Cached-input treatment for the 54.30M cached input tokens.
5. Any retries, hidden auxiliary work, compactions, safety checks, or duplicated metering not represented by unique successful token_usage_record response IDs.
6. Whether the ChatGPT Pro entitlement and weekly bucket were provisioned correctly.
7. Whether the September 9 Plus/Pro conversation incident or its mitigation/reconciliation work affected Codex usage accounting.

If the ledger shows an incorrect deduction, please restore the affected weekly allowance. If the deduction is intentional, please document the conversion and expose a per-task breakdown in the product.

Additional information

There are several closely matching open reports:

• #44203: weekly usage jumped from 25% used to 100% in about one minute on September 9.
• #44208: approximately 41 weekly percentage points disappeared during an 11-minute Astra Ultra Plan run on September 9.
• #44206: remaining allowance fell from approximately 98% to 99% to 16% shortly after a reset on September 9.
• #43222: Windows Pro Astra depletion appeared disproportionate to highly cached request-level telemetry.
• #41220: cross-report tracker for abnormal Codex usage and accounting inconsistencies.

OpenAI previously acknowledged an official incident titled "Codex Usage Limits Depleting Faster Than Expected" and stated that abuse and fraud prevention systems had incorrectly rate-limited some accounts: https://status.openai.com/incidents/01KW2E6W0503W4NXJNCVAG8V6T

The September 9 status incident for elevated Plus/Pro ChatGPT conversation errors was marked resolved at 12:21 p.m. America/Toronto, approximately 23 minutes before this account's 74-point jump. This is temporal correlation only, not evidence of causation: https://status.openai.com/incidents/01M23BNX5V1XT9P3NP0PX56FTN

Tagging @etraut-openai because they have previously requested thread IDs and diagnostic evidence when investigating Codex rate-limit reports. I can provide additional sanitized local telemetry if a specific schema or private upload channel is requested.

No credentials, account identifier, prompt contents, source code, private repository names, or private filesystem paths are included here.

No repository file, test, or code entry point is identified; start by reviewing the affected token_count and token_usage_record telemetry and the linked reports #44203, #44208, #44206, #43222, and #41220. The issue is done only when server-side ledger reconciliation explains the 74-point adjustment, including weighting, cached input, retries or auxiliary work, and entitlement state.