You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched existing issues and this hasn't been reported yet
This is a single bug report (please file separate reports for different bugs)
I am using the latest version of Claude Code
What's Wrong?
Summary
Typing input becomes noticeably laggy when the context window is near capacity. Keystrokes are echoed with visible delay, making the CLI
feel unresponsive. This was not an issue in version 2.0.x.
Environment
Claude Code version: claude --version: 2.1.6 (Claude Code)
Terminal: GNOME TERMINAL, Version 3.46.8 for GNOME 43, Using VTE version 0.70.6 +BIDI +GNUTLS +ICU +SYSTEMD
Node.js version: node --version: v20.19.5
Steps to Reproduce
Start a Claude Code session
Have a lengthy conversation or work on a large codebase until context usage reaches 70-90%+
Begin typing a new prompt
Observe that keystrokes are echoed with noticeable delay
Expected Behavior
Typing should remain responsive regardless of context window usage. Keystroke echo should be immediate (<50ms perceived latency).
Actual Behavior
As context fills up, there is increasing delay between pressing a key and seeing it appear in the terminal. At high context usage
(80%+), the lag becomes disruptive to normal typing flow.
Workarounds Discovered
The following mitigation partially helps but don't fully resolve the issue:
Manual /compact or /clear when lag becomes noticeable
Possible Causes (Speculation)
Token counting or context size calculations running on each keystroke
UI state updates (status line, context percentage) blocking the input event loop
New features added post-2.0.x (hooks, MCP, subagents) adding overhead to the main loop
Memory pressure from larger context affecting Node.js event loop responsiveness
Impact
Disrupts typing flow and reduces productivity
Particularly noticeable during longer coding sessions
Forces frequent manual compaction to maintain usability
What Should Happen?
Expected Behavior
Typing should remain responsive regardless of context window usage. Keystroke echo should be immediate (<50ms perceived latency).
Error Messages/Logs
Steps to Reproduce
Steps to Reproduce
Start a Claude Code session
Have a lengthy conversation or work on a large codebase until context usage reaches 70-90%+
Begin typing a new prompt
Observe that keystrokes are echoed with noticeable delay
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.0.x
Claude Code Version
2.1.6 (Claude Code)
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
Similar bug was reported as: #17711
The difference is that I did not experience timeouts.
Preflight Checklist
What's Wrong?
Summary
Typing input becomes noticeably laggy when the context window is near capacity. Keystrokes are echoed with visible delay, making the CLI
feel unresponsive. This was not an issue in version 2.0.x.
Environment
Steps to Reproduce
Expected Behavior
Typing should remain responsive regardless of context window usage. Keystroke echo should be immediate (<50ms perceived latency).
Actual Behavior
As context fills up, there is increasing delay between pressing a key and seeing it appear in the terminal. At high context usage
(80%+), the lag becomes disruptive to normal typing flow.
Workarounds Discovered
The following mitigation partially helps but don't fully resolve the issue:
Manual /compact or /clear when lag becomes noticeable
Possible Causes (Speculation)
Impact
What Should Happen?
Expected Behavior
Typing should remain responsive regardless of context window usage. Keystroke echo should be immediate (<50ms perceived latency).
Error Messages/Logs
Steps to Reproduce
Steps to Reproduce
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.0.x
Claude Code Version
2.1.6 (Claude Code)
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
Other
Additional Information
Similar bug was reported as:
#17711
The difference is that I did not experience timeouts.
My current statusline definition is:
{
"statusLine": {
"type": "command",
"command": "input=$(cat); used=$(echo "$input" | jq -r '.context_window.used_percentage // empty'); model=$(echo "$input" | jq
-r '.model.display_name'); dir=$(echo "$input" | jq -r '.workspace.current_dir'); if [ -n "$used" ]; then printf "[%s] %s |
Context: %.1f%% used" "$dir" "$model" "$used"; else printf "[%s] %s" "$dir" "$model"; fi"
}
}
Formatted for readability:
input=$(cat)
used=$(echo "$input" | jq -r '.context_window.used_percentage // empty')
model=$(echo "$input" | jq -r '.model.display_name')
dir=$(echo "$input" | jq -r '.workspace.current_dir')
if [ -n "$used" ]; then
printf "[%s] %s | Context: %.1f%% used" "$dir" "$model" "$used"
else
printf "[%s] %s" "$dir" "$model"
fi
Output example:
[/workspace] Claude Opus 4.5 | Context: 45.2% used