Long-output Opus request stalls server-side after client update (output_tokens=0, error: unknown after 36 min)

Summary

After updating Claude Code from 2.1.112 → 2.1.133, a previously-reliable long-output task (generating a ~20k-character markdown investment weekly report) hangs for 36 minutes and then fails with error: "unknown" and output_tokens: 0. The model never streams a single output token. The same task, with the same model, the same effortLevel: xhigh, and a near-identical input size (~15-16k tokens), completed in 6.5 minutes on 2.1.112.

Environment

• Claude Code: 2.1.133 (failure) — also subjectively reproduced on 2.1.138
• Model: claude-opus-4-7[1m] (Opus 4.7, 1M context variant)
• effortLevel: xhigh
• OS: Windows 11 (native install, npm global)

Failure trace

Session: 741fd4d7-cbca-4ddd-b9c4-73b1e5005df6
Failing request: req_011Cau71JpyBPtgVzyFVviVf

| time (UTC) | event |
|---|---|
| 15:12:48 | preparatory tool calls finish (WebSearch + TaskUpdate batch), final request begins |
| 15:13–15:48 | ~30s-interval ping/heartbeat timestamps, no tokens streamed |
| 15:48:57 | server returns stop_reason: "stop_sequence", output_tokens: 0, cache_creation_input_tokens: 0, cache_read_input_tokens: 0, error: "unknown" |

The model never enters the output phase — prefill appears to stall server-side, but the client keeps the stream open until a server-side timeout.

Comparison with prior working sessions (same task type)

| date | version | total time | result | ToolSearch calls |
|---|---|---|---|---|
| 2026-04-11 | 2.1.100 | ~12 min | ✅ ok | n/a |
| 2026-04-18 | 2.1.112 | 6.5 min | ✅ ok | 2 |
| 2026-04-26 | 2.1.116 | ~12 min | ✅ ok | n/a |
| 2026-05-10 | 2.1.133 | 36 min | ❌ error: unknown, 0 tokens | 7 |

Initial context size is comparable across all sessions (~15-18k cache_creation tokens). effortLevel was xhigh throughout. The most prominent change in the trace is the volume of ToolSearch / deferred_tools_delta activity — roughly 3.5× more deferred-tool fetches in the failing session, with multiple cache invalidations as new tool schemas get injected mid-task.

Hypothesis

The expanded deferred-tools system introduced/changed between 2.1.116 and 2.1.133 causes repeated mid-task schema injection, which appears to interact badly with xhigh extended thinking on the 1M-context Opus variant — the final large request seemingly stalls in server-side prefill and is eventually killed with a generic error. Older client builds with fewer deferred tools and a simpler initial tool schema do not hit this on the same task.

Reproduction (best guess)

1. Set effortLevel: xhigh in ~/.claude/settings.json
2. Use claude-opus-4-7[1m]
3. Run a task that:

• Invokes several deferred tools early (WebSearch, TaskUpdate, MCP tools)
• Then asks for a single large markdown output (~20k chars) via Write

Cannot guarantee reproducibility — may depend on cache state and server load.

Asks

• Is the 36-minute stall + error: unknown something the server team can correlate via the request ID?
• Is there a way to disable / opt out of the deferred-tools system for diagnostic comparison?
• Is xhigh + 1M Opus a supported combination for long-output tasks, or is there an undocumented limit?