Skip to content

ChatGPT Pro (20x) accounts appear to receive Pro 5x Codex usage capacity #38157

Open
Open
ChatGPT Pro (20x) accounts appear to receive Pro 5x Codex usage capacity#38157
Labels
authIssues related to authentication and accountsbugSomething isn't workingrate-limitsIssues related to rate limits, quotas, and token usage reporting

Description

@Jonesau
Jonesau
opened on Aug 12, 2026

What happened?

Multiple active ChatGPT Pro accounts still show the paid Pro (20x) subscription, and the official Codex usage API continues to identify them as plan_type: "pro". However, their effective Codex usage allowance now behaves like the much smaller Pro 5x tier.

The issue is therefore not the displayed subscription name or the plan_type field. It is the amount of usable quota actually allocated to accounts that are still subscribed to Pro (20x).

Observed behavior

  • The affected accounts remain active ChatGPT Pro subscriptions.
  • The official usage response still reports plan_type: "pro".
  • Despite that, usage percentages rise and limits are reached at a level consistent with Pro 5x rather than the expected Pro 20x allowance.
  • This was observed across multiple separately subscribed Pro accounts, not just one account.
  • The change appeared at roughly the same time across the affected accounts.

Expected behavior

Accounts subscribed to ChatGPT Pro (20x) should receive the corresponding Pro 20x Codex usage allowance.

Actual behavior

The accounts are labeled and authenticated as Pro, but their effective Codex quota appears to be provisioned at approximately the Pro 5x level.

Request

Could the team please investigate the effective quota allocation for active Pro subscriptions, including whether some Pro 20x accounts were accidentally assigned the lower 5x allowance during a quota reset or entitlement rollout?

No account identifiers, email addresses, credentials, or private infrastructure details are included in this report.

Activity

  1. github-actions
    added
    bugSomething isn't working
    authIssues related to authentication and accounts
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    on Aug 12, 2026

  2. github-actions commented on Aug 12, 2026

    @github-actions
    github-actionsbot
    on Aug 12, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. Jonesau
    changed the title [-]Active ChatGPT Pro (20x) accounts are being assigned `prolite` (5x) Codex limits[/-] [+][Correction] Initial Pro 20x to `prolite` report used the wrong account[/+] on Aug 12, 2026
  4. Jonesau
    changed the title [-][Correction] Initial Pro 20x to `prolite` report used the wrong account[/-] [+]ChatGPT Pro (20x) accounts appear to receive Pro 5x Codex usage capacity[/+] on Aug 12, 2026

  5. AiurArtanis commented on Aug 12, 2026

    @AiurArtanis
    AiurArtanis
    on Aug 12, 2026

    Pro 20x user checking in 🙋
    Honestly, this feels even worse than “20x being billed like 5x.”
    From what I’m seeing, it’s more like a weekly allowance is being burned as if it were a 5-hour allowance.

    At this rate, “20x” is starting to look less like a multiplier and more like a speedrun category. 😅

  6. jiaruihz commented on Aug 17, 2026

    @jiaruihz
    jiaruihz
    on Aug 17, 2026 – with ChatGPT Codex Connector

    Another independent Pro 20x reproduction, with a controlled time window and local token telemetry.

    I am subscribed to the $200/month ChatGPT Pro 20x tier. My local Codex metadata still reports:

    plan_type: "pro"

    However, after my weekly window reset on Aug 13, the effective weekly capacity became dramatically smaller than my historical experience under a similar workflow.

    Controlled interval

    OpenAI Support confirmed that my main Codex weekly window had 18% remaining at:

    2026-08-14 18:15:11 UTC+8

    By approximately:

    2026-08-16 09:00:00 UTC+8

    the same weekly window had reached 0% remaining.

    I parsed my local ~/.codex/sessions/**/rollout-*.jsonl telemetry for exactly that interval, using deltas of cumulative total_token_usage rather than summing repeated cumulative values.

    Local activity during the 18% -> 0% interval

    GPT-5.6 Sol

    total_tokens            11,963,774
input_tokens            11,934,579
cached_input_tokens     11,495,680
uncached_input_tokens      438,899
output_tokens               29,195
reasoning_output_tokens     10,240

    GPT-5.6 Terra

    total_tokens            11,650,801
input_tokens            11,608,034
cached_input_tokens     10,520,576
uncached_input_tokens    1,087,458
output_tokens               42,767
reasoning_output_tokens     16,646

    Combined

    total_tokens            23,614,575
