API requests silently queue 1-10 min before first token since ~Jul 16 (Max 20x, quota at 27%)

Status Open
Reported on v2.1.205
Maintainer reply None cached
Activity 1 comment · opened Jul 19, 2026

Summary

Since ~2026-07-16, API requests from Claude Code sessions frequently sit "queued" for 1–10 minutes before the response starts streaming. The wait happens between a completed tool result and the first token of the next assistant turn. Before 2026-07-16 the same workloads (same machine, same account, same or much larger contexts) had ~0s wait.

Evidence (measured from session transcripts, ~13k API calls over 3 months)

Method: for every unique requestId in ~/.claude/projects/.../*.jsonl, wait = (assistant entry timestamp − previous entry timestamp) − output_tokens/40 (generous generation-time allowance). All slow requests had healthy prompt-cache hits (90–110k+ cache_read_input_tokens) and small outputs (200–1500 tokens incl. thinking), so the wall-clock time is queueing, not compute.

Before / after (requests with context >100k tokens):

| Date | Client | n | median wait | p90 |
|---|---|---|---|---|
| Apr–Jul 15 (opus-4-7/4-8, up to 800k ctx) | 2.1.x | ~9,000 | 0s | 0–9s |
| Jul 13–15 (claude-fable-5) | 2.1.205 | 1,695 | 0s | 1–2s |
| Jul 16 | 2.1.205 | 132 | 0s | 3s |
| Jul 16 | 2.1.211 | 171 | 54s | 119s |
| Jul 17 | 2.1.211 | 395 | 12s | 172s |
| Jul 18 | 2.1.211 | 316 | 38s | 254s |
| Jul 19 | 2.1.211 | 28 | 40s | 351s |

Worst single request: 634s wait for 490 output tokens with 109,966 cached input tokens (req_011CdBJtrxi64kjDKwSo1yfQ). Another example: req_011CdBGoHNVigDwSPMH8A6ks (305s, 1381 out).

It is progressing to smaller contexts. On Jul 19 a fresh session on claude-opus-4-8 (1M) hit waits of 181s/418s/547s at only 45–80k context — sizes that were instant for months.

Not a quota issue. cachedUsageUtilization snapshot taken 3 minutes before the laggy Jul 19 session: session 0%, weekly_all 27% (severity normal), weekly_scoped Fable 45% (severity normal). No limit active. organizationRateLimitTier: default_claude_max_20x.

Not a local network issue. Same-second cross-check across two concurrent sessions shows only one shared connectivity blip (ConnectionRefused at 09:35 Jul 19) which is excluded from the stats above.

Affects both claude-fable-5 and claude-opus-4-8[1m]. Coincides with the Claude 5 launch window and the Jul 16–17 incident wave on status.claude.com, but continues on Jul 18–19 with no posted incidents.

Impact

Agentic turns make 5–15 API calls; with per-request queueing of 1–10 min a single turn can take 20+ minutes, and user messages typed meanwhile sit in the client-side queue, so the CLI appears frozen ("queued", no thinking). This makes long agentic sessions unusable on a Max 20x plan that is nowhere near its limits.

Environment

  • Claude Code 2.1.211 / 2.1.214, Windows 11 Pro 10.0.26200 (native installer)
  • Max 20x subscription (OAuth), tier default_claude_max_20x
  • Models: claude-fable-5 (high effort), claude-opus-4-8 (1M context)

Expected

Time-to-first-token in seconds (as it was through 2026-07-15), or at least surfacing the real queue/throttle state to the user instead of a silent multi-minute wait.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