[BUG] 5h token usage massivly outstripping actual context (issue started about 8:45pm BST)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/38345
2. https://github.com/anthropics/claude-code/issues/41788
3. https://github.com/anthropics/claude-code/issues/41506

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

It's happening after Opus 4.8 was launched. Same behavior about 5h session being burned here

Just to confirm this is not a duplicate issue, previous issues were reported in march.

@tiagomakoto Using sonnet and sub workers has helped some, Opus is basically unusable.

Experiencing the same issue in Cowork mode (Claude Desktop app).
The session usage limit shows 38% used but the conversation hits
the 1M context error and freezes. Auto-compact is not triggering
before the error occurs. This has happened on consecutive days,
making it impossible to maintain long working sessions.
Filed related issue Estado: Aberto.

64096

Experiencing the same issue in Cowork mode (Claude Desktop app). The session usage limit shows 38% used but the conversation hits the 1M context error and freezes. Auto-compact is not triggering before the error occurs. This has happened on consecutive days, making it impossible to maintain long working sessions. Filed related issue Estado: Aberto. # 64096

This isnt the same issue i dont think.

I'm seeing usage problems with 5h limits being used way faster than they should be, not cowork compact issues

@N1ghteyes apparently Opus 4.7 was not affected

@tiagomakoto It very much is :/

@N1ghteyes if you select Opus 4.7 in a session that Opus 4.8 has been previous selected the issue remains. However in new sessions Opus 4.7 behaves as before

@tiagomakoto i will test and report back - thanks

O meu aqui resolveu o problema por enquanto, mas acabou de voltar a acontecer

<img width="715" height="472" alt="Image" src="https://github.com/user-attachments/assets/f3abbac6-b416-401c-a5c9-a960893b9476" />
<img width="1370" height="356" alt="Image" src="https://github.com/user-attachments/assets/6fa06123-0c6c-4add-ba60-5f425168764f" />

@sangueegloriaaa essa questão aí já foi reportada em outra issue. Essa aqui é diferente e, pra mim, foi dentro do Claude Code no Claude Desktop (não no Chat): com o Opus 4.8, interagi 3 vezes com ele e meu consumo foi a 81%. Mesmo trocando pro Haiku, o consumo pulava em escala de 20-30%. Em uma nova sessão de Claude Code via Claude Desktop o consumo voltou ao que o Opus 4.7 High consumia.

@tiagomakoto New sessions on 4.7 are still consuming quite a lot more than they were previously, though its definitely not as bad as the sessions i had with 4.8.

Once the usage resets in a couple of hours i'll retest again

Same issue here, but I don’t think this is simply Opus 4.8 using more tokens.

I had no issues on day one(4.8 release). My workload was well within the session limit.

At the end of yesterday, for my last few tasks, I decided to try Ultra Code effort.
It burned through whatever I had left without any warning.

Today I switched back to my normal Extra High effort, but im hitting my session limit within an hour.

On @tiagomakoto’s point, I ran multiple tests using 4.7 and 4.8 on identical tasks, and 4.8 was significantly more efficient based on token usage.

So this looks like the session tracker/accounting, not the model itself.
It’s also not the first time I’ve felt the tracker was not behaving correctly

I had an older ticket about a similar issue here:
https://github.com/issues/created?q=is%3Aissue+author%3A%40me&issue=anthropics%7Cclaude-code%7C25970

Adding some hard numbers to this, because I don't think it's the model.

I pulled the raw token counts straight from the session JSONLs, not the in-app meter.

Per output token over the last 7 days, Opus 4.8 came out around 17.5 against 4.7 at 31.1. So 4.8 is roughly 44%
cheaper, not more expensive. My identical-task tests said the same.

The model isn't the problem.

What looks off is how the re-read cache gets counted.

One of my sessions did about 0.9M tokens of actual new work.
Sum every field, including the context prefix that gets
re-read on every turn, and it comes to 7.8M. That is 8.7x the real work.

