Claude Code has a big problem

Claude Code’s flicker and sluggishness trace back to a tight rendering budget and a terminal environment that punishes “React-style” updates—especially when the app must redraw or re-layout large portions of the UI under real-world conditions like resizing, long scrollback, and frequent garbage collection.

A key detail from the internal engineering discussion is the frame budget: Claude Code targets roughly a 16-millisecond cadence, leaving only about 5 milliseconds for the terminal-specific work that turns the computed UI into ANSI sequences. That narrow window matters because terminal rendering isn’t just “slower DOM.” Terminals are effectively byte- and escape-sequence limited: updating earlier content requires sending additional control codes to reposition the cursor and overwrite prior lines, which can balloon the amount of data sent and the amount of state the renderer must track. When the renderer misses its frame budget, flicker and jitter show up.

The performance debate also hinges on how React’s virtual DOM model behaves in an append-only output system. React’s strength comes from diffing and committing changes when it can update the “real world” representation efficiently. In a terminal, the “real world” is built by writing text and escape sequences; to change something, the system often has to locate the right region in scrollback and overwrite it. That means React-driven re-renders can translate into large bursts of terminal output—even when only a small part of the UI changed—because the terminal must be coerced into the right state via escape commands.

Resizing exposes another mismatch. Browsers provide explicit resize events and well-defined layout feedback loops. Terminals don’t offer the same standardized signals, so Claude Code has to infer dimensions and patch behavior around terminal quirks. The discussion points to intercepting SIGWINCH, disabling scrolling while measuring the pseudo-terminal size, recalculating layout, then patching differences and restoring scroll behavior. This is the kind of work that makes the experience feel “browser-like,” but it also increases complexity and the chance that rendering falls behind.

Garbage collection becomes a practical failure mode. In some terminal/OS combinations, the rendering pipeline triggered GC too often—an issue that only appears after shipping to diverse environments. When GC pauses land inside the frame window, the renderer misses deadlines, producing flicker.

The transcript also contrasts Claude Code with other terminal UI approaches. Libraries like ncurses and modern Rust TUIs (e.g., ratatouille, used by OpenAI’s Codex alternative) can rely on a standard scroll buffer and different rendering strategies. Some apps use “alt mode” to avoid polluting the terminal’s normal scrollback, which changes selection, copy/paste, and scroll behavior—often requiring custom selection logic and clipboard handling.

Overall, the argument isn’t that React is inherently wrong for terminals, but that the terminal’s constraints make React’s diff-and-rasterize pipeline expensive in ways that are easy to underestimate. The engineering goal, as framed here, is less about raw milliseconds and more about maintainability and safe iteration—keeping changes from breaking other parts of a large codebase while still meeting a 60 fps target. The result: Claude Code can be usable day-to-day, but its worst-case rendering paths are where the system’s architectural tradeoffs show up as lag, flicker, and jitter.