[BUG] Input Lag / Slow Typing Echo When Context is Full (Regression from 2.0.x)

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

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)
• Last known working version: 2.0.x
• OS: Linux 6.1.0-42-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.159-1 (2025-12-30) x86_64 GNU/Linux
• 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

1. Start a Claude Code session
2. Have a lengthy conversation or work on a large codebase until context usage reaches 70-90%+
3. Begin typing a new prompt
4. 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

1. Start a Claude Code session
2. Have a lengthy conversation or work on a large codebase until context usage reaches 70-90%+
3. Begin typing a new prompt
4. 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:
https://github.com/anthropics/claude-code/issues/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