Repository navigation
GPT-5.6 Sol Medium depletes Pro 5-hour usage allowance extremely quickly #32250
Description
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
- Use Codex desktop with a ChatGPT Pro subscription.
- Select GPT-5.6 Sol and Medium reasoning effort.
- Record the remaining 5-hour allowance.
- Run a short research conversation involving a few GitHub searches.
- Continue with several very short follow-up messages without additional tool calls.
- 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.
Activity
github-actions commentedon Jul 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
gitpyblog commentedon Jul 14, 2026
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 commentedon Aug 1, 2026
hourly-token-usage.csv
session-token-audit.md
Same pattern here, but on GPT-5.6 Sol at
ultraeffort 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_countevents), so they are client-side and I am not claiming they equal what the billing system counted.What the log shows
gpt-5.6-sol/ultratoken_countevents)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
ultraeffort 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:
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
token_countstream be expected to approximate the weekly figure at all? If not, is there a client-visible counter that does?Happy to share a redacted hourly CSV and the per-request delta table if that is useful. Possibly related: #32606.
token-deltas.csv