GPT-5.6 Sol Medium depletes Pro 5-hour usage allowance extremely quickly

[Oguz-Yueksel]

What version of Codex is running?

Codex desktop app (macOS). Exact build number is not currently visible in the usage dialog.

What subscription do you have?

ChatGPT Pro (€200/month).

Which model were you using?

GPT-5.6 Sol with reasoning effort set to Medium.

What issue are you seeing?

The 5-hour usage allowance is being depleted at an unexpectedly high rate during a very short conversation.

In one short task, the remaining 5-hour allowance dropped from 87% to 76% (11 percentage points). The task consisted mainly of discussing Codex usage limits and performing a small number of GitHub searches. After the initial research, several trivial follow-up messages—without any additional tool calls—each appeared to consume approximately 1 percentage point.

This is especially unexpected because the same user's prior workflow with GPT-5.5 at xhigh reasoning did not show comparable consumption. GPT-5.6 Sol was deliberately used at Medium to reduce usage.

Screenshots were captured showing:

• 78% remaining, reset at 02:22
• 76% remaining, reset at 02:22

Steps to reproduce

1. Use Codex desktop with a ChatGPT Pro subscription.
2. Select GPT-5.6 Sol and Medium reasoning effort.
3. Record the remaining 5-hour allowance.
4. Run a short research conversation involving a few GitHub searches.
5. Continue with several very short follow-up messages without additional tool calls.
6. Recheck the usage dialog after each message.

Expected behavior

A short conversation with Medium reasoning should consume a small and predictable portion of the Pro 5-hour allowance. Trivial follow-up messages should not each consume approximately 1 percentage point.

Usage accounting should also expose enough detail to distinguish model multiplier, input/context tokens, cached input, reasoning tokens, and tool-call overhead.

Actual behavior

• Remaining allowance fell from 87% to 76% during one short task.
• Even short follow-ups without new tool calls appeared to reduce the allowance by about 1 percentage point each.
• The UI provides no breakdown explaining the consumption.

Additional information

Possible areas to investigate:

• GPT-5.6 Sol usage multiplier
• prompt-cache misses or lack of context reuse
• repeated charging of the full accumulated tool context
• reasoning-token accounting
• incorrect or delayed usage reporting

The contrast with GPT-5.5 xhigh under the same user's normal workflow suggests this is not explained by reasoning effort alone.

[github-actions]

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

• Codex quota drains extremely fast after ChatGPT update when generating large PPT content #32176
• Perceived regression in Codex quality and higher token consumption with GPT-5.6 #32161
• Codex five-hour usage limit appears to have been consumed abnormally fast #31898
• (No Agent use) After slow-response bug was fixed a few days ago, usage limit burns faster than before, and I only use "slow" mode #31199
• Codex Pro 5x quota drops 2-3% for a single normal prompt, equivalent to 10-15% of Plus 5-hour quota #30909

Powered by Codex Action

[Oguz-Yueksel]

Additional measurement from the same task:

• The 5-hour allowance has now fallen further to 72% remaining, from 87% at the beginning — a total decrease of 15 percentage points during this short conversation.
• The reset time remained 02:22.
• The weekly allowance currently shows 96% remaining.
• Model remains GPT-5.6 Sol, reasoning effort Medium, on ChatGPT Pro (€200/month).
• The additional activity since the earlier measurement consisted primarily of short conversational follow-ups and reviewing related GitHub issues.

This suggests the unusually rapid depletion is concentrated in the 5-hour allowance. A screenshot showing 72% five-hour / 96% weekly remaining is available.

[gitpyblog]

Hi OpenAI Support,

I'm reaching out about a token/usage consumption issue I've experienced since the GPT-5.6 (Sol/Terra/Luna) release.

Before this release, I was able to plan my weekly workload around my usage allocation and consistently got results I was satisfied with. I understand a more capable model will naturally consume more tokens per task, and I've been experimenting with different settings (model variant, reasoning effort) to adapt.

However, in one specific session (ID: 019f60b9-bd71-77a1-ab1b-2b5bde36d335), I used nearly my entire weekly token allocation on a task that should have been simple — generating a basic prototype webpage. The session took several hours and returned a very mediocre result, when a task of this scope should normally take only a few minutes.

Could you please look into this session and let me know whether this reflects a known issue with GPT-5.6's usage accounting or reasoning-effort behavior, or whether something is misconfigured on my account? I'm aware other users have reported similarly disproportionate usage since launch, so I'd like to understand whether this is an isolated case or a broader rollout issue.

[bd7-needle]

hourly-token-usage.csv
session-token-audit.md

Same pattern here, but on GPT-5.6 Sol at ultra effort against the weekly allowance rather than the 5-hour one.

I pulled the numbers below from a read-only parse of my local Codex session log (token_count events), so they are client-side and I am not claiming they equal what the billing system counted.

What the log shows

Model / effort	gpt-5.6-sol / ultra
User turns	4
Model requests (token_count events)	1,031
Wall-clock span of Sol activity	~4h 45m
Sum of per-request token deltas	135,338,189
Mean per request	131,396
Median per request	129,896
Largest single request	240,204
Reported context window	258,400
Weekly indicator over the session	59% used → 100% used

Input breakdown across the session: 136.8M input, of which 134.1M was cache-read and 2.7M non-cached; 414K output.

What I think is not the bug

I want to get ahead of the obvious answer. 1,031 requests × ~131K context ≈ 135M, so the headline token figure is just the arithmetic of a long agentic loop re-sending its context on every tool call. Cache hit rate was ~98%, which means prompt caching was working, not failing. I am not filing this as "the token counter is wrong."

The two things I do think are worth looking at are below.

1. Four user turns produced 1,031 model requests

Two turns account for most of it: one ran 419 requests over ~113 minutes, another 294 requests over ~72 minutes of active time. At ultra effort with a ~130K working context, each of those turns is spending 40M+ tokens without returning to the user.

Is there any per-turn ceiling — request count, cumulative tokens, or elapsed time — at which the loop is supposed to stop and check in? If there is, it did not trigger. If there is not, a single turn can consume an arbitrary fraction of a weekly allowance and there is no point at which the user can intervene.

2. Weekly percentage does not track processed tokens within the same session

Hourly totals (UTC+3), same model, same effort, same session:

Hour	Processed tokens	Weekly indicator	Points	Tokens per point
14:00	31,662,972	59% → 68%	9	3.52M
15:00	22,944,370	68% → 71%	3	7.65M
16:00	26,530,225	72% → 82%	10	2.65M
17:00	24,047,143	82% → 97%	15	1.60M
18:00	30,153,479	97% → 100%	3	10.05M

That is a ~6× spread in tokens per percentage point with no configuration change between hours. The 15:00 hour ends at 71% and the 16:00 hour opens at 72%, so the indicator is also not updating in lockstep with the events.

I understand hour boundaries cut across turns and that cached and non-cached input are almost certainly weighted differently — but the non-cached and output shares are fairly stable across these hours too, so weighting alone does not obviously explain the spread. Right now the weekly figure is not reproducible or even approximable from the client-side log, which makes it impossible for a user to see a problem coming.

Questions

1. Is there a documented per-turn stop condition for agentic loops (requests, tokens, or time)? If not, is one planned?
2. How are cache-read input, non-cached input, output, and reasoning tokens each weighted toward the weekly allowance?
3. Should the client-side token_count stream be expected to approximate the weekly figure at all? If not, is there a client-visible counter that does?
4. Is there any warning or soft threshold before the weekly allowance reaches 100%? None appeared here.

Happy to share a redacted hourly CSV and the per-request delta table if that is useful. Possibly related: #32606.

token-deltas.csv