[Pro 20x][Windows] GPT-6 Astra weekly quota depletion appears disproportionate to local token telemetry in same-day Astra→Sol run

What version of the Codex App are you using?

Current Windows package during evidence collection: OpenAI.Codex 26.901.5003.0.

The affected work includes long-lived threads whose rollout session_meta.cli_version values span older versions (including 0.146.0-alpha.3.1 and 0.152.1), so I am not claiming this is isolated to one CLI build. The current installed Desktop package is the version above.

What subscription do you have?

ChatGPT Pro — $200 / 20x tier.

What platform is your computer?

Windows x64, Microsoft Windows NT 10.0.26200.0.

What issue are you seeing?

GPT-6 Astra appears to consume the shared weekly Codex allowance disproportionately quickly compared with GPT-5.6 Sol on the same account and same machine.

On Sep 5, 2026 (America/Los_Angeles), I observed the weekly allowance UI fall from approximately 45% remaining to 5% remaining over the broader work session. I confirm that no other device/client was running Codex; all Codex activity was on this Windows machine and is represented by the local Desktop/Work rollouts.

I switched away from GPT-6 Astra to GPT-5.6 Sol because the allowance was falling too quickly. From the UI I observed at least ~20 percentage points of weekly allowance disappear while I was actively using Astra before/around the switch (possibly closer to 25 points, but I cannot support the 25-point figure precisely, so I am using 20 as the conservative observation).

Importantly, the local rollout telemetry can now be reconciled against the raw daily token total. A complete scan of all rollouts that were still being written on Sep 5 (including long-lived threads created on earlier dates) gives 1,212,053,536 total tokens, which closely matches the ~1.22B raw-token figure observed in the client. This avoids the common mistake of scanning only rollouts created on that calendar date.

Local token telemetry for Sep 5

All figures below are sums of each request's token_count.info.last_token_usage; cumulative total_token_usage snapshots are not summed. cached_input_tokens is treated as a subset of input_tokens.

Model / effort	Calls	Input	Cached input	Output	Total
GPT-6 Astra max	66	16,857,635	16,115,328	164,486	17,120,167
GPT-6 Astra xhigh	106	14,656,480	14,242,688	78,134	14,734,614
GPT-6 Astra total	172	31,514,115	30,358,016	242,620	31,854,781
GPT-5.6 Sol max	1,684	492,848,479	485,567,488	846,384	494,257,249
GPT-5.6 Sol high	1,158	312,469,897	306,271,360	876,944	313,515,703
GPT-5.6 Sol xhigh	1,094	300,497,017	296,851,840	848,281	301,426,262
GPT-5.6 Sol total	3,936	1,105,815,393	1,088,690,688	2,571,609	1,109,199,214
codex-auto-review	454	67,986,200	54,632,704	56,129	70,999,541
Day total	4,562	1,205,315,708	1,173,681,408	2,870,358	1,212,053,536

Astra's input was 96.33% cached; Sol's was 98.45% cached.

Direct rate-limit timeline captured in the rollouts

The token_count.rate_limits records use limit_id: "codex", plan_type: "pro", and a 10,080-minute weekly window.

The available Sep 5 local-day slice directly shows:

• 00:00 local: weekly used_percent = 64% (36% remaining).
• Astra xhigh continues until about 02:02:48 local.
• Astra max continues until about 02:53:14 local.
• Around the end of the Astra-active period the weekly meter reaches 70% used.
• No further GPT-6 Astra requests occur after ~02:53:14 in the Sep 5 rollout data.
• Sol / auto-review continue for the remainder of the day.
• The weekly meter eventually reaches 95% used (5% remaining), matching the UI endpoint of the observed depletion.

During the 00:00–02:53 Astra-active tail, other local Sol/auto-review threads were also active, so I do not attribute the entire 64%→70% movement to Astra. The user's ~20-point Astra-period observation spans a wider session than this after-midnight slice and the server meter can lag, so that observation is deliberately kept separate from the directly logged 6-point tail.

What makes this worth backend reconciliation is that the same account/day provides a large local model split and an explicit model switch: Astra accounts for only 31.85M locally recorded total tokens while Sol accounts for 1.109B, yet the user-visible allowance was already dropping rapidly enough during the Astra phase to force a switch back to Sol.

Additional rate-limit attribution anomaly

The same export also contains 196 codex-auto-review token_count events (about 33.0M total tokens) reporting limit_id: "codex_bengalfox", window_minutes: 300, and used_percent: 0.0, while other simultaneous requests on the same account report the real codex weekly bucket climbing from 64% toward 95%.

That resembles the bucket-attribution symptom reported in #43136. I am not claiming it is the cause of the Astra depletion, but it makes client-side quota attribution less trustworthy and is relevant when reconciling this window.

Steps to reproduce / observed sequence

This is an observed production sequence, not yet a deterministic clean-room reproduction:

1. On a Pro 20x account, note the weekly remaining allowance.
2. Run local Codex/Work tasks using GPT-6 Astra at xhigh/max (Ultra) on Windows Desktop.
3. Observe the weekly meter declining unusually quickly.
4. Switch the active work back to GPT-5.6 Sol because of the depletion.
5. Extract all local rollout JSONL files that received Sep 5 events, including long-lived rollouts created on earlier dates.
6. Sum only last_token_usage per request and correlate with rate_limits snapshots.

No prompts, source code, repository paths, credentials, or session IDs are included in this public report.

Expected behavior / requested investigation

Please reconcile this Sep 5 account window against server-side usage attribution and determine:

1. How much weekly allowance was charged to GPT-6 Astra xhigh/max versus GPT-5.6 Sol and codex-auto-review.
2. Whether Astra's effective Pro-included allowance weighting is intentionally much higher than users can infer from local token telemetry, and if so document it clearly.
3. Whether cached-input treatment, retries, hidden/server-side agent work, or duplicated metering caused additional Astra charges not represented in last_token_usage.
4. Whether any requests in the affected work were attached to the wrong rate-limit bucket / entitlement state.
5. Whether long-lived threads created under older app-server versions can retain stale model/quota routing after Desktop/model upgrades.
6. Expose per-task/per-model quota attribution so users can audit a drop without reconstructing JSONL rollouts.

If server-side reconciliation shows incorrect deduction, please restore the incorrectly consumed allowance.

Related issues

• #41220 — abnormal quota/accounting cross-report tracker
• #43029 — GPT-6 Astra Ultra consumes ~30% of Pro 20x weekly quota during ~1-hour task
• #43136 — session pinned to wrong rate_limits bucket while same-account sessions receive the correct codex bucket

This report adds a same-account, same-day Astra→Sol comparison with 4,562 request-level token records and a raw daily total that reconciles to the client's ~1.22B figure.

Begin with the Sep 5 rollout JSONL records, using token_count.info.last_token_usage and token_count.rate_limits as the reported comparison points. Review related issues #43029 and #43136, then reconcile Astra, Sol, and codex-auto-review against server-side quota attribution. Done means explaining the discrepancy, identifying any wrong bucket or metering behavior, and determining whether allowance restoration is warranted.