Skip to content

[Pro 20x] Effective GPT-6 Astra allowance feels below one third of previous capacity; Sep 14–15 quota evidence #45644

Open

Description

@Water-Run

Pro 20x: reported severe reduction in effective GPT-6 Astra allowance and perceived quality regression

Account and environment

  • Subscription: ChatGPT Pro 20x, as reported by the user. The live Codex account endpoint confirms planType: pro; it does not expose the 20x multiplier in the returned snapshot.
  • Installed CLI: codex-cli 0.154.0.
  • Local diagnostic environment: Fedora 44, Linux 7.2.5-200.fc44.x86_64, x86_64. Desktop app version has not been verified.
  • Model recorded locally: gpt-6-astra.
  • Timezone for the table below: Asia/Shanghai (UTC+8).

User experience

Around last weekend (approximately September 12–13, 2026; onset is uncertain), my practical usable allowance began to feel like less than one third of what it used to be. Previously I could sustain GPT-6 at Max reasoning; now even High does not provide enough usable capacity for my work. I also perceive a substantial deterioration in model quality.

“Less than one third” is my estimate of practical capacity, not a measured entitlement ratio. No controlled before/after quality example has been supplied yet. Please investigate these reports without assuming the cause in advance.

Verified quota observations

These are account-level quota snapshots recorded in local Codex history, plus a fresh account/rateLimits/read response. All rows refer to the codex bucket and a 10,080-minute (weekly) window.

Date/time (UTC+8) Weekly used Weekly remaining
Sep 14, 08:58:37 25% 75%
Sep 14, 16:43:29 55% 45%
Sep 15, 09:45:11 55% 45%
Sep 15, 15:53:35, live API read 69% 31%

The next weekly reset returned by the live API is September 19, 2026, 16:44:45 UTC+8. This snapshot returns no secondary window for the main codex bucket, so it does not establish a 5-hour percentage for Astra. The separate Spark bucket must not be used as Astra's quota.

The observed main weekly counter increased by 30 percentage points during the Sep 14 interval and by 14 points during the Sep 15 interval. These are account-level changes across concurrent activity, not consumption attributed to one task.

Local usage evidence and limits

A local review covers 61 rollout files from threads updated since Sep 7. Earlier records predominantly show Astra max; Sep 14–15 records contain both high and xhigh. The recent consumption cannot be attributed solely to High. Local records show input, cached input, output and reasoning token counters; a filtered diagnostic attachment contains those counts, timestamps, session identifiers and quota snapshots.

The counts are local observed token usage, not server billing units. Cached input is a subset of input; reasoning output is a subset of output. This device's records may not cover other devices or all account activity. No local usage records were found for Sep 12–13 in this review, so the exact onset is not established. The observations alone do not prove a threefold change in quota weighting or a backend model downgrade.

Requested investigation

Please perform an account-level quota accounting investigation and determine whether the effective quota weighting or quota accounting for ChatGPT Pro 20x has changed.

  1. Verify the account's correct entitlement and explain any changes in effective allowance or model/reasoning weighting around Sep 11–15.
  2. Reconcile the recorded quota changes with server-side per-request usage, including input/cache treatment, reasoning output, subagents, retries, failed requests and recovery work.
  3. Check whether any quota resets, entitlement changes or account transitions affected the comparison period.
  4. Investigate the separately reported quality regression, including the actual model snapshot/routing and effective reasoning configuration. Please state what additional reproducible examples are needed.
  5. Provide the findings and an understandable usage breakdown; correct the allowance if erroneous accounting is identified.

Related public report: #43967. This is a separate account's complaint with its own local measurements; a common root cause has not been established.

Codex feedback submission

Feedback tracking ID: no-active-thread-01a0a416-21c5-7483-994b-60d6733ab2d0

Submitted successfully through Codex app-server feedback/upload with a filtered local usage diagnostic JSON attachment. Full conversation logs were not uploaded. This is an account-level report, so the feedback tracking ID has a no-active-thread- prefix. The diagnostic attachment includes session identifiers for correlation.

Activity

  1. added
    bugSomething isn't working
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    model-behaviorIssues related to behaviors exhibited by the model
    on Sep 15, 2026
  2. aoinoikaz commented on Sep 16, 2026

    @aoinoikaz

    I have the exact same issues on Pro 20x. Feels like usage is being drained significantly faster, as well as the overall quality of work has degraded.

  3. uncfreak1255-code commented on Sep 20, 2026

    @uncfreak1255-code

    Same tier (Pro 20x), same period, independent measurement — and one result that may narrow the cause.

    I reconstructed my weekly windows from the used_percent / resets_at values that Codex writes into its own
    rollout logs (token_count events), then compared each window against the tokens my sessions actually used in
    that window. ~162k rate-limit readings, ~193k deduped responses, Aug 1 – Sep 20.

    Window start (UTC) allowance used days uncached input output
    2026-08-20 03:58 68% 3.9 107.2M 7.88M
    2026-08-25 15:43 26% 5.0 86.5M 6.39M
    2026-08-27 15:24 22% 3.3 74.7M 5.99M
    2026-08-31 11:11 98% 3.1 103.3M 6.32M
    2026-09-03 14:20 100% 2.9 93.9M 6.04M
    2026-09-08 11:13 100% 2.6 70.4M 4.30M
    2026-09-12 01:06 100% 3.9 81.3M 4.80M

    September windows carried fewer tokens than August windows and still reached 100% faster. Expressed as work
    per 1% of allowance, it fell from roughly 5.5–14.4 units in August to 2.6–4.4 in September (stable across three
    different token weightings). The break starts with the Aug 31 window — before Astra was available to me on
    Sep 3.

    It does not look Astra-specific. My current window is 81% gpt-5.6 work, 9% Astra, 10% auto-review, and it is
    consuming allowance at 2.74 units per 1% — the same rate as my Sep 12–15 window, which was 32% Astra and 17%
    auto-review (2.83). Cutting Astra and auto-review by about two thirds changed nothing, which suggests the increase
    applies to baseline gpt-5.6 work as well.

    Controls I checked locally:

    • Service tier default throughout September (priority/Fast only Aug 21–26).
    • Cache hit rate flat at 94–97%, so this is not a caching regression.
    • Plan enum pro across both months; no plan change (Pro 20x billed continuously).
    • Per the usage dashboard for Aug 20 – Sep 18: Desktop App 77.0%, Exec 8.1%, GitHub Code Review 4.7%, the rest
      Mobile/Work/CLI/Cloud. No new surface appeared.
    • Scheduled jobs and automations are under 1% of usage.

    Method cross-check: my parser read 18.0% used at 2026-09-20 11:28:59Z; the account Usage page showed "82% left"
    at 11:43Z the same morning. Independent derivation, same number.

    For scale on the user-visible impact: my window hit 100% on Sep 15 17:25Z and did not reset until Sep 19 11:42Z —
    3.8 days with no Codex, during which 61 GitHub code reviews were refused with "You have reached your Codex
    usage limits for code reviews" (so cloud code review draws on the same weekly limit). I have also spent
    usage-limit resets to keep working (Sep 6 and Sep 11 per the Usage page; 0 available now).

    Happy to share the deterministic parser or per-window aggregates if that is useful to whoever picks this up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingmodel-behaviorIssues related to behaviors exhibited by the modelrate-limitsIssues related to rate limits, quotas, and token usage reporting

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions