[BUG] Render loop on startup causes ~30s of input lag (fast mode status check)

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?

After starting a session, typing in the input line has ~1s lag spikes where keystrokes buffer and then appear all at once. This lasts approximately 30 seconds then resolves. The issue is purely in terminal input rendering — CPU, disk, and network are all idle during the spikes.

What Should Happen?

There should be no lag spikes

Error Messages/Logs

Evidence from ~/.claude/debug/<session>.txt:

  16:34:48.287 Org fast mode: disabled (extra_usage_disabled)
  16:34:49.088 High write ratio: blit=0, write=1012 (100.0% writes), screen=18x161
  16:34:49.083 Fast mode unavailable: Fast mode requires extra usage billing
  16:34:49.105 Fast mode unavailable: Fast mode requires extra usage billing
  16:34:49.113 Fast mode unavailable: Fast mode requires extra usage billing
  ... (536 total messages over 32 seconds, firing every ~33ms)
  16:35:21.249 Fast mode unavailable: Fast mode requires extra usage billing

  Key details:
  - 536 re-renders in 32 seconds (~30fps)
  - blit=0, write=1012 (100.0% writes) — full screen rewrite every frame, no incremental diffs
  - The loop starts after Org fast mode: disabled (extra_usage_disabled) is received
  - The loop eventually self-stabilizes and input becomes responsive

Steps to Reproduce

1. run claude
2. type in the input field, easiest is to just hold down a key and see it spray with big lag spikes.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.62 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

Environment:

• Claude Code 2.1.62 (native Linux binary)
• WSL2 on Windows (Linux 5.15.167.4-microsoft-standard-WSL2)
• Terminal size: 18x161

Symptoms:
After starting a session, typing in the input line has ~1s lag spikes where keystrokes buffer and then appear all at once. This lasts approximately 30 seconds
then resolves. The issue is purely in terminal input rendering — CPU, disk, and network are all idle during the spikes.

Root cause (from debug log):
The fast mode status check triggers a TUI render loop. On an account without extra usage billing enabled, the check returns extra_usage_disabled, which appears
to trigger a React state update that cascades into repeated re-renders.

Evidence from ~/.claude/debug/<session>.txt:

16:34:48.287 Org fast mode: disabled (extra_usage_disabled)
16:34:49.088 High write ratio: blit=0, write=1012 (100.0% writes), screen=18x161
16:34:49.083 Fast mode unavailable: Fast mode requires extra usage billing
16:34:49.105 Fast mode unavailable: Fast mode requires extra usage billing
16:34:49.113 Fast mode unavailable: Fast mode requires extra usage billing
... (536 total messages over 32 seconds, firing every ~33ms)
16:35:21.249 Fast mode unavailable: Fast mode requires extra usage billing

Key details:

• 536 re-renders in 32 seconds (~30fps)
• blit=0, write=1012 (100.0% writes) — full screen rewrite every frame, no incremental diffs
• The loop starts after Org fast mode: disabled (extra_usage_disabled) is received
• The loop eventually self-stabilizes and input becomes responsive

Expected behavior:
The fast mode status should be checked once (or debounced) and not trigger a render loop. A status of extra_usage_disabled should be a terminal state that
doesn't cause re-renders.

Impact:
The first ~30 seconds of every session are effectively unusable for typing. More noticeable on WSL2 where PTY throughput is lower, but the unnecessary render
loop would waste CPU on any platform.