Pro 5x: investigate Astra/Sol quota consumption across three full weekly allowances (Fast mode off)

What issue are you seeing?

I am requesting investigation of potentially excessive subscription quota consumption on ChatGPT Pro 5x, with Fast mode disabled.

I exhausted one full weekly allowance, then used and exhausted two additional full resets: three complete weekly meter runs, or 300 percentage points of weekly usage in total. My local usage report for the corresponding activity shows $959.87 in estimated API-equivalent usage, across gpt-5.6-sol and gpt-6-astra.

All of this reported usage and both full resets were concentrated on September 6, 2026 (GMT). I do not have specific start/end or reset times. This is a reported calendar-day window, not a timestamp-verified interval.

This works out to approximately $319.96 per exhausted weekly meter, or $3.20 per weekly percentage point, assuming the report covers all activity charged during those three runs.

The concern is whether Astra-related model weighting, quota accounting, or reset behavior could explain the amount consumed. This is a request to reconcile the meter, not a claim that a billing defect has already been proven. The available aggregate does not isolate Astra from Sol or establish a before/after regression on my account.

Reported setup

Field	Value
Subscription	ChatGPT Pro 5x
Codex client	Codex App
App version	26.901.51231
Operating system	Windows 10; exact OS build not supplied
Installation source	Microsoft Store
Fast mode	Disabled throughout the three reported runs
Models shown in the usage report	gpt-5.6-sol, gpt-6-astra
Allowances exhausted	One original weekly allowance plus two full resets
Date of all reported usage and both resets	September 6, 2026
Timezone	GMT (UTC+00:00), as reported
Exact start/end/reset times	Not available
Report row label	2026-09
Reported total tokens	707,989,104
Reported API-equivalent cost	$959.87 USD

Usage evidence

Text transcription of my screenshot; the column headers were cropped, so the original numeric order is preserved rather than presenting inferred category labels as verified:

Period   Models                      Numeric columns, left to right
2026-09  gpt-5.6-sol, gpt-6-astra      19,099,425 | 3,423,311 | 1,164,019 | 685,466,368 | 707,989,104 | $959.87

Derived averages:

$959.87 / 3 full meter runs = $319.96 per full meter run
$959.87 / 300 percentage points = $3.20 per weekly percentage point

The three runs have not yet been separated at their reset timestamps. The average must not be treated as evidence that each run delivered the same amount of usage or that an ordinary weekly reset and the two additional resets had identical effective capacity.

What steps can reproduce the bug?

This is an observed account-level sequence, not a deterministic minimal reproduction. The reported sequence occurred on September 6, 2026, GMT:

1. Use Codex App 26.901.51231, installed from the Microsoft Store on Windows 10, on Pro 5x with Fast mode off, using the models listed above.
2. Exhaust the original weekly allowance.
3. Apply a full reset, continue using Codex, and exhaust that allowance; repeat for a second full reset.
4. Compare the three exhausted weekly meters with the local API-equivalent usage report, which totals $959.87.

Exact reset timestamps are unavailable. Model-by-model interval totals and server-provided quota snapshots are not included yet, so this report alone cannot establish the cause or rule out incomplete local usage coverage.

What is the expected behavior?

Quota consumption should be attributable to the actual activity and the applicable plan, model, service tier, and reset rules. Any intended differences between models or reset types should be explainable sufficiently to reconcile the user-visible meter.

I am not asserting that Pro 5x promises a fixed dollar amount of API usage, nor treating a third-party API-cost estimate as OpenAI's billing ledger.

Please investigate or identify the appropriate private support route to:

1. Verify that the correct Pro 5x entitlement and quota bucket applied throughout all three runs, including immediately after each full reset. September 6, 2026, GMT is the available day-level window for correlation; individual reset times are not known.
2. Reconcile quota deductions with model, actual service tier, input/cache/output usage, and any background, subagent, retry, or compaction activity. Fast mode was not enabled by me.
3. Explain any Astra-versus-Sol subscription weighting or reset-specific differences that would account for the result, and distinguish intended weighting from incorrect accounting or workflow amplification.
4. Correct the accounting and restore any allowance found to have been consumed incorrectly, if an investigation confirms an error.

Additional information

Related reports reviewed before filing:

• #41220 — cross-report tracker for abnormal quota depletion and usage-accounting inconsistencies.
• #43351 — another Pro 5x report involving Sol/Astra and rapid weekly depletion; that report also describes idle/background symptoms that I am not claiming here.
• #43230 — rapid Astra depletion following a reset on Pro 20x; a different subscription tier.

This report adds a specific Pro 5x / Fast-off / three-exhausted-meter-in-one-day measurement. A shared root cause with those reports is not established; please consolidate this case into the appropriate tracker if preferred.

Details still needed for account-level correlation include the usage-report tool/version/command and full headers, reasoning effort, per-model/per-reset totals, other active clients or shared-quota activity, and a suitable diagnostic or feedback ID. These are currently unknown rather than assumed absent. The Codex App version, Windows version, installation source, incident date, and reported timezone are supplied above; exact start/end/reset timestamps are unavailable.

The 2026-09 row is an aggregate, not independent proof of exact interval coverage. The September 6 date comes from my recollection of when the usage and resets occurred. No raw session logs, prompts, credentials, account identifiers, or private project content are being posted. Please specify a secure channel and the minimum diagnostic fields needed for further investigation.

This is an account-level investigation with no repository files, tests, or code entry points identified. Start by reviewing the reported usage aggregate and the available secure support route, then correlate the September 6 GMT activity with entitlement, model, service-tier, and reset records. Done means the three quota runs are reconciled and any accounting error or required correction is explained.