[BUG] Opus 4.7/4.8 token usage regressed 2-3x after update; Opus 4.8 also disconnects frequently

You've already done the hardest part — mapping it to a cluster rather than treating it as one bug. For what it's worth, an independent operator-side count lines up with yours: the token-burn / quota-burn reports concentrate sharply on the post–May 28 (v2.1.15x / Opus 4.8) window, and they cleanly separate into two different problems that are worth treating separately:
1. The token-per-turn regression (the "2–3×" part).
The most reliable way to confirm it on your side is to look at the distribution of output_tokens per turn, not the totals. Routine coding turns historically sit in roughly the 1–5k band; the regressed turns land at 10k+ (sometimes far higher) for the same work. Two ways to check:

• ccusage (free, community tool) for a quick per-session view, or
• read the session JSONL directly — each assistant turn records usage.output_tokens, so a one-line jq over ~/.claude/projects/**/<session>.jsonl tells you your median band immediately.

If your median is in the 10k+ band, the single most effective mitigation today is to route routine work back to Opus 4.7 (/model), which eliminates most of the delta in practice. Keep 4.8 for the tasks where you actually want the extra reasoning. This is a stopgap, not a fix — but it's a 30-second one.
2. The disconnect / mid-task stop (separate failure).
This co-occurs but is a different surface — there's a parallel cluster of mid-stream SSE stalls / pause-token emission on 4.7/4.8 and Sonnet 4.6 (e.g. #64900 has a repro). Worth tracking that thread separately rather than folding it into the cost regression, since a fix for one won't fix the other.
Why it's worth confirming your band before June 15 specifically: after the billing split, programmatic / Pool 2 usage meters at API rates. A 2–3× token regression that's "just" quota pressure today becomes a 2–3× dollar line item after the split, so it's worth logging your current median-per-turn now as a baseline you can compare against on June 16.
If it helps anyone triaging: a free output-token-spike-detector hook (MIT, in cc-safe-setup) flags individual turns that cross a threshold you set, which makes the regressed turns visible in real time instead of at the end of the bill — but the Opus 4.7 route + the JSONL audit above are the parts that actually move the number today.

I dug deeply into Claude Code prompt cache invalidations across multiple long-running sessions and found several reproducible patterns that may help explain the “random cache drops” many users are seeing.

Key findings from transcript-level audits (.jsonl analysis with jq tooling):

1. Cache invalidation is NOT only TTL-related

I confirmed the 5m sliding window is functioning correctly. HOT cache survives ~290s idle and dies shortly after ~300s. So many drops happening under 5 minutes are caused by prefix mutation, not expiration.

1. Parallel tool-use bursts can trigger full prefix rewrites

Large batches of tool calls in a single assistant turn consistently correlate with invalidation:

• 14× TaskCreate
• 22× TaskUpdate
• 27× TaskUpdate + Bash
• repeated 7–9× Edit bursts on large prefixes

Observed effect:
cache_read collapses from ~100k–300k down to the static floor (~23k), while cache_creation_input_tokens spikes massively.

1. Async sub-agent returns are especially important

This appears to be a major hidden invalidation source.

When an async agent/background bash completes AFTER the assistant turn has ended, Claude Code injects the notification through the same queue-operation → user path used for queued user messages.

That forces a resume request and rewrites the conversational tail:
Example:
read 105.6k → 23.5k
write 1.9k → 85.6k

However:

• if the async notification arrives MID-TURN while the assistant is still streaming/tool-calling, there is NO drop.
• synchronous agents returning inline as tool_results also do NOT drop.

This reconciles the previously confusing “dispatch is free but sometimes agent returns are expensive” behavior.

1. Attachments / PR links / queued user input mutate the prefix

Another major source of “random” invalidations:

• attachment expansion
• PR link expansion
• queued user messages while the assistant is still working

These consistently correlate with HOT-cache rewrites even under the 5m window.

I also built jq-based tooling to classify invalidations by:

• TTL expiry
• burst parallelism
• injection events
• compaction
• async resume behavior

The most actionable finding for the Claude Code runtime team is probably:
“queue-operation/user-style injections reposition cache breakpoints and invalidate conversational tails.”

This seems especially relevant for:

• async agents
• background bash notifications
• attachment expansion
• PR-link enrichment

Happy to provide sanitized transcripts / jq scripts if useful.

More info:
#63930
#64901

I can confirm this. I work in roughly the same way as before, and my subscription's 5-hour limit used to be more than enough with plenty of room to spare. Now I can hit the entire 5-hour limit in just 2–3 hours, even without working on particularly heavy or complex tasks.

I'm having the same problem. My workflows haven't changed in weeks -- I never hit usage limits. Suddenly overnight, I'm burning through tokens and hitting limits. This sucks. Pls fix.

The details:

• I'm on Claude Max plan, Opus 4.7 1M context, macOS.
• I upgraded from 2.1.150 to 2.1.152. My historical per-turn cost across 2.1.118–2.1.150 ranged 22K-40K billed tokens. Two sessions today on 2.1.152 are anomalous — one averaging 53K/turn, another 120K/turn. Across 2.1.118–2.1.150 (months of data) my per-turn cost never exceeded ~40K. Other 2.1.152 sessions today are in normal range, so it's not across-the-board — feels like a regression that triggers under specific conditions.

This is the missing half of the "2–3× tokens" puzzle — your prefix-mutation finding explains the invalidation, and the cache pricing explains why an invalidation shows up as a 2–3× cost spike rather than a 2–3× token-count spike.
The multipliers (relative to base input price):

• cache read ≈ 0.1× base input
• cache write (creation) ≈ 1.25× base input (5-minute TTL; 2× for the 1-hour TTL)
• uncached input = 1.0×

So when the prefix is stable, a long conversation's history bills at ~0.1× every turn. The moment something mutates the prefix, that whole span stops being a read (0.1×) and becomes a re-creation (1.25×) — roughly a 12× jump on the cached span, and since the cached history dominates a long session's input, the turn total lands in the 2–3× range you measured. The token count barely moves; the price does. That's exactly why cache_read_input_tokens collapsing to near-zero (with cache_creation_input_tokens spiking) is the signal to watch, not input_tokens.
Your two findings map cleanly onto the one invariant — caching is a strict prefix match; any byte change anywhere in the prefix invalidates everything after it, and the render order is tools → system → messages:

1. Sub-5-min drops = prefix mutation, not TTL — correct. The 5-min TTL refreshes on every read, so a HOT prefix that's being used can't expire under you. A drop inside the window means the serialized prefix changed.
2. Parallel tool bursts trigger full prefix rewrites — this is the prefix-match invariant biting. If a batch of tool_use/tool_result blocks lands in a different order, or any earlier block's bytes shift, the breakpoint no longer matches the prior prefix and everything from the mutation point re-creates. There's also a 20-block lookback limit: a breakpoint only walks back ~20 content blocks to find a prior cache entry, so a single turn that adds >20 blocks (14× TaskCreate, 22× TaskUpdate, etc. — exactly your repro) can push the previous cached block out of range and silently miss even without reordering.

Mitigations that follow directly:

• Keep the system prompt and tool list byte-stable (no datetime.now(), no per-request IDs in system; serialize tools deterministically) — anything volatile up front re-creates the entire downstream cache.
• For long tool-burst turns, an intermediate cache breakpoint every ~15 blocks keeps the next turn within the 20-block lookback.
• Verify with usage: total prompt = input_tokens + cache_creation_input_tokens + cache_read_input_tokens. If cache_read is near-zero across identical-prefix turns, diff the rendered prefix bytes between two requests to find the invalidator.

(Source for the multipliers and the lookback/render-order behavior: Anthropic's prompt-caching docs — the 0.1× read / 1.25× write figures and the prefix-match + 20-block-lookback rules are documented, so this isn't guesswork about model internals.)

Any Updates?

I was on vacation for a few days now and hardly worked, today and yesterday, worked normally again and my 5 hours limit is used up in 2-3 hours, and that has never happened to me before.

Does anyone know what the current state of affairs is?

Edit: I use MacOS Claude Code Desktop!

Adding my case with concrete billing data from the Anthropic Console.

Context: I've been using Claude Code for 3 months. Monthly spend was consistently well under $100 with Opus 4.7 / Sonnet 4.6. Same type of work throughout — nothing changed on my side.

What happened after the Opus 4.8 / Sonnet 5 rollout:

• July 1–21, 2026: near-zero spend (a few dollars total, mostly Sonnet 4.6)
• July 23: ~$90 in a single day, almost entirely Opus 4.8
• July 24: $72.52 in one day, broken down as:
• Sonnet 5: $58.65
• Opus 4.8: $13.81
• Haiku 4.5: $0.06

Total: ~$165 in roughly 48 hours, doing the same tasks that previously cost cents per day.

The most striking data point: Sonnet 5 alone burned $58 in a single day. Sonnet is supposed to be ~5–6x cheaper per token than Opus. To spend that in Sonnet means millions of output tokens generated — consistent with the reports in this issue about hidden thinking bloat, context cache waste, and repeated tool-result fetching.

Notably, Haiku 4.5 in the same day cost $0.06, which is the reference point for how the new generation should behave.

Requests:

1. Root cause investigation and fix for the token inflation across the 4.8 / Sonnet 5 generation (not only Opus 4.8)
2. A hard user-configurable spend cap in Claude Code itself (not just in the Console) that halts the session before another $80/hour event
3. Transparent per-session token accounting broken down by hidden thinking vs. visible output vs. tool-result re-fetching, so users can see where the burn is happening

Screenshots from the Anthropic Console attached.

<img width="1219" height="621" alt="Image" src="https://github.com/user-attachments/assets/e16ae053-31fa-48dc-8d63-948637bb8a4d" />

<img width="1321" height="735" alt="Image" src="https://github.com/user-attachments/assets/4aa1c749-1b72-4339-bea5-11245b1e7075" />