[BUG] Opus 4.8 medium effort spends 46k output tokens on hidden thinking for a simple coding turn

this sounds similar to the one I opened here - https://github.com/anthropics/claude-code/issues/63935

one potential thing to try if you can is to go back to the 157 version, if its the same issue it fixed it for me....

Thanks for the pointer. I checked my transcript against #63935.

The same session does have some 2.1.158 signals from that issue:

• Wasted call — file unchanged since your last Read
• probe commands like echo alive
• wait/probe commands using sleep ...; echo ...

So yes, #63935 may be part of the same 2.1.158 / Opus 4.8 cluster.

The request I filed here still has a different shape. For the specific high-token request:

• stop_reason=end_turn
• effort=medium
• output_tokens=46,433
• no API 400
• no max_tokens
• no failed retry loop
• visible work was just two normal grep/Bash commands for a small rename-impact scan

So I don't think this should be collapsed into the duplicate-read/probe-loop issue alone. The failure I'm reporting is that a routine coding turn, under medium effort, still burned ~46k output tokens mostly as hidden thinking.

I'll try 2.1.157 in a fresh session and report back if that removes the hidden-thinking spike.

Filing this same shape from the cc-safe-setup tracking side — your transcript fits a cluster I've been tracking as Cluster 23 candidate (Effort-budget regression) under Opus 4.8 / 2.1.x. Your #64153 is the cleanest anchor for the specific shape: routine coding turn, effort=medium, completed normally with stop_reason=end_turn, but spent tens of thousands of output tokens largely on hidden thinking.
Distinct from #63935 in the way you already noted: #63935 is the API-400 / wasted-call loop shape; your filing is the completed-but-overspending shape. Same Opus 4.8 substrate, different failure mode. Sibling filings I've grouped here that share the routine-task-with-disproportionate-output-tokens signature include #64152 (Opus over-engineers simple rename, 15+ tool calls including redundant re-reads), #64102 (cited by you), and #63455 (Opus 4.8 routine sessions burning 40-50k tokens without completing work). The transcript-grouping-by-requestId step in your reproduction is the cleanest diagnostic across these filings — that's the one I've been pointing other reporters at.
Path 1 (lowest-friction workaround), repeatedly confirmed by reporters across the cluster: /model claude-opus-4-7. Multiple operators have reported routine-turn output_tokens dropping back to the Opus 4.7-shaped range immediately on switching, including under effort=medium. This is symptom-suppression at the model layer, not a fix, but for a coding-loop workflow it gets you out of the 46k-output-tokens-per-turn regime today.
If you want operator-side detection (rather than only-after-the-bill), three hooks in cc-safe-setup fire on the Cluster 23 signature:

• examples/opus48-routine-task-warning.sh — PostToolUse hook warning when output_tokens on a routine tool-use turn exceeds an Opus-4.7-shaped baseline
• examples/opus48-thinking-wedge-advisor.sh — flags the thinking-budget wedge specific to Opus 4.8 routine turns
• examples/effort-tracking-logger.sh — logs effort setting alongside output_tokens for medium-vs-actual delta audit over time

All opt-in, no behavior for non-Opus-4.8 sessions, fail-soft.
Longer write-up of the cluster (the routine-task signature, the effort-tier-vs-output-tokens mismatch table, the four sub-axes): Cluster 23 field guide.
Your filing's specific contribution to the cluster: the cache_read_input_tokens: 91877 / output_tokens: 46433 / stop_reason: end_turn triple with the transcript-by-requestId reproduction is the cleanest evidence of the cost-without-failure shape — clearer than the API-400 sibling cluster, and useful for distinguishing "this completed and still cost a lot" from "this errored and retried a lot". Thank you for filing it with the usage breakdown intact.

Does that bug explain what seems like insane token spend? I burnt through a 20x plan in 2 days which normally takes at least 4-5 days when going hard

@chrisjenx — Short answer: yes, very likely. The math fits Cluster 23 regression closely.

Your burn rate vs. the regression magnitude. Your "20× plan in 2 days vs 4-5 days normal" is a ~2-2.5× session-wide burn-rate inflation. The Cluster 23 anchor here (#64153) measures 46,433 output tokens on a routine rename-impact scan that would normally land 2-3k — a 15-20× per-turn regression on hidden thinking. You don't need every turn to regress to hit a session-wide 2-2.5×; even a subset of routine turns running 5-15× over baseline pulls cumulative into your range.

The pattern that distinguishes Cluster 23 from "more tokens because the task is harder" is routine turns under medium effort completing normally:

• stop_reason=end_turn (not retried, not a wedge)
• effort=medium (you weren't asking for deep reasoning)
• Mostly hidden thinking, not user-visible output
• Same prompts on Opus 4.6/4.7 produce 2-3k output, not 40-50k

If your sessions had many small/routine turns and you were on claude-opus-4-8, your burn pattern is consistent with what 5 independent operators have now filed under this shape: #64153 (this issue, the cleanest anchor), #64152, #64143, #64102, #63455.

Universal mitigation today (no waiting for upstream): claude --model claude-opus-4-7. The #64153 reporter's own comparison documents that Opus 4.6/4.7 do not exhibit the same surge on the same prompts. Treat 4.7 as the working baseline until upstream lands a fix; keep 4.8 available for tasks where you actively want the cost of deep reasoning.

June 15 implication. After June 15 the Pro/Max usage caps split per-product, so the same 5-10× per-turn over-spend converts directly into 5-10× faster cap exhaustion (and 5-10× dollar burn for direct-API operators). For any operator currently on 4.8 for routine coding turns, the model switch is the highest-leverage pre-cliff action — pinning to 4.7 today is dollar-equivalent to staying on 4.8 with a 5-10× larger plan after June 15.

Operator-side diagnostic references (all free, MIT):

• Field guide: 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), including the requestId-grouping reproduction step and per-tier (low / medium / high) detection thresholds.
• Three detection hooks shipped in cc-safe-setup (PR #529, #535): output-token-spike-detector.sh (absolute-magnitude rolling-window comparison), thinking-budget-effort-mismatch-detector.sh (per-tier threshold without baseline accumulation — low>10k, medium>30k, high>80k), opus48-routine-task-warning.sh (opt-in SessionStart advisory).
• The sibling Cluster 22 candidate (parallel-tool fabrication on the same Opus 4.8 substrate) is a different surface mode but resolves via the same /model claude-opus-4-7 switch: Cluster 22 candidate field guide.

Cheapest diagnostic right now: if you're already burning 20× in 2 days, switch the model pin to claude-opus-4-7 and observe whether your next 24 hours returns to baseline. That isolates Cluster 23 from sibling Opus 4.8 hazards (Cluster 13 extended-thinking wedge, Cluster 22 fabrication retries) in roughly one session of observation.

Ran into this issue and switching from 4.8 to /model claude-opus-4-7 immediately fixed the problem.

Version: 2.1.161

Adding independent evidence for this shape, plus a harder variant that ends in a permanently wedged session — which I don't think has been reported yet.

Setup: Claude Code 2.1.170, headless --input-format stream-json, with a local logging proxy in front of the API (so I have per-request stop_reason / output_tokens / duration for every call).

The malignant variant: 64k tokens of pure hidden thinking, terminated by max_tokens

5 occurrences across 3 sessions (Jun 9–10), all on claude-opus-4-8:

| time | duration | output_tokens | stop_reason |
|---|---|---|---|
| Jun 9 19:36 | 1118 s | 64,000 | max_tokens |
| Jun 9 19:55 | 1145 s | 64,000 | max_tokens |
| Jun 9 20:14 | 517 s | 64,000 | max_tokens |
| Jun 10 14:32 | 1198 s | 64,000 | max_tokens |
| Jun 10 14:52 | 475 s | 64,000 | max_tokens |

Each of these requests completed normally at the HTTP level (status 200, no retry, no disconnect). The transcript entry for each is an assistant message containing a single thinking block with thinking: "" and a ~180–220 KB signature, no text, no tool_use — i.e. the entire 64k output budget went into encrypted/hidden thinking with zero visible content. From the user's perspective the session just goes silent for 8–20 minutes.

Denominator from the same proxy (same machine, same workloads): claude-opus-4-7 = 11,643 requests, zero max_tokens runaways; claude-opus-4-6 = 8,658 requests, zero; claude-opus-4-8 = 1,227 requests, 5. This looks model-specific to 4.8, consistent with the effort-budget regression hypothesis in this thread.

The wedge: CC stops auto-continuing after the second max_tokens in one agentic turn

This is the part that turns a token-burn bug into a hang bug:

1. First runaway (14:32, 20 min, max_tokens) → CC auto-continued ~4 s after completion, the agentic turn resumed, a couple of normal tool calls followed.
2. Second runaway in the same turn (14:52, 8 min, max_tokens) → CC never issued another API request. Process still alive, 0% CPU, CPU time frozen — it's not waiting on the network (the proxy logged the request as complete). The session is permanently stuck and only a kill/resume recovers it.

So the observable failure for end users is "Claude hangs forever mid-task", but the root sequence is: hidden-thinking runaway → max_tokens with zero visible blocks → CC's continuation logic gives up silently after the second hit.

Side effect worth noting: hallucinated context after lighter runaways

In a sibling session on 4.8, a lighter form (~25 KB signature thinking block, end_turn) was immediately followed by the model inventing conversation history — it "answered" a user reminder that was never sent, and claimed it had attempted tool calls that do not exist anywhere in the transcript. Whatever happens inside these oversized hidden-thinking episodes seems to degrade the model's grounding in the actual conversation.

Happy to provide redacted transcript excerpts (block structure + sizes) if useful.

Reproducing this on Opus 4.8, effort=high (not max). Pulled hard numbers from one day of local Claude Code session logs:

• Across 1,606 assistant turns in a single day, 16 (~1%) ran extended thinking to the 64,000-token output ceiling → stop_reason: max_tokens, with thinking-only content and zero answer text. Each took 16–20 min wall-clock.
• The other 99% are normal (median output 1,105 tokens).
• Onset is recent: 0 occurrences in May, first hit on June 11, climbing since (14 in a single day by June 28). Spans versions 2.1.170 → 2.1.195.
• Not input-dependent: triggered by trivial turns — a one-line question, or a 92-character tool_result — not just heavy context. Input tokens were tiny/cached on the blowup turns.
• It cascades: a truncated thinking turn is frequently followed by another that blows up to 64k again.
• Platform: macOS.

Confirms this isn't limited to medium effort — it happens on high too, and at the full 64k ceiling rather than 46k.

Workaround that bounds the damage: setting MAX_THINKING_TOKENS (e.g. 20000) in settings.json env caps thinking so the model is forced to emit an answer instead of dying at the ceiling. The underlying runaway still appears present on effort=high. No related fix in the 2.1.195 changelog.