[BUG] Opus 4.8 (1M) stream hangs after first chunk since 2.1.154; 2.1.153 is last known good

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

When using Opus 4.8 (1M context), Claude Code frequently hangs in the thinking/streaming state with no further output.

The strongest signal is a precise version boundary and long-term regression tracking:

• Last known-good version: 2.1.153
• First known-bad version: 2.1.154
• Latest tested bad version: 2.1.197
• I have been tracking Claude Code releases since 2.1.154. I did not test every single release, but I tested many versions across the 2.1.154 -> 2.1.197 range.
• Every tested version reproduced the same Opus 4.8 hang/misbehavior.
• Each time I confirmed the issue still existed, I rolled back to 2.1.153, which remains stable on this same machine.

Observed symptoms:

• The stream enters a long "thinking" state with no output.
• The API stream is established and TTFB is normal, but after the first chunk the stream stops entirely.
• It only recovers via the idle watchdog after several minutes.
• One occurrence produced a semantically unrelated response:
• Input: "Can you update pricing.json?"
• Response: "Understood, I'll write it to memory ✨"
• I interrupted immediately. Transcript inspection confirmed no tool_use was sent and no file was modified.

This appears specific to Opus 4.8 / 1M behavior on this machine. On the same machine, Opus 4.7 works normally.

What Should Happen?

Claude Code should continue streaming usable output after the first response chunk, or fail fast with a clear recoverable error if the stream stalls.

The assistant response should correspond to the latest user prompt. It should never silently answer a stale/nonexistent context or produce unrelated content after long thinking.

A regression introduced after 2.1.153 should not require users to pin/rollback indefinitely in order to use Opus reliably.

Error Messages/Logs

Captured with:

claude --debug api --debug-file ~/claude-opus-debug.log

Findings:

- TTFB is normal: first byte arrives within ~1.3-1.8s.
- Hang pattern: after receiving the first chunk, no further stream events arrive for an extended period.
- Recovery only happens through the idle watchdog after several minutes.
- This suggests the connection is established successfully; the failure occurs after stream start / after the first chunk.

No sensitive request IDs or API keys are included here, but I can provide sanitized debug excerpts if needed.

Related in-product feedback report with session details:

Feedback ID: ce515f85-8f15-4669-abce-3471ad252167

Steps to Reproduce

1. Use Claude Code on the affected Mac with Opus 4.8 / 1M context.
2. Run a normal coding prompt or file-editing prompt. The issue is intermittent but recurring.
3. Observe that the stream enters "thinking" and then hangs with no useful output.
4. Capture debug logs with claude --debug api --debug-file ~/claude-opus-debug.log.
5. In the debug log, observe normal first-byte timing followed by no further stream events until the idle watchdog recovers/aborts.
6. Downgrade/pin Claude Code to 2.1.153 on the same machine and repeat similar work: Opus 4.8-related hang/misbehavior does not reproduce there.
7. Upgrade again to later versions in the 2.1.154 -> 2.1.197 range: the issue returns.

Reproduction is not 100% deterministic per prompt, but it has reproduced repeatedly for over a month across many tested Claude Code versions after 2.1.153.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.153

Claude Code Version

2.1.197 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment / comparison matrix:

| Machine | Chip | Tailscale | Opus 4.8 |
|---|---|---|---|
| Affected Mac | Apple M4 Max (Mac16,6, 64GB, arm64) | Installed | Hangs / misbehaves |
| Other Mac | M1 Pro | Not installed | Normal |
| Windows machine | - | Installed | Normal |

Factors ruled out or reduced in likelihood:

• Network / DNS / proxy: checked, no anomaly found.
• VPN / Tailscale: another working machine also uses Tailscale.
• macOS version: reproduced before and after OS upgrade.
• Node.js version: tested and ruled out.
• Terminal emulator: reproduced across terminals, not limited to one terminal app.
• Statusline script: measured at ~39ms, not a plausible cause.
• Local Claude cache/config: deleted/reinstalled ~/.claude and .claude.json; issue persisted.
• Account routing: same Anthropic account works fine on other machines.

Model comparison:

• Same affected machine + Opus 4.7: works normally.
• Same affected machine + Opus 4.8 / 1M: hangs or misbehaves.

Release-note correlation around 2.1.154:

• 2.1.154 changed the lean system prompt default for models except Haiku, Sonnet, and Opus 4.7 and earlier, which means Opus 4.8 is in the newly affected category.
• 2.1.154 also mentioned a fix for premature out-of-context behavior on some 1M-context models.
• Opus 4.8 defaulting to high effort may also be relevant, although my local global setting is effortLevel: "low".

Possibly related issues:

• #46745 - stream dies after first chunk / silent stalls
• #66095 - Opus 4.8 stream byte stalls / idle timeout
• #69061 - Opus 4.8 responds from nonexistent context after long thinking
• #68352 - Opus 4.8 (1M) recurring unusable assistant outputs
• #67606 - Opus 4.8 confabulates user messages / stale-context-like behavior

Requested investigation:

• Check for a regression introduced in 2.1.154 that still affects 2.1.197.
• Investigate Opus 4.8 / 1M stream handling after the first chunk.
• Investigate whether the lean system prompt / 1M-context behavior change in 2.1.154 can trigger stale-context or stream-hang behavior.
• Investigate whether M4-series Apple Silicon exposes a low-level client/runtime compatibility issue.
• Consider detecting and retrying stream hangs faster than the full idle-watchdog delay.

Terminal/Shell detail:

• Primary terminal: kitty.
• Also reproduced in the built-in macOS Terminal.app, so this does not appear to be kitty-specific.

Session/debug artifacts:

• I have the corresponding Claude Code conversation/session transcript and debug log for at least one occurrence.
• I can provide sanitized excerpts or request IDs privately if maintainers need them.
• I am not attaching the full transcript publicly because it may contain local project paths, prompts, filenames, and other project/context details.

Anthropic feedback reference:

• I already submitted an in-product Claude Code feedback report for this issue, including the corresponding session/conversation details.
• Feedback ID: ce515f85-8f15-4669-abce-3471ad252167
• The feedback flow asked me to also file a GitHub issue and include this Feedback ID, so maintainers should be able to correlate this public report with the private session details internally.