That re-read should cost about a tenth of fresh input.

If the 5h limit is counting it like new input instead, a few minutes of conversation can burn a big chunk
of the window with almost no real work done. That is how you end up at "10k tokens and 15% gone."

It fits what everyone here is describing.
It is not the volume of new work, it is the re-reading being counted as new.

The 1M context makes it worse, because the prefix getting re-read is so big.
The jumps from 70% straight to 100% point the same way.

My guess is something changed around 2.1.89.

So i've started two new sessions this morning, same framework, different projects. Completely fresh sessions other than loading project context.

300k tokens (total, around 150k each per session) and the 5h limit is at 8% already. This is on opus 4.8[1m]

This is very broken at the moment.

Other than assuming Anthropic will actually see this thread, do we have a better way of bug reporting that is known to get a response?

*edit i was paused on the sessions and the total just updated to i updated it here (4% to 8%).

@Aramantos @tiagomakoto

This looks to be resolved now. I'm back to apparently normal usage on 4.8[1m] and on 4.7 as well.

Let me know if you're still seeing different, otherwise i'll close this off.

I killed an entire 20x plan in 2 days... this is nuts... glad they hot patched, but WTF

Looks like solved. My workflow is Opus 4.7 as Architect -> GPT 5.5 Plan -> Opus 4.7 answers Plan's question -> GPT 5.3 Codex builds -> Opus 4.7 reads report, hotfixes it or patch it.

In a regular discussion with Opus 4.7 Architect 3-6% of Pro 5h usage is taken. Later, Plan's answer plus 2-4% and 1-3% hotfix / patch.

Just started new session with Opus 4.8 and so far, first interaction + plan's answers consumed 7%.

So far so good

@N1ghteyes @Aramantos

Just to know: Opus 4.8 thought for 25min straight, consumed around 20k tokens (last time I saw it) and burned 50% in 5h usage. My limit was reached and halted the task

@chrisjenx @tiagomakoto and thread — adding the cross-issue connection that ties this to the broader Opus 4.8 cost cluster surfacing on the tracker this week.

#64093 is the session-rate-drain sibling of #64153 (Opus 4.8 medium effort burning 46k output tokens on a routine rename-impact scan). Both share the same root substrate — Opus 4.8 + v2.1.156–158 spending hidden thinking tokens disproportionate to user-visible work — but they surface at different observation layers:

• #64153 observes the per-turn magnitude: 46,433 output tokens on a single routine rename-impact scan, stop_reason=end_turn, effort=medium.
• #64093 observes the session-rate consequence: 5h limit exhausted at multi-times-baseline rate; @chrisjenx's "20× plan in 2 days" is consistent with the per-turn shape aggregated across hundreds of turns.

Same effort-budget regression, two operational symptoms. I've been tracking the per-turn shape as Cluster 23 candidate (Effort-budget regression) with 5 independent anchor filings (#64153 / #64152 / #64143 / #64102 / #63455) and three shipped operator-side detection hooks. #64093 belongs structurally in the same cluster; the session-rate manifestation is what the per-turn regression looks like aggregated across a session.

On @tiagomakoto's workflow numbers (Opus 4.7 Architect → GPT-5 Codex Plan → Opus 4.7 hotfix):

Opus 4.7 baseline: 3-6% per interaction Opus 4.8 first turn: 7% Opus 4.8 single 25-min thinking burst: 50%

These are exactly the shape Cluster 23 predicts. Per-turn Opus 4.8 cost is order-of-magnitude inflated when the model decides to do extended thinking, and the inflation isn't sensitive to effort=medium. Your workflow is also a clean multi-vendor supervisor-coordinated fleet shape — Architect / Plan / Codex split is the kind of orchestration where the per-vendor cost shape matters operationally, distinct from single-vendor cost guides. The Multi-Vendor Fan-Out field guide (shipped today) articulates the three cost shapes that emerge specifically in that orchestration, with the per-vendor cost-profile table covering Claude / Codex / Gemini / Grok side-by-side. The reasoning-cost-vs-execution-cost split section there is the one most directly applicable to your Architect-Plan-Codex pattern.