input_tokens            23,542,613
cached_input_tokens     22,016,256
uncached_input_tokens    1,526,357
output_tokens               71,962
reasoning_output_tokens     26,886

    So approximately 93.5% of input tokens were cached input.

    This was not a Fast-mode or image-generation workload:

    • Fast mode: No
    • Image generation: No
    • Voice-initiated Codex tasks: No
    • GPT-5.3-Codex-Spark usage was negligible and is tracked in its separate window

    Using the published short-context token/credit rates, the locally observed activity is only on the order of a few hundred credits (roughly ~340–370 depending on the applicable Terra rate table), yet it coincided with depletion of the final 18 percentage points of the weekly Pro 20x window.

    I understand local telemetry is not the authoritative server-side usage ledger, and there may be additional shared/background usage not visible locally. That is exactly what I would like the Codex team to help reconcile.

    This seems closely aligned with this issue: the account still identifies as pro, while the effective quota allocation / denominator appears much smaller than the expected Pro 20x tier.

    Could the team please check whether some $200 Pro 20x accounts are receiving an incorrect effective weekly quota after reset, or whether there is hidden server-side usage/accounting (retries, subagents, background activity, shared agentic usage, delayed reconciliation, etc.) that would explain this discrepancy?

    A per-session/server-side credit deduction view would also make this class of issue much easier to diagnose.

    Related detailed report: #38367.

  7. jiaruihz commented on Aug 20, 2026

    @jiaruihz
    jiaruihz
    on Aug 20, 2026 – with ChatGPT Codex Connector

    Fresh Pro 20x reproduction after a new weekly reset: the meter fell to 46% remaining (~54 pp consumed) within ~11 hours, while the entire local Aug 20 Codex activity was only ~14.10M GPT-5.6 Terra tokens, corresponding to roughly <=117 published-rate credit-equivalent activity (and that is an upper bound because the daily report includes usage before the weekly reset time).

    I posted the full token reconciliation and specific server-side questions in #38367. This again appears consistent with an effective quota denominator / entitlement or server-side accounting mismatch rather than visible local workload alone.

  8. iiijiashu commented on Aug 20, 2026

    @iiijiashu
    iiijiashu
    on Aug 20, 2026

    I think I’m seeing the same issue on my Pro 20x account.

    My account still shows plan_type: pro, but the actual Codex quota feels much smaller. I checked the analytics data and the numbers are very consistent.

    I used:

    daily credits / daily usage percentage × 100

    and got basically the same result every day:

    • Aug 13: 19,976 credits / 48.80% → ~40,932
    • Aug 14: 4,443 / 10.86% → ~40,932
    • Aug 15: 11,018 / 26.92% → ~40,932
    • Aug 16: 13,049 / 31.88% → ~40,932
    • Aug 17: 7,793 / 19.04% → ~40,932
    • Aug 18: 6,076 / 14.84% → ~40,932
    • Aug 19: 3,333 / 8.14% → ~40,932

    I’m paying for the $200 Pro 20x tier, but recently the weekly quota has been going down extremely fast. After the latest reset, I casually ran some Codex/Work tasks and already used around 10% of the weekly limit.
    Would be great if someone from OpenAI could check the actual entitlement assigned to affected Pro 20x accounts.

  9. PureWhiteWu commented on Aug 20, 2026

    @PureWhiteWu
    PureWhiteWu
    on Aug 20, 2026

    Same issue here, I've subscribed to Pro 20x account, but seems receive only Pro 5x Codex usage recently.

  10. albertluo27 commented on Aug 21, 2026

    @albertluo27
    albertluo27
    on Aug 21, 2026

    Same issue here. I max out the usage this week. Do not use any reset or get any rest. The token usage shows a much lower weekly usage spending compare to last week

  11. gxdbk201 commented on Sep 9, 2026

    @gxdbk201
    gxdbk201
    on Sep 9, 2026 – with ChatGPT Codex Connector

    Another independent ChatGPT Pro 20x reproduction after a clean global reset, with multiple quota checkpoints and local rollout-*.jsonl telemetry.

    Account / reset baseline

    • Subscription: ChatGPT Pro 20x ($200 tier; confirmed in billing UI)
    • Surface: Codex / ChatGPT-account auth
    • Main model during the measured segment: GPT-6 Astra
    • Timezone below: UTC+8
    • A global reset had completed before the test.
    • At 2026-09-08 15:54, the usage UI showed 100% remaining.

    I then continued normal Codex use without manually applying another reset.

    Quota checkpoints

    Time (UTC+8) Weekly remaining Consumed from fresh window
    2026-09-08 15:54 100% 0%
    2026-09-08 21:30 75% 25%
    2026-09-09 01:16 50% 50%
    ~2026-09-09 06:37 25% 75%
    2026-09-09 10:18 7% 93%

    Exact local ledger for the first 25 percentage points

    For the clean 100% -> 75% interval, I parsed the relevant local rollout JSONL files and globally de-duplicated by response_id.

    Observed totals:

    total_tokens              106,661,534
