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

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

• #32176
• #32161
• #31898
• #31199
• #30909

Powered by Codex Action

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.

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.

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