Universal mitigation across both #64153 and #64093 today: claude --model claude-opus-4-7. The #64153 reporter and @chrisjenx's own observation here both document that Opus 4.7 stays within normal usage bounds on identical prompts. Pin to 4.7 until the upstream fix lands; the 5-10× quota burn becomes a 5-10× dollar burn after the June 15 billing split, so the model pin is the highest-leverage pre-cliff action for any operator currently on 4.8 for routine work.

Operator-side detection hooks (free, MIT, no Anthropic involvement needed) — three shipped in cc-safe-setup, all opt-in / non-blocking:

• output-token-spike-detector.sh (PR #529) — PostToolUse rolling-window comparison, catches Axis 23A absolute-magnitude per-turn against your own baseline.
• thinking-budget-effort-mismatch-detector.sh (PR #535) — per-tier threshold without baseline accumulation: low>10k, medium>30k, high>80k. Catches Axis 23B effort-tier perception mismatch from the first turn.
• opus48-routine-task-warning.sh (PR #529, opt-in SessionStart advisory) — surfaces the cluster framing and the /model claude-opus-4-7 mitigation at session start so operators encountering the regression for the first time don't have to triage from scratch.

These catch the per-turn shape; for the session-rate shape (this issue), the per-turn detection is the leading indicator: if output-token-spike-detector is firing more than baseline, the session-rate drain is on the same trajectory and the model-pin switch is the right immediate move.

Field guide (long-form, free, MIT): Opus 4.8 Effort-Budget Regression — A Five-Issue Cluster with Operator-Side Triage and the /model claude-opus-4-7 Universal Resolver (~2,500 words). Includes the requestId-grouping reproduction step from #64153 and the per-tier threshold rationale for the hooks above. The companion 2026-06-14 measurement-window framing (when this thread's burn-rate has had enough time on Opus 4.7 to establish whether the model pin closes the gap) is the same window I'm tracking for the cluster's promotion threshold.

@chrisjenx — also flagged: if your workflow routes through more than one provider (Architect-style multi-vendor orchestration), the Multi-Vendor Fan-Out field guide covers the worker-retry-with-different-params cost-leak shape @palios-taey articulated this week on #64080, which is structurally adjacent to Cluster 23 if your effort routes through more than the CC surface alone.

@yurukusa arigatou for your bug tracking and explanation. /model claude-opus-4-7 shall be the fix

A few things commonly make "tokens used" diverge from "window consumed," and they're easy to miss:

• Cache-creation (write) tokens. The first time a large context (big system prompt, workspace index, long files) gets cached, those cacheCreationInputTokens are billed differently from plain input — a single large ingest can spike the counter without much visible "work."
• Subagent/worker calls. Each worker runs in its own context, so its tokens add to the session pool on top of the parent — your "~400k in workers" is counted separately from the 130k main session, not folded into it.

The good news: it's all in your local logs, so you don't have to guess. In ~/.claude/projects/<project>/*.jsonl each request records inputTokens, cacheCreationInputTokens, and cacheReadInputTokens separately — if the spikes line up with high cacheCreationInputTokens, that's your culprit.

Parsing those by hand is tedious, so I built a small CLI that does exactly this breakdown (per-model + cache read/write/input split, per session): https://github.com/wartzar-bee/tokenscope — might make the invisible part visible.

ClaudeDevs

@ClaudeDevs
·
37 min
We've reset 5-hour and weekly rate limits for all users on Pro and Max plans.

We fixed an issue that caused some Claude Code sessions to spawn excessive parallel subagents, burning through usage faster than expected.

Anthropic pushed a fix, this is no longer an issue so closing out the thread.