input_tokens              106,282,051
cached_input_tokens       103,723,904
uncached_input_tokens       2,558,147
output_tokens                 379,483
reasoning_output_tokens       217,937   (subset of output)
unique responses                  358

    Approx. 97.6% of input was cached.

    Breakdown from the local records:

    GPT-6 Astra main-session activity   105,620,192 tokens
guardian / auto-review               1,041,342 tokens

    The weekly quota metadata in the local logs also recorded several intermediate points during the same fresh window. The observed token totals vs. weekly usage were internally consistent with the UI trend, e.g. approximately:

    5% used   -> 22.93M recorded raw tokens
6% used   -> 28.23M
7% used   -> 30.66M
10% used  -> 43.64M
11% used  -> 46.13M
12% used  -> 49.89M
25% used  -> 106.66M

    A simple raw-token extrapolation from these points implies roughly ~0.43B raw tokens for a full 100% window. I understand that subscription quota is not documented as a 1:1 raw-token bucket and that Astra/model/task weighting can differ, so I am not claiming that 0.43B is the authoritative server-side quota. The concern is the large change in effective capacity on the same Pro 20x account.

    Same-account historical baseline

    On this same Pro 20x account I have a prior heavy-use day (Aug 23) where the product analytics showed about 1.33B tokens for the day, corresponding to the scale I historically experienced when exhausting most/all of a Pro 20x weekly allowance.

    The new post-reset window therefore appears to provide only about ~32% of that historical raw-token scale before exhaustion, even though the subscription remains Pro 20x.

    Separate analytics reconciliation anomaly

    There is also a large mismatch between user-visible Analytics and the local response ledger. For 2026-09-07 (UTC+8):

    Analytics UI:                   ~5.536M tokens
local de-duplicated ledger:    287.589M tokens

    That is about a 52x difference. Changing the day grouping to UTC does not explain it (the local ledger is even larger under UTC grouping).

    In the local logs I also observed cumulative token_count.info.total_token_usage snapshots that can decrease/reset while per-response token_usage_record and thread_token_usage continue monotonically. I am not claiming the Analytics UI uses that field, but it may be a useful clue when investigating the reconciliation gap.

    Why this seems related to #38157

    The subscription itself still shows Pro 20x, but after a fresh reset the effective weekly usage denominator / accounting looks dramatically smaller than the same account's historical Pro 20x behavior.

    This could still be caused by server-side weighting or hidden/shared activity rather than an entitlement mis-provisioning. The local telemetry cannot determine that. Could the Codex team please reconcile this account's server-side ledger and verify:

    1. whether the account is actually provisioned with the Pro 20x weekly entitlement;
    2. the server-side quota/credit-equivalent charged for the measured 100% -> 75% interval;
    3. whether Astra cached input, background/guardian activity, retries, compaction, or hidden shared usage explains the discrepancy;
    4. whether any quota denominator/entitlement changed at the global reset;
    5. why Analytics can under-report the locally recorded response ledger by ~52x;
    6. whether incorrectly consumed quota can be restored if the server-side ledger confirms an accounting/provisioning error.

    Related: #38367 and the cross-report tracker #41220.

    I have the full local rollout JSONL set, exact checkpoint screenshots, and the Pro 20x billing screenshot available if maintainers need additional evidence. I intentionally did not post private project/conversation content publicly.

  12. gxdbk201 commented on Sep 9, 2026

    @gxdbk201
    gxdbk201
    on Sep 9, 2026 – with ChatGPT Codex Connector

    Follow-up with a full controlled 100% -> 0% measurement after my previous report in this thread (#issuecomment-5595278265). I also ran a separate full 5x-window measurement using the exact same local accounting method, so this provides a direct apples-to-apples comparison.

    Summary

    Using local Codex rollout-*.jsonl telemetry and globally deduplicating by response_id:

    • 5x full cycle (100% -> 0%): 51,320,415 raw tokens
    • 20x full cycle (100% -> 0%): 403,082,557 raw tokens
    • Observed raw-token ratio: 7.854x

    This is not a claim that the UI percentage must be token-linear; rather, I am asking the Codex team to clarify what backend unit/weighting the 5x and 20x windows actually use, because two complete controlled cycles under the same parsing method differ by ~7.85x rather than 4x.

    Accounting method

    For both cycles I used the same method:

    1. Count only token_usage_record.payload.usage records.
    2. Globally deduplicate by response_id across all session files/archives.
    3. For each unique response, calculate:
    raw total = input_tokens + output_tokens
    1. Do not add cached tokens, reasoning tokens, or thread_token_usage again, to avoid double counting.

    20x full-cycle measurement

    Controlled window:

    Start: 2026-09-08 15:54 UTC+8 — UI remaining: 100%
End:   2026-09-09 21:32 UTC+8 — UI remaining: 0%

    Final result:

    Unique response_ids: 1,358
Input tokens:         401,864,773
Output tokens:          1,217,784
Raw total:            403,082,557

    The last included usage record before the observed 0% point was at approximately:

    2026-09-09 21:28:55 UTC+8

    which is only a few minutes before the 21:32 exhaustion observation.

    Independent checkpoint cross-check

    Earlier in the same 20x cycle I captured the point where the UI had fallen from 100% to 75%. That segment had previously been independently calculated as:

    106,661,534 raw tokens

    When I later rescanned the complete dataset from the beginning, without manually inserting that result, the cumulative total at the 358th unique response_id reached exactly 106,661,534 tokens again (record time approximately 2026-09-08 21:29:49 UTC+8).

    So the prior checkpoint reproduced exactly, token-for-token, which is a useful validation that the parsing/deduplication method stayed consistent.

    The remaining 75% -> 0% portion was therefore:

    403,082,557 - 106,661,534 = 296,421,023 raw tokens

    Duplicate / boundary checks

    I also checked duplicate responses across the session archives:

    • Duplicate response_ids were globally deduplicated.
    • No duplicate response had conflicting input_tokens / output_tokens values.
    • Some duplicate records had different log timestamps, but identical usage values.
    • I specifically checked for response IDs replayed across the 15:54 start boundary or the 21:32 end boundary; none changed the result.

    The data set included the large long-running sessions plus the Sept 8/Sept 9 session collections and the final sessions covering the last hours before exhaustion.

    5x full-cycle measurement

    A separate complete 5x cycle was measured with the same accounting rules:

    5x, 100% -> 0%: 51,320,415 raw tokens

    Comparison:

    20x: 403,082,557
5x:   51,320,415
ratio = 7.854x

    A simple 4x projection from the measured 5x cycle would be:

    51,320,415 x 4 = 205,281,660

    whereas the observed complete 20x cycle was:

    403,082,557

    Questions for the Codex team

    Could you please clarify:

    1. Are the displayed 5x and 20x usage windows expected to scale linearly at all?
    2. What internal unit actually drives the remaining-percentage meter: raw tokens, weighted tokens, credits, compute, model-specific cost, or another resource unit?
    3. Are cached input, reasoning, context length, tool calls, retries/subagents, or background/server-side activity weighted differently between these windows?
    4. Is approximately 51.3M raw tokens for a complete 5x cycle and 403.1M raw tokens for a complete 20x cycle consistent with the intended entitlement/accounting configuration?
    5. Could the team compare these controlled windows against the authoritative server-side ledger and explain the ~7.85x effective raw-token difference?

    I have retained the original rollout JSONL archives and exact checkpoint evidence. I am intentionally not posting private project/conversation contents publicly, but I can provide the relevant telemetry if maintainers need it.

  13. extezin commented on Sep 14, 2026

    @extezin
    extezin
    on Sep 14, 2026 – with ChatGPT Codex Connector

    I’m seeing very similar behavior on my active ChatGPT Pro 20x account.

    Based on my own recent Work/Codex usage and token throughput, the effective capacity currently feels closer to roughly 6–8× Plus, not the expected 20×. This is an estimate rather than an exact multiplier, because Personal Analytics does not expose the underlying server-side quota units.

    What makes this concerning is that the weekly allowance is now depleting much faster than it did under comparable GPT-5.6 Sol / Work usage before the recent rollout and resets. The issue is not limited to GPT-6 Astra — I have also seen very rapid depletion on periods where my visible usage was predominantly GPT-5.6 Sol.

    OpenAI Support has confirmed that my account is an active Pro account and that the shared Work/Codex weekly window is reaching 100% used, but they are now reviewing the unusually rapid depletion rate.

    It would be useful if the team could verify the actual backend entitlement / quota multiplier assigned to Pro 20x accounts, not only the displayed plan name or plan_type value.

  14. jin44194649 commented on Sep 30, 2026

    @jin44194649
    jin44194649
    on Sep 30, 2026 – with ChatGPT Codex Connector

    Related current data point from Sep 29, 2026 (America/Chicago): on a $200 ChatGPT Pro account, the weekly meter reset/upgrade time was 18:09. The main ChatGPT Work session lasted about three hours (to ~21:09) and was used for eight chapters of writing/review. By 22:32 the weekly meter showed 89% remaining. I am not claiming the same root cause as this issue, but the effective consumption was unexpectedly high and the UI did not provide enough task-level attribution to reconcile the drop. I added the fuller timeline in #40527.

    Because this issue concerns provisioned capacity versus the advertised Pro tier, please also check whether newly changed $200 Pro subscriptions are receiving the intended Work/Codex weekly entitlement. My case alone does not establish a 5x/20x mismatch, but it is another current signal worth correlating.

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

    authIssues related to authentication and accountsbugSomething isn't workingrate-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