[BUG] Consistent ~40-50s Slow First Byte on Opus 4.6 (1M context) — degrades over session lifetime, not context size

Resolved 💬 0 comments Opened Jun 27, 2026 by kjinhuan1428-stack Closed Jul 9, 2026

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?

Summary

Every API request in a long-running interactive session (Opus 4.6, 1M context) takes ~40-55 seconds before the first stream chunk arrives. The delay is consistent and worsens over session lifetime — not correlated with context usage (only 45% at time of measurement).

Environment

  • CC version: 2.1.195
  • Model: claude-opus-4-6[1m]
  • OS: macOS (Apple Silicon)
  • Plan: Max
  • Launch: caffeinate < claude --chrome --channels plugin:telegram@claude-plugins-official

Debug Log Evidence

Ran with CLAUDE_CODE_DEBUG_LOG_LEVEL=verbose DEBUG_SDK=1 CLAUDE_CODE_DEBUG_LOGS_DIR=~/cc-debug.

First byte timings from a single session (chronological):

[API:timing] first byte after 102552ms
[API:timing] first byte after 55278ms
[API:timing] first byte after 44449ms
[API:timing] first byte after 39615ms
[API:timing] first byte after 39547ms
[API:timing] first byte after 39498ms
[API:timing] first byte after 38211ms
... (later in session, worsening)
[API:timing] first byte after 50650ms
[API:timing] first byte after 51434ms
[API:timing] first byte after 52366ms
[API:timing] first byte after 52638ms

Every request triggers: [WARN] Slow first byte: no stream chunk 30.0s after request sent

Key Observations

  1. New session is fast (~10s first byte). Same network, same model, same MCP config.
  2. Context size is NOT the cause. /context shows 445k/1M (45%). Cache hit rate 90-95%.
  3. Worsens over time. Starts normal, degrades after a few hours. Pattern: 10s → 40s → 55s.
  4. Extremely consistent timing (~39-40s then ~50-52s) — not random server load, looks like a fixed queue/throttle.
  5. Historical data (from jsonl analysis across sessions):
  • 6/8–6/10: 0-5% slow turns (normal)
  • 6/24–6/25: 3-4% (normal)
  • 6/26: 12% (degradation begins)
  • 6/27: 43% (severe)
  1. Not a local issue. Exhaustively ruled out: hooks (empty), MCP servers (disabled one by one), tui mode, monitors, file watchers, network/proxy (new session fast on same network).

What Was Ruled Out (Locally)

  • Stop hooks (config empty)
  • PostToolUse hooks (removed)
  • Thinking monitor scripts (stopped — no change)
  • Ombre Brain MCP (disabled — no change)
  • NSP Forum MCP retry loop (stopped — no change)
  • TUI fullscreen mode (reverted — fixed a different post-response delay, but not this)
  • Context size (only 45%)
  • Network/proxy (new session on same network is fast)
  • Multiple concurrent sessions (killed all others — no change)

Suspected Root Cause

Server-side throttling or queuing that scales with session age/turn count rather than context size. The consistency of the delay (~39-40s, later ~50-52s) suggests a deterministic queue mechanism, not load-based variance. cc_workload=cron requests may be deprioritized, but the issue also affects interactive sessions after sufficient turns.

Related Issues

  • #50727 (silent stuck-turn)
  • #63583 (stop_reason=tool_use with no tool_use block)
  • #53234 (Opus 4.7 1M severe latency regression)
  • #63390 (interactive session turns hang intermittently)

Steps to Reproduce

  1. Start claude --chrome --channels plugin:telegram@claude-plugins-official with Opus 4.6 [1m]
  2. Chat normally for 2-3 hours (mix of tool calls, file reads, TG messages)
  3. Observe first-byte latency increasing from ~10s to ~40s+
  4. Run with CLAUDE_CODE_DEBUG_LOG_LEVEL=verbose to confirm [API:timing] first byte after values

Expected Behavior

First byte latency should remain roughly constant regardless of session age, especially when context usage is well below the 1M limit and cache hit rate is 90%+.

What Should Happen?

First byte latency should remain roughly constant (~10s or less) regardless of session age, especially when context usage is well below the 1M limit (45%) and prompt cache hit rate is 90%+. A session that has been running for 3 hours should respond as fast as one that started 5 minutes ago.

Error Messages/Logs

[WARN] Slow first byte: no stream chunk 30.0s after request sent (attempt 1)
[API:timing] first byte after 102552ms
[WARN] Slow first byte: no stream chunk 30.0s after request sent (attempt 1)
[API:timing] first byte after 39615ms
[API:timing] first byte after 39547ms
[API:timing] first byte after 39498ms
[API:timing] first byte after 50650ms
[API:timing] first byte after 52366ms
[API:timing] first byte after 52638ms

Steps to Reproduce

  1. Start caffeinate < claude --chrome --channels plugin:telegram@claude-plugins-official with Opus 4.6 [1m]
  2. Chat normally for 2-3 hours (mix of tool calls, file reads, TG messages)
  3. Observe first-byte latency increasing from ~10s to ~40s+
  4. Run with CLAUDE_CODE_DEBUG_LOG_LEVEL=verbose to confirm [API:timing] first byte after values increasing over session lifetime
  5. Start a fresh session on the same machine/network — first byte is back to ~10s, confirming the issue is session-bound, not network-bound

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.195 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