### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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 Anthropic API experiences slowdowns (even minor ones not reported on status page), keyboard input in Claude Code CLI becomes extremely slow. Each ke

[BUG] Input latency severely affected by API response times - typing becomes unusable during API slowdowns

Status Closed — not planned

Maintainer reply None cached

Activity 11 comments · opened Dec 18, 2025 · closed Mar 26, 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?

When Anthropic API experiences slowdowns (even minor ones not reported on status page), keyboard input in Claude Code CLI becomes extremely slow. Each keystroke takes approximately 1 second to
appear on screen.

This issue is particularly severe when:

Working on large codebases with extensive context
Using Opus model
During peak API usage hours (US business hours)
Sessions with long conversation history

The problem appears to be that Claude Code's Node.js event loop gets blocked when API responses are slow. Since keyboard input (stdin) runs on the same event loop, it gets affected even though
input handling should be completely local and independent of API communication.

Confirmed this is NOT a system/network issue:

System Load: 0.4
Memory: 24GB available out of 31GB
Network latency: 0.6ms
Tested on multiple servers - same issue
Tested from different client machines - same issue
After exiting Claude Code, typing in same terminal is instant

What Should Happen?

Keyboard input should be processed locally and remain responsive regardless of API latency. The input buffer should be independent of the API communication layer.

User should be able to type messages at normal speed even when API is slow. The slowness should only affect the response generation, not the input experience.

Suggested fixes:

Separate input handling into its own thread/worker
Use non-blocking I/O for API communication
Buffer user input locally, independent of API state

Error Messages/Logs

No error messages - the application continues to function, just with severe input lag.

  Diagnostic output:

  # Inside Claude Code session - typing "hello" takes ~5 seconds
  # Each character appears with ~1 second delay

  # Isolation test (same terminal, after exiting Claude Code):
  $ echo "test"
  # Types instantly - no delay

  # System resources during issue:
  $ uptime
   14:34:00 up 30 days, load average: 0.40, 0.35, 0.32

  $ free -h
                total        used        free      shared  buff/cache   available
  Mem:           31Gi       6.8Gi       4.4Gi        71Mi        20Gi        24Gi

  $ ps aux | grep node
  # Claude Code process running normally, no excessive CPU/memory

Steps to Reproduce

Open Claude Code CLI: claude
Work on a large project with many files (to build up context)
Have a conversation with multiple back-and-forth messages
Wait for API to experience any slowdown (often during US business hours)
Try typing a new message
Observe: each keystroke takes ~1 second to appear on screen
Exit Claude Code with /quit
Type in same terminal - observe instant response (proving it's not terminal/SSH issue)

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.0.72

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

11 Comments

github-actions[bot] · 8 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

george7979 · 8 months ago

I'm experiencing the same issue on v2.0.72.

I've tested previous versions and confirmed that v2.0.71 is the last stable version where this bug does not occur.

Environment

OS/Platform: Windows 11 + WSL (Ubuntu)
Terminal: Cursor IDE terminal / standalone WSL console
Setup: Filesystem and installation are entirely within WSL

Symptoms

Severe input lag that scales with conversation context
Frequent API connection retry messages
Running /clear temporarily fixes the lag until the context builds up again

burakyalti · 8 months ago

Downgrading to version 2.0.71 resolves the issue.

The input latency problem does not exist in version 2.0.71. This suggests a regression was introduced in a newer version.

### Steps to downgrade:

```bash
npm install -g @anthropic-ai/claude-code@2.0.71

To prevent auto-update (keeping the working version):

Add the following to ~/.claude/settings.json:

{
"env": {
"DISABLE_AUTOUPDATER": "1"
}
}

Version comparison:

| Version | Input Latency |
|------------------|-----------------------------|
| Latest (current) | ~1 second per keystroke |
| 2.0.71 | ✅ Normal, instant response |

This confirms the issue is a regression introduced after version 2.0.71, not an API-related problem as initially suspected.

dmkenney · 8 months ago

Can confirm same exact behavior. No issues on 2.0.71.

At beginning of session has very little noticeable lag. As the conversation continues the lag becomes increasing worse to the point it is unusable.

lilith · 8 months ago

I also experience this over RDP/VNC where keystrokes arrive in bursts. The blocked event loop can't keep up, causing OS-level input
buffer overflow and dropped characters. Same with autocomplete and assistive stuff. More than half of characters are dropped, even on a fresh instance of claude after a reboot. Buffering needs to be fixed, the keyboard needs to be on a different event loop or something.

BrianMcBrayer · 7 months ago

I am also experiencing this issue. I downgraded to 2.0.71 and it is still happening there, but it was not happening to me at the end of 2025. Typing in my terminal is instant. When I launch claude in that same terminal, it takes up to a couple seconds for newly types characters to appear.

Environment:
Windows - WSL (Ubuntu)
Windows Terminal

github-actions[bot] · 6 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

kaansoral · 6 months ago

bump

shallwefootball · 6 months ago

Detailed profiling data from Linux server (NUC, 16-core, 64GB RAM)

Environment: Ubuntu Linux, Claude Code via mosh + tmux, SSH from macOS (iTerm2)

I systematically profiled the input lag by monitoring the Claude Code process via /proc to isolate the exact bottleneck. Here's what I found:

Root Cause: Main thread blocked during API stream chunk processing

By sampling /proc/<pid>/schedstat and /proc/<pid>/io at 250ms intervals during a response stream:

| Timestamp | Thread State | CPU run (per 250ms) | Scheduler wait | rchar (read) | wchar (write) |
|-----------|-------------|---------------------|----------------|--------------|---------------|
| idle | S (sleeping) | 13-18ms | 0ms | 0.3-0.5KB | 0.1KB |
| API chunk arrives | R (running) | 71-81ms | 0.9-1.1ms | 334-13106KB | 1.8-14.9KB |

When an API streaming chunk arrives, the main thread spends 70-80ms in CPU-bound processing (parsing + terminal rendering), during which stdin reads are completely blocked.

What was ruled out

| Layer | Measurement | Result |
|-------|------------|--------|
| Network (Tailscale) | RTT 0.03ms, jitter 0.008ms, 0% loss | Not the cause |
| tmux server | Single-threaded but CPU 0% even under load | Not the cause |
| NUC system load | CPU 82% idle, nvme 2.2% util | Not the cause |
| tmux escape-time | Already set to 0 | Not the cause |
| Disk I/O contention | iostat shows no contention | Not the cause |

Additional observations

12 Claude Code instances running simultaneously (each ~40 threads, total ~10.5GB RAM) — even with this load, the system is not the bottleneck
The tmux server (single process, single thread) handles all session I/O but measured at 0% CPU even during stress tests with tmux send-keys
The lag is per-CC-instance: each CC blocks its own stdin during its own response rendering, independent of other sessions

Suggestion

The original issue author's suggestion #1 is correct — input handling needs to be separated from the API response processing pipeline. The 70-80ms main thread blocks are well within human-perceptible range and directly cause the "stuttering" input experience.

Profiling method: /proc/<pid>/schedstat (run_time, wait_time), /proc/<pid>/io (rchar, wchar), /proc/<pid>/task/<tid>/stat (thread state sampling at 100-250ms intervals)

github-actions[bot] · 5 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

github-actions[bot] · 4 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.