Multi-minute silent stalls on claude-fable-5; no client-side indication of waiting

Multi-minute silent stalls on claude-fable-5; no client-side indication of waiting

Environment

• Claude Code 2.1.219 (desktop app, macOS), build 2026-07-24T03:24:19Z, sha 7006c4c3ac
• macOS Darwin 25.5.0
• Affected model: claude-fable-5
• Unaffected concurrently: claude-opus-5

Summary

Two Claude Code sessions running claude-fable-5 repeatedly stalled for 5–30 minutes
mid-turn over a ~2 hour window. The stalls were synchronized across both sessions to
within seconds, which points at a shared server-side gate rather than a per-session
hang. A third session on claude-opus-5, running concurrently on the same machine and
same account, was unaffected throughout.

No error was surfaced in either session. The UI simply showed no progress — there was no
"retrying", no rate-limit notice, and nothing written to the transcript for the duration
of each stall.

Evidence

Both processes were alive and idle during the stalls, each holding an ESTABLISHED TLS
connection to the API (160.79.104.10:443), with negligible CPU:

PID   ELAPSED  CPU-TIME  session      model
944   22:53    0:22.59   d01925ce…    claude-fable-5
1068  22:26    0:18.96   c30c9788…    claude-fable-5
1824  06:07    0:10.23   fd5583e4…    claude-opus-5   (unaffected)

Stall windows, from transcript timestamps (UTC, 2026-07-28). Note how closely the two
independent sessions track each other:

| session c30c9788 | session d01925ce |
|---|---|
| 07:38:47 → 07:48:41 (595s) | 07:38:43 → 07:48:44 (601s) |
| 07:48:50 → 07:53:28 (278s) | 07:48:44 → 07:53:32 (287s) |
| 07:59:44 → 08:07:12 (448s) | 07:53:33 → 08:07:07 (814s) |
| 08:07:51 → 08:19:40 (709s) | 08:07:46 → 08:19:37 (711s) |
| 08:19:40 → 08:49:47 (1808s) | 08:19:37 → 08:49:20 (1783s) |
| 08:50:57 → 08:58:43 (466s) | 08:50:51 → 08:59:11 (500s) |

Six stalls, both sessions resuming within seconds of each other each time, with nearly
identical durations (595/601, 709/711, 1808/1783).

Ruled out locally:

• No 429 or any API error recorded in either transcript
• Not permission prompts — both sessions run with --allow-dangerously-skip-permissions
• No external process contention (checked; nothing relevant was running or holding locks)
• Not machine load — the concurrent claude-opus-5 session stayed responsive

Baseline latency on claude-fable-5 was also high outside the stalls: ~2 minutes per turn
(observed inter-tool-call gaps of 122s, 127s, 124s, 111s, 119s).

The reportable client-side bug

Separate from the latency itself: the client gives no indication that it is waiting or
retrying. A 30-minute stall is indistinguishable from a hung process. There's no spinner
state change, no "still waiting on the API", no retry/backoff message, and nothing written
to the transcript — so the only way to tell a stalled session from a dead one is to inspect
the process's open sockets by hand.

Surfacing elapsed wait time, or any retry/backoff state, would make this diagnosable
without leaving the app.

Expected vs actual

• Expected: either the request completes in reasonable time, or the client reports that

it is waiting/retrying/rate-limited.

• Actual: the session goes silent for up to 30 minutes with no feedback of any kind.