Repository navigation
Pro 20x: Astra shows ~36% lower API-equivalent capacity per weekly quota than Sol (same-account measurements) #43731
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex desktop app on macOS. Exact application and bundled CLI versions are omitted from this public report for privacy; historical versions were not pinned for every measured interval.
What subscription do you have?
ChatGPT Pro 20x ($200/month), signed in with ChatGPT. The account endpoint reports planType=pro; please verify the 20x entitlement against the server-side account record.
What platform is your computer?
macOS. Exact OS version, build, and hardware details are omitted from this public report.
What issue are you seeing?
After switching from GPT-5.6 Sol to GPT-6 Astra, my locally recorded standard-API-price-equivalent usage per percentage point of weekly Codex allowance dropped substantially. A comparison on my own account, using a consistent price basis, gives about $1,925 per full weekly allowance with Sol versus $1,234 with Astra, approximately 35.9% lower.
I am requesting an accounting investigation. These dollar values are normalization estimates, not actual API charges, a published subscription entitlement, or proof that the weekly cap was reduced.
All times below are Asia/Shanghai (UTC+08:00), in 2026:
| Observed interval | Main model | Weekly meter used | Standard-API-equivalent text usage during interval | Projected equivalent for 100% of weekly allowance |
|---|---|---|---|---|
| Sep 1 03:22 – Sep 4 15:46 | GPT-5.6 Sol, with a small amount of GPT-5.4 mini | 20% → 50%: 30 percentage points | $577.3742 | $1,924.58 |
| Sep 6 01:05 – Sep 7 00:31 | GPT-6 Astra, with a negligible amount of GPT-5.4 mini | 60% → 67%: 7 percentage points | $83.3702 | $1,191.00 |
| Sep 8 11:03 – Sep 8 13:52 | GPT-6 Astra | 5% → 19%: 14 percentage points | $172.8169 | $1,234.41 |
The first two intervals share the same weekly reset identity: 2026-09-07 03:19:05 UTC. The third interval has reset time 2026-09-15 02:05:43 UTC. The lower effective capacity was already visible after switching models in the previous window, before the September 8 reset.
The current Astra interval represents roughly $12.34 per percentage point, versus $19.25 for the earlier Sol interval. Equivalently, the observed weekly meter moved about 1.56× as much per normalized API dollar.
These are interval-based extrapolations; I did not exhaust an entire weekly allowance to measure these values.
What steps can reproduce the bug?
This is a retrospective observation and measurement procedure, not a controlled minimal reproducer:
- Use a ChatGPT Pro 20x account in Codex and record the 10,080-minute codex usage window, including used_percent and resets_at.
- Record local token usage while working with Sol, then Astra.
- Match the first observed upward crossings of the selected percentage endpoints to locally recorded usage in the same interval and reset window.
- Reprice both periods on the same standard API basis and calculate: interval cost × 100 / percentage points consumed.
- Compare model periods within the same reset identity, and check whether the difference persists in the next window.
Data source and calculation details:
- Token records came from CC Switch, using its codex_session imports of Codex session logs. Quota observations came from local Codex JSONL token_count/rate_limits metadata.
- Historical stored costs were recalculated, because some older records retained older prices.
- Fixed normalization rates, USD per million tokens, in uncached input / cached input / output order:
- GPT-5.6 Sol: 4 / 0.4 / 20
- GPT-6 Astra: 10 / 1 / 50
- GPT-5.4 mini: 0.75 / 0.075 / 4.5
- OpenAI-style input_tokens includes cached input. Uncached input was calculated as input_tokens minus cache_read_tokens, avoiding double charging the cached portion.
- Reset timestamps differing by at most five seconds were grouped. Observations with reset timestamps already earlier than their observation time were excluded as stale replay.
- The normalization does not add API long-context or Fast multipliers.
My local default configuration is gpt-6-astra, xhigh reasoning, and service_tier=default. Inspected Astra task contexts included high and xhigh. Task-level Fast overrides were not present in the inspected usage metadata and remain unverified.
What is the expected behavior?
Please help reconcile these intervals against server-side metering and clarify whether the difference is expected:
- Verify the Pro 20x entitlement and whether weekly capacity or model-specific quota accounting changed across the intervals.
- Identify any Astra-specific subscription weighting, Fast charges, automatic review, or other shared usage that explains the discrepancy.
- Investigate any unintended difference between recorded activity and allowance debits.
- If allowance was incorrectly consumed, correct the accounting and restore the affected allowance as appropriate.
I am not assuming that every model must have an identical API-dollar-to-quota conversion. If the conversion intentionally differs, a documented explanation or auditable breakdown would resolve much of the uncertainty.
Additional information
Known limitations
- codex-auto-review is unpriced ($0) in CC Switch in both periods. The last 14-percentage-point interval contains 206 such unpriced records. Its underlying billing model and contribution to weekly allowance are unverified.
- This is locally recorded, account-level evidence. Other-device/cloud activity, non-text charges, retries not reflected in local usage, task-level service tiers, meter rounding, and reporting delay have not been fully reconciled.
- The measurements therefore establish a difference in the locally observed API-equivalent conversion, not a confirmed backend defect or a guaranteed weekly dollar budget.
Previously submitted Codex feedback
A report has already been submitted through the official Codex feedback channel. The private feedback reference is intentionally omitted from this public issue.
This public issue retains the subscription tier, aggregate usage amounts, and observation times. Account identifiers, exact software/OS versions, hardware details, private feedback references, local paths, source code, and raw conversation/application logs are omitted.
Related reports
- GPT-6 Astra: Usage limits consuming rapidly / short session length #43201 — Astra usage limits consuming rapidly.
- Pro weekly quota meter accelerated ~2.4x mid-window, then returned to normal (Aug 14) #38728 — earlier report of changing API-equivalent usage per quota point.
These may have different causes. This report adds a same-account Sol/Astra comparison with the price basis and remaining uncertainties stated explicitly.
Activity
github-actions commentedon Sep 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
svip3232 commentedon Sep 8, 2026
I’ve noticed that after switching from GPT-5.6 to GPT-6 Astra, my weekly usage percentage decreases significantly faster. Based on my actual usage, GPT-6 Astra appears to consume my weekly allowance at roughly three times the rate of GPT-5.6. Does GPT-6 Astra have a higher usage multiplier or consume more of the weekly allowance per token/request compared with GPT-5.6?
I am a ChatGPT Pro user and primarily use ChatGPT for software development, so the much faster consumption of my weekly allowance with GPT-6 Astra has a significant impact on my normal development workflow.
EateralSpirial commentedon Sep 11, 2026
Additional Pro 20x account-level data point from Sep 2026:
This implies an aggregate effective capacity of roughly $1,557–$1,833 API-equivalent per full weekly allowance, with a midpoint around $1,685 if the consumed amount is approximated as 3.25 weekly allowances.
That remains below the ~$1,925/full-week Sol interval reported in this issue, despite aggregating across multiple reset windows, so meter rounding at individual percentage points should have less influence on this estimate.
This still does not by itself prove a published entitlement was reduced: model-specific subscription weighting, unpriced shared/auto-review usage, reconciliation behavior, or other server-side accounting could contribute. But the observed effective weekly capacity is materially lower than the earlier Sol baseline, with Fast and >272K long-context multipliers excluded.
Please consider this as another independent Pro 20x data point for the accounting investigation.
Recoveredd commentedon Sep 12, 2026
Adding an independently measured Pro 20x data point from macOS. This is a comparison of two separate, model-dominant intervals from the same account, using local Codex/Work token telemetry paired with the server-reported weekly allowance percentage.
The apparent Sol/Astra full-allowance ratio is 1.975x. In other words, these measurements are consistent with an Astra-specific allowance weighting very close to 2x after model-specific credit rates have already been applied. This observation does not by itself determine whether that is intentional weighting, server-side usage absent from local telemetry, or an accounting defect.
Calculation basis, credits per 1M tokens in uncached input / cached input / output order:
The current 100 / 10 / 500 Sol promotion was not applied because OpenAI's current rate card says that promotion is for eligible usage paid with purchased credits and that included plan usage, 5-hour limits, and weekly limits are unchanged: https://help.openai.com/en/articles/11481834
Controls and validation:
service_tierwasdefault.There is also independent public corroboration from the unofficial Codex Quota Observatory. Its current Pro 20x Astra Standard series reports 326.4 reference credits per 1% quota, or about 32.6K per full allowance, from 52 samples covering 260 points over five UTC days, with mixed-model intervals excluded: https://codex-quota.manetli.com/ . That is close to this account's Astra result of 313.02 credits/point / 31.3K per full allowance, while this account's near-pure Sol interval is 618.23 credits/point.
Could maintainers please clarify whether an approximately 2x Astra-specific weighting exists in the included allowance, and, if so, document it? Otherwise, please reconcile these intervals against the server-side usage ledger, including retries or auxiliary compute not exposed in local telemetry. This also appears relevant to the broader tracker in #41220.
I can provide the aggregate measurement/evidence CSVs and private timestamps to OpenAI support or maintainers if useful; raw local logs and private account identifiers are not being posted publicly.
sm-yjr commentedon Sep 21, 2026
Independent Pro 20x data point, measured at per-token granularity rather than by exhausting a full weekly allowance.
Method. Mixed GPT-5.6 Sol and GPT-6 Astra usage within the same weekly windows, Fast mode off at all times. Per-request token counts (input / cached input / output) were parsed from Codex session logs with CC Switch (exact JSONL session parsing, v3.13+) and priced at standard API rates; weekly-meter percentage deltas were read from the usage meter. The compared quantity is the slope of meter depletion against recorded tokens, per model.
Observation.
Cross-check against other reports. 5.0 ÷ 2.5 (API price ratio) ≈ 2.0× aggregate — consistent with the 1.975× full-allowance pool ratio measured in the comment above, but in tension with #45940, which reconciles per-token depletion at only ~1.4× the published Astra rates (~3.5× vs Sol per token). Either the unpublished weighting varies across accounts or periods, or one of the measurement approaches carries a confound.
Ask. If the extra ~2× weighting is real, it is indistinguishable in aggregate from halving the Astra weekly pool while charging the published per-token rates. Could the team confirm which accounting structure applies to the included weekly allowance for Astra, and whether the difference vs Sol is intentional?