[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:

On a Pro 20x account, note the weekly remaining allowance.
Run local Codex/Work tasks using GPT-6 Astra at xhigh/max (Ultra) on Windows Desktop.
Observe the weekly meter declining unusually quickly.
Switch the active work back to GPT-5.6 Sol because of the depletion.
Extract all local rollout JSONL files that received Sep 5 events, including long-lived rollouts created on earlier dates.
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:

How much weekly allowance was charged to GPT-6 Astra xhigh/max versus GPT-5.6 Sol and codex-auto-review.
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.
Whether cached-input treatment, retries, hidden/server-side agent work, or duplicated metering caused additional Astra charges not represented in last_token_usage.
Whether any requests in the affected work were attached to the wrong rate-limit bucket / entitlement state.
Whether long-lived threads created under older app-server versions can retain stale model/quota routing after Desktop/model upgrades.
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

[Meta] Abnormal Codex usage/quota depletion and usage-accounting inconsistencies — cross-report tracker #41220 — abnormal quota/accounting cross-report tracker
[Codex app] GPT-6 Astra Ultra consumes ~30% of a 20x Pro weekly quota during a ~1-hour task #43029 — GPT-6 Astra Ultra consumes ~30% of Pro 20x weekly quota during ~1-hour task
Session pinned to wrong rate_limits bucket (codex_bengalfox) while concurrent sessions on the same account receive the correct codex bucket #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.

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

[Codex app] GPT-6 Astra Ultra consumes ~30% of a 20x Pro weekly quota during a ~1-hour task #43029

Powered by Codex Action

Thanks. #43029 is clearly related, but I am keeping this issue open for now because it adds materially different diagnostic evidence rather than only another subjective depletion report: a same-account/same-day Astra→Sol comparison, 4,562 request-level last_token_usage records, a 1.212B-token daily total that reconciles with the client-side raw-token figure, and correlated rate_limits snapshots. It also captures a simultaneous codex_bengalfox attribution anomaly similar to #43136.

If a maintainer designates #43029 (or #41220) as the canonical tracker, I am happy to consolidate this evidence there and close this issue as a duplicate. Until then, keeping the forensic dataset separately addressable should make backend reconciliation easier.

I’m seeing something similar, and I’m also starting to suspect cached input.

I tried normalizing my Astra and Sol usage using their respective API prices. Since Astra is roughly around 2× more expensive than Sol, I would naturally expect it to consume the weekly quota significantly faster.

The strange part is that what I’m seeing is noticeably more than that expected difference.

What caught my attention is that if I artificially apply roughly a 2× weight to Astra’s cached input in my calculation, the relative weekly quota consumption between Astra and Sol starts to line up much more closely with what I would expect from their pricing difference.

I also tried lowering reasoning effort and disabling Fast mode, but that didn’t noticeably improve the quota consumption.

So I can’t confirm cached input is the cause, but right now it’s the part I’m most suspicious of.

Commenting to add more metrics.

Account type                     ::: Pro 20x
Model                            ::: gtp-6-astra
Thinking                         ::: High
Fast                             ::: False
Max Context Window Size          ::: 258K
Weekly Quota Remaining @~11:28PM ::: 42%
Weekly Quota Remaining @~ 6:15AM ::: 0%

So, the time to use approximately 42% of a Pro x20 accounts weekly quota was just over 6h47m
(measured from a quota screenshot near the beginning to a last modified time on a file near the end)

Details:

This was the only drain during this time window I believe. No other agents, no code review, no chatting.
It was using subagents, upto 3 sometimes
It was likely often waiting on an external local model a lot during the time frame (it was refining prompts), so codex was not working actively the whole time.

Adding a privacy-preserving same-account data point and requesting backend clarification/reconciliation, not asserting a proven billing defect.

Environment and plan

ChatGPT desktop / Codex interface, macOS; app version 26.901.51231 (build 8109).
Paid ChatGPT Pro 20x, as explicitly confirmed by the subscriber.
Investigated window: September 7, 2026, 10:30–18:32 UTC+08:00.
The weekly Codex meter (limit_id=codex, 10,080-minute window) started at 0% after reset and reached 12% during that window. It first reported 13% at 18:34 while a diagnostic conversation was active. The later diagnostic activity is excluded from the totals below.

Locally recorded token usage within the 0%→12% investigation window

Model	Input, including cached	Cached input (subset)	Output, including reasoning
GPT-6 Astra	105,630,985	102,310,528	247,925
GPT-5.6 Sol	13,185,236	12,755,968	36,610
GPT-5.6 Terra	28,065,059	26,635,776	131,353
Total	146,881,280	141,702,272	415,888

Method: read retained local rollouts, including long-lived tasks created before that date, and sum positive changes in cumulative token usage within the time window; repeated unchanged usage snapshots are excluded. Cached input is a subset of input, not an extra input amount. Reasoning is not added again on top of output. There are 1,111 token-producing usage increments across 12 retained task/worker rollouts. This is local telemetry, not a complete server-side ledger, and an increment should not be assumed to represent every hidden server operation.

Astra turn metadata in this window is high/medium mixed (584 high and 197 medium usage increments), not max throughout. The user expected medium/default-speed operation. Current configuration and explicit historical speed-setting overrides inspected for this window use default; no explicit fast/priority setting was found in this window. Some records omit a speed value, so this is not a claim of independently verified per-response billing tier. Older September 5–6 logs contain priority settings, so those dates are deliberately NOT used as a controlled no-fast baseline.

Using the currently published standard credit rate card purely as a normalization metric gives approximately 4,130.62 nominal credits for the table above: 3,697.78 Astra, 188.79 Sol, 244.05 Terra. This is NOT an assertion that included subscription quota follows that rate card exactly, nor a purchased-credit charge. It does not apply any undisclosed subscription optimization or account-specific weighting. Dividing this number by 12% would only infer a denominator circularly; it cannot establish the actual Pro 20x weekly capacity.

Why reconciliation is requested
The subscriber is concerned that this depletion is excessive for Pro 20x and wants to know whether the correct entitlement and the recently announced Astra long-tail subscription-usage optimization were applied. Tibo's announcement describes up to 3–4x less subscription usage in some long-tail cases without a quality change; this report does not assume every workload qualifies or that this particular account already received that benefit.

Please clarify or investigate:

Whether the effective Pro 20x entitlement was correctly applied in this window, rather than relying only on the generic plan_type: pro label.
Whether the Astra subscription-usage optimization applied to these requests, and what determines eligibility/effective rollout.
Whether model/cache weighting, background/auto-review activity, retries, or metering omissions explain any difference between the local usage table and the charged weekly allowance. These are questions, not established causes.
Provide an auditable per-model/per-task charged-usage breakdown or an explanation of expected consumption. If incorrect deductions are confirmed, restore the affected allowance.

Privacy: no account identifiers, email addresses, session/feedback IDs, repository names or paths, prompts, source code, raw logs, screenshots, or credentials are attached. Account-specific reconciliation may require a secure support channel; this public comment intentionally cannot identify the private account. Please do not request raw private session logs in this public thread.

@fmlavephilippines-commits

Adding another same-account Sol→Astra comparison, this time from a headless fleet rather than an interactive session, because it isolates the model variable well: same account, same host, same orchestrator, same xhigh effort, Fast off, no subagents, and the workload is the same kind of GitHub-issue implementation work every day. The only thing that changed between windows is the model.

Setup

ChatGPT Pro 20x ($200), macOS 15.7.4, Apple M4
codex-cli 0.152.1 → 0.153.4 over the period (no version change lines up with the jump below)
Sessions are launched by an orchestrator (originator: detent-orchestrator), 4–12 concurrent sessions, one session per issue, no MultiAgent / subagents, Fast mode off
model_reasoning_effort = "xhigh" for both models; Sol until Sep 4, Astra from Sep 4 on
Numbers below are summed from the rollout files in ~/.codex/sessions/2026/09/*/*.jsonl: rate_limits.primary.used_percent for the weekly meter (Pro has no 5h window, so primary is the weekly window and secondary is null), and info.last_token_usage per token_count event for tokens. Windows are grouped by primary.resets_at; each row is a fresh reset (the Sep 5–6 ones are the banked Astra-rollout resets).

Weekly window burn, per fresh reset (UTC)

Window start	Model / effort	Input tokens	Cached	Uncached input	Output	Meter movement	Input tokens per 1% of weekly
Sep 2 12:40	gpt-5.6-sol xhigh	1,447M	98%	36.0M	5.0M	0→100% in 20.8h	14.5M
Sep 3 13:00	gpt-5.6-sol xhigh	1,321M	98%	28.1M	4.1M	1→91% in 16h	14.7M
Sep 4 05:00	sol 822M + astra 156M, xhigh	978M	98% / 96%	23.5M	3.1M	0→100% in 22h	9.8M
Sep 5 03:10	gpt-6-astra xhigh	29M	89%	3.2M	0.21M	15→92% in 15h	0.38M
Sep 5 18:40	gpt-6-astra xhigh	29M	93%	2.0M	0.16M	1→98% in 5.3h	0.30M
Sep 6 15:50	gpt-6-astra xhigh	107M	94%	6.3M	0.54M	7→98% in ~7h	1.2M

What that says

Sol at xhigh cost a very stable ~14.5M input tokens per weekly percentage point across two full windows, so a full Pro week is roughly 1.4B tokens of this workload (98% cached).
Astra at the same effort cost 0.3M–1.2M input tokens per point. That is 12×–48× more quota per input token, not the ~2.5× the API rate card implies.
It is not explained by the uncached or output share either: uncached input per point is 0.36M (Sol) vs 0.02–0.07M (Astra), output per point is 50k (Sol) vs 1.6k–6k (Astra). Every way I slice the ledger, Astra's quota weight per token is an order of magnitude above Sol's.
The mixed Sep 4 window is the closest to @fmlavephilippines-commits's run. If Sol is charged at its usual 14.5M/pt, its 822M accounts for ~57 points, which leaves ~43 points for Astra's 156M, i.e. ~3.6M/pt, about 4× Sol. The Astra-only windows on Sep 5–6 are 3×–12× worse than that again, which is consistent with ASTRA Token burn just drastically increased this morning, what happened?! #43230's report that Astra burn stepped up around Sep 5–6 rather than being a fixed multiplier.
Concretely: on Sep 5 the window went 1% → 98% in 5.3 hours on 29M input tokens (2.0M uncached) and 0.16M output. At Astra's API prices that is roughly $55 of tokens for an entire Pro week.

Caveats

Token totals are only what this host's rollouts saw. A second machine on the same account also runs Codex sessions (Sol on the Sol days, Astra on the Astra days) and its tokens are not counted here, so every row understates tokens per point by some amount. That applies to the Sol rows and the Astra rows alike, so it cannot produce the 12×–48× gap on its own, but the absolute per-point figures should be read as lower bounds.
The Sep 5 03:10 window was already at 15% when the first session observed it, and the Sep 6 15:50 window at 7%, so the per-point figures for those rows are slightly generous to Astra, not the other way round.
Wall-clock durations are not comparable across rows because concurrency varied (4–12 sessions); the tokens-per-point column is the one to compare.

Happy to share the aggregation script or per-request records if it helps the team reconcile. Like the other reports here, the ask is simply a published quota weighting for Astra so the meter can be budgeted against.

I’ve noticed similar Astra usage behavior in my own engineering tasks.
Instead of treating this only as a quota problem, I started looking at how the workload was being assigned to the model. A significant part of the context and execution did not actually require premium reasoning.
I’ve been experimenting with splitting the workflow across specialized agents/models:
Router → Context Scout → Premium Reasoning → Implementer → Reviewer
Repository discovery and context filtering are handled before the expensive reasoning step. Routine implementation, tests, documentation and Git operations can then be delegated to smaller models, while Astra is reserved for architecture, security and difficult reasoning.
This doesn’t change Astra’s underlying quota consumption, but it can reduce how much unnecessary work is sent to it.
I turned the experiment into a small open-source GitHub template:
https://github.com/robert-lukowski/token-gourmand
Still early, and I’m planning to benchmark the actual reduction rather than assume the savings.

Adding a Pro 20x / Windows same-account Sol→Astra comparison covering August 25–September 8, 2026, based on 7,929 archived Codex/OpenAI usage events correlated with weekly-meter snapshots.

Comparison window, UTC	Main model	Weekly meter	API-equivalent value	USD per 1%	Projection to 100%
Aug 25 15:28 – Aug 27 07:10	Sol	0%→14%	$253.4508	$18.1036	$1,810.36
Sep 4 07:14–19:16	Sol	1%→5%	$66.6326	$16.6581	$1,665.81
Sep 4 19:16 – Sep 7 07:13	Astra	5%→31%	$309.8057	$11.9156	$1,191.56

Against the August 25–27 Sol baseline, Astra consumed approximately 1.52× as much weekly quota per API-equivalent dollar: 51.9% more quota, after accounting for the models’ different API prices. This comparison applies to the specific windows above.

Across the full analysis period, recorded API-equivalent usage totals $830.9997: Astra $492.0015, Sol $338.5735, Luna $0.4248. Astra’s input cache hit rate was 96.5650%, versus 97.6864% for Sol.

Method and limitations

Standard short-context API rates, per million uncached/cached/output tokens: Astra $10/$1/$50, Sol $4/$0.40/$20, Luna $0.20/$0.02/$1.20. Cached input and reasoning are not counted twice; Fast/long-context uplifts and tool fees are excluded.
Quota readings are shared, rounded and may lag. Historical August effort metadata is unavailable; identical workload/effort/Fast settings are not established. 2,119 recent events matched surviving rollout records with no token discrepancies.

Please reconcile the effective Pro 20x entitlement and per-model/cache quota weighting for these windows. If weighting changed, please explain when and why; if deductions were incorrect, please correct them

Adding a closely matching Windows Pro case from September 9: #44213. It records 55.34M tokens across 232 unique Astra xhigh responses with 98.1% cached input, while the weekly meter jumped from 14% used to 88% used in one server response. This strengthens the request for backend reconciliation of cached-input treatment, Astra weighting, event time versus posting time, and per-response quota deltas.

I'm getting a similar isssue, id 01a0ae78-12c5-7900-aca4-b83783a4680b

Navigation Menu

Repository navigation

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

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Local token telemetry for Sep 5

Direct rate-limit timeline captured in the rollouts

Additional rate-limit attribution anomaly

Steps to reproduce / observed sequence

Expected behavior / requested investigation

Related issues

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

What version of the Codex App are you using?

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Local token telemetry for Sep 5

Direct rate-limit timeline captured in the rollouts

Additional rate-limit attribution anomaly

Steps to reproduce / observed sequence

Expected behavior / requested investigation

Related issues

Activity

github-actions commented on Sep 6, 2026

fmlavephilippines-commits commented on Sep 6, 2026

zhangzhenguo-it commented on Sep 6, 2026

Grallen commented on Sep 6, 2026

you3fen commented on Sep 7, 2026

michaelhvisser commented on Sep 7, 2026

robert-lukowski commented on Sep 8, 2026

chrislopez24 commented on Sep 8, 2026

dogancanbaris commented on Sep 9, 2026

AndreaPi commented on Sep 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions