[Bug] Latency regression in 4.8: 60+ second delay before action execution on trivial commands

Resolved 💬 2 comments Opened Jun 24, 2026 by lankro Closed Jun 28, 2026

Bug Description
Summary: Latency regression in Claude Code since the 4.7 → 4.8 rollout What I'm seeing: Since the 4.7 → 4.8 update, there's a consistent delay of over a minute before any action begins — even for trivial, deterministic commands. Asking it to run something like "tail -1 <file>" and return the line will sit on "...almost done with <type> thinking..." for 60+ seconds before anything happens. The thinking/latency overhead seems to be applied uniformly, regardless of how trivial the task is. Impact: Effective daily throughput is down roughly 50–70%. Work that used to take 30–60 minutes now takes many hours. A normal multi-session workflow — 3–5 sessions and 2–4 parallel fronts at once — is no longer practical, because every step blocks on a long wait. For interactive daily engineering use, the per-action wait has become the dominant cost. What would help: - Reduce time-to-first-action latency, especially the regression introduced with 4.8. - Scale thinking time to task complexity — trivial mechanical commands (file reads, single-line output, deterministic shell calls) shouldn't carry the same reasoning overhead as complex reasoning tasks. - A low-latency responsiveness mode for interactive, multi-session work.

Environment Info

  • Platform: darwin
  • Terminal: iTerm.app
  • Version: 2.1.183
  • Feedback ID: 6f8c7864-459a-4fd5-a38b-7ac492a34244

Errors

[]

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