[Bug] ChatGPT Plus quota consumption increased ~9x between comparable Codex App tasks

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.51511

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

ChatGPT Plus quota consumption in Codex App increased dramatically between two comparable consecutive tasks.

On 2026-08-31, a ~24-minute design task consumed 8 percentage points of my 5-hour quota.

On 2026-09-01, a very similar ~53-minute design task consumed 75 percentage points of my 5-hour quota.

Local Codex session telemetry shows that input token usage increased only from 13.56M to 22.04M (~1.63x), while 5-hour quota consumption increased from 8% to 75% (~9.4x).

Both tasks were part of the same design workflow, used 4 active threads, and had very high cached-input ratios.

The second task also increased my weekly quota usage from 21% to 32% in a single run.

What steps can reproduce the bug?

Environment

• Codex App: 26.825.51511
• ChatGPT subscription: Plus
• OS: Windows x64
• Local Codex CLI/runtime: 0.151.0
• Model observed in local Codex session JSONL: gpt-5.6-sol

Reproduction

I was working on consecutive sections of the same software design document in the same Codex workflow.

Task 1 — Section 5.10

Prompt:

接着做5.10的设计

English meaning: "Continue the design of section 5.10."

Time:
2026-08-31 19:08:43 to 19:31:56 local time

Duration:
~23m57s

Local session telemetry:

• Active threads: 4
• token_count updates: 97
• Input tokens: 13,555,743
• Cached input tokens: 13,231,104
• Non-cached input tokens: 324,639
• Output tokens: 43,307
• Total tokens: 13,599,050
• Cached input ratio: 97.61%

Quota change:

• 5-hour usage: 58% -> 66%
• 5-hour delta: +8 percentage points
• Weekly usage: 19% -> 21%
• Weekly delta: +2 percentage points

Task 2 — Section 5.11

Prompt:

继续5.11的设计

English meaning: "Continue the design of section 5.11."

Time:
2026-09-01 08:21:37 to 09:13:10 local time

Duration:
~53m26s

Local session telemetry:

• Active threads: 4
• token_count updates: 194
• Input tokens: 22,037,379
• Cached input tokens: 20,967,936
• Non-cached input tokens: 1,069,443
• Output tokens: 89,572
• Total tokens: 22,126,951
• Cached input ratio: 95.15%

Quota change:

• 5-hour usage: 0% -> 75%
• 5-hour delta: +75 percentage points
• Weekly usage: 21% -> 32%
• Weekly delta: +11 percentage points

Comparison

Input tokens increased only:

13.56M -> 22.04M

This is approximately a 1.63x increase.

However, 5-hour quota consumption increased:

8 percentage points -> 75 percentage points

This is approximately a 9.4x increase in quota consumption.

Very roughly normalized by locally recorded input tokens:

• Task 5.10: ~0.59 quota percentage points per 1M input tokens
• Task 5.11: ~3.40 quota percentage points per 1M input tokens

That is approximately a 5.8x difference in quota consumption per locally recorded input token.

Weekly quota also increased disproportionately:

• Task 5.10: +2 percentage points
• Task 5.11: +11 percentage points

The weekly usage is continuous across the two tests:
Task 5.10 ended at 21%, and Task 5.11 started at 21%.

For Task 5.11, the first recorded 5-hour usage was 0%, and it reached 75% during this single task.

I understand that local token counts may not map linearly to ChatGPT subscription quota. However, this difference appears much larger than the difference in workload and is reproducible in the local session telemetry.

Session ID:
01a017fb-2df4-76e0-a295-cfb279dfb511

At the end of the affected task, /status showed approximately:

• 5-hour quota remaining: 25%
• Weekly quota remaining: 68%
• Context remaining: 67% (~85,896 / 258K used)

What is the expected behavior?

Quota consumption should remain reasonably consistent for comparable workloads using the same subscription and model.

I do not expect quota usage to map linearly to locally recorded token counts. However, an approximately 1.63x increase in input-token workload should not result in an approximately 9.4x increase in 5-hour quota consumption without some corresponding change in workload, model, or documented quota behavior.

I would expect the second task to consume more quota because it ran longer, but not 75% of the entire 5-hour quota in a single comparable design task.

Additional information

No response

Start with the local Codex session JSONL and the /status output for session 01a017fb-2df4-76e0-a295-cfb279dfb511, comparing the two recorded tasks, token counts, and quota changes. The issue is done when the discrepancy is reproduced and the quota accounting behavior is corrected or clearly explained.