Opus 4.8: runaway invisible thinking burns entire 64k output budget (15+ min of silence), followed by token corruption and fabricated tool results

The runaway invisible-thinking / output-budget burn pattern is a strong failure case.

If you can paste a sanitized trace showing where the run started burning tokens, where silence began, and where fabricated tool results appeared, I can run it through Rootlyze and send back a proofpack with likely cause, evidence, next action, prevention guidance, and limitations.

Please remove secrets, API keys, tokens, customer data, and private URLs first.

Environment

• Claude Code (desktop app, Windows 11), version 2.1.205
• Model: claude-opus-4-8

Summary

A new variant of this runaway-thinking bug. Unlike the known signature (stop_reason=max_tokens with output_tokens=64000 exactly), this one self-terminates below the cap and the session continues, so max_tokens-based monitoring misses it entirely.

Observed behavior (from transcript, session 71e247a6)

• After a normal tool_result at 07:02:58Z, the next assistant message did not complete until 07:15:54Z (~13 minutes of silence).
• That single message billed usage.output_tokens=42,808 with stop_reason=tool_use. Visible content was only a thinking block (content not persisted), 393 chars of text, and one Read tool call — i.e. ~42k tokens went into invisible thinking.
• requestId: req_011Ccsx15xTaW38A2SWutJRL / message id: msg_011Ccsx174BfpTYi9JXM4RZJ
• The first visible text after the gap responded to a conversation that never happened in this session (it "replied" to a discussion from a previous day's session), i.e. confabulation.
• The session then stabilized and worked correctly, but near the end it produced structurally invalid JSON for the AskUserQuestion tool twice in a row (InputValidationError: raw newline inside a JSON string).

Prior occurrences

12 earlier events across 6 sessions (2026-06-10..07-09), all on claude-opus-4-8, none on other models. Previously reported requestIds: req_011CcrGHTgx741YGN1zkXKJu, req_011CcrHapKX1WTKbd3Nm7gSP.

Why this variant matters

• It evades detection tuned to the known signature (stop_reason=max_tokens + output=64000), so users silently pay for ~40k thinking tokens per event.
• The post-runaway confabulated reply suggests the degradation chain (runaway thinking → confabulation → malformed tool JSON) can occur even when the token cap is not reached.

Thanks — this is a very useful writeup. I ran the public details through Rootlyze as a mini-proofpack.

Likely pattern: invisible-thinking/output-budget runaway that self-terminates below the known max_tokens signature, followed by a possible degradation cascade: stale-session confabulation and malformed tool JSON.

Evidence:

• ~13-minute silent assistant turn after the normal tool_result
• usage.output_tokens=42,808 with stop_reason=tool_use, not max_tokens
• visible content was tiny relative to billed output
• first visible text after the gap referenced a conversation not in this session
• later AskUserQuestion calls failed twice with raw newline JSON validation errors
• 12 prior events across 6 sessions, all on claude-opus-4-8

Next check: detection should not rely only on stop_reason=max_tokens or the exact 64k-token signature. A better rule would alert on high output tokens + long assistant wall-clock latency + tiny visible content, even when stop_reason=tool_use.

Prevention idea: add a separate thinking-runaway guard, for example: assistant latency >60–120s plus output_tokens >25k–30k plus visible-content ratio anomaly. After that trigger, force a context/session refresh before the next model call so any degraded state does not propagate.

Limitation: this is based only on the public report and billed-token/timing details, not the full transcript. The confabulation and malformed JSON may be downstream of the runaway, but that needs confirmation.

For a full proofpack, the most useful sanitized slice would be only the 2–3 messages before the runaway, the runaway assistant message metadata, the first confabulated reply, and the two invalid AskUserQuestion calls. Please remove secrets, API keys, tokens, customer data, credentials, private URLs, and sensitive file paths first.

I have reproduced a variant of this with Fable 5. After burning through the 64k output budget, it keeps just retrying, burning through it again and again. The following data was collected by Claude in a separate session:

VSCode extension,Claude Code 2.1.207, Linux. Extra High or High reasoning depth.

Symptom: assistant turns that consume the entire output
budget with stop_reason: "max_tokens", where the content is a single thinking
block with thinking: "" and a ~165–182KB signature. No visible text, no tool
calls, ~14 minutes of silence per attempt. The harness retries and hits the
same wall repeatedly.

15 such turns across 4 sessions on 2026-07-11 (all same task, retried with
reworded prompts asking to do smaller chunks of the task):

| session | 64k thinking-only turns |
|---|---|
| 92c8cd12-3282-4a2f-b744-3859dfbf0f04 | 6 (10:42–13:05 UTC July 11) |
| cb6ec373-d155-4a87-a7dc-42569dfe84ae | 4 (07:46 UTC, 61,933 tok) |
| d798512b-3f18-41cb-b099-729a3eb87f40 | 4 (13:39–14:30 UTC, July 11) |
| 5eaa829d-68d9-42c9-9715-7313a5527a92 | 1 (15:48 UTC) |

Trigger shape: asking the model to verify rigorously, from a small axiom
set, which inference rules of a program logic remain valid in a generalized
setting (research-level math; I can't share the exact prompt). Deterministic
enough that every variant of the prompt reproduced it.
Every session starts fine with collecting context, then the thinking loop starts.
When I interrupt the thinking process and ask, it tells me that it just finished
collecting context and didn't start the proofs yet.

Total: ~950k output tokens burned with zero output, counted against my usage
limit. Happy to share the session IDs above for server-side correlation;
I cannot attach transcripts (unpublished research).