Hi, this was my test! The plan-mode prompt has been largely unchanged since the 3.x series models and now 4.x get models are able to be successful with far less direction. My hypothesis was that shortening the plan would decrease rate-limit hits while helping people still achieve similar outcomes. I ran a few variants, with the author (and few thousand others) getting the most aggressive, limiting the plan to 40 lines. Early results aren't showing much impact on rate limits so I've ended the experiment.
Planning serves two purposes - helping the model stay on track and helping the user gain confidence in what the model is about to do. Both sides of that are fuzzy, complex and non-obvious!
(It's worth reading the gh comment I linked if you're interested in terminals!)
tl;dr other programs like Neovim and Codex use the "alternate screen buffer" which means they don't use scrollback and reimplement their own scrolling. CC uses scrollback (because that's what most users expect) which it has to clear entirely and redraw everything when it changes (causing tearing/flickering). There's no way to incrementally update scrollback in a terminal.
(I also want to add some more flavor to the 1/3 metric because I don't want it to be mis-interpreted. "30% of the time you use CC it flickers" isn't quite accurate - it's dependent on screen height and what you do. Most people will not see _any_ flickers at all. Some people with short screens (typically VSCode users because by default the terminal opens fairly short) will see flickers. Previously, if something rendered offscreen users would see a flicker for _every subsequent frame_ regardless of wether anything was actually changing. Now they will only see a flicker occasionally when it's _absolutely_ needed. Once or twice vs thousands.
Additionally, the metric really tracks when CC emits a "clear scrollback" operation. If the user is in a terminal that supports DEC 2026 they won't see a flicker even if we emit that clear scrollback command.)
Most people's mental model of CC is that "it's just a TUI" but it should really be closer to "a small game engine". For each frame our pipeline constructs a scene graph with React -> layout elements -> rasterize them to a 2d screen -> diff that against the previous screen -> _finally_ use the diff to generate ANSI sequences to draw. We have a ~16ms frame budget so we have roughly ~5ms to go from the React scene graph to ANSI written. You're right that in theory we shouldn't have to do much work, but in practice that's required optimizations at every step.
For the GC pauses specifically, what mattered is predictable performance. More allocations == more GC == more frames where the VM is locked up seemingly doing nothing. On slower machines we were seeing this be in the order of seconds, not ms and when somebody is typing all they feel is the 1 character that's stuttering. Honestly, I was surprised about this too as GC in JS is often not something that's too impactful.
How tall is your tmux pane? If it's very small it might still flicker as CC tries to redraw scrollback. I've noticed several tmux users have layouts where they stack several panes on top of each other making each one quite short.
Another option is to rebuild tmux from latest source so it buffers synchronized output, which should prevent the flicker entirely.
If you're still seeing a terrible flicker please file a `/bug`!
The communication is definitely on me! There honestly wasn't much new to say -I've been slowly ramping since early Jan just to be extra sure there's no regressions. The main two perf. issues were:
1. Since we no longer have <Static> components the app re-renders much more frequently with larger component trees. We were seeing unusual GC pauses because of having too much JSX... Better memoization has largely solved that.
2. The new renderer double buffers and blits similar cells between the front and back buffer to reduce memory pressure. However, we were still seeing large GC pauses from that so I ended up converting the screen buffer to packed TypedArrays.
Hi! I work on TUI rendering for Claude Code. I know this has been a long-standing frustration — it's taken longer than any of us wanted.
The good news: we shipped our differential renderer to everyone today. We rewrote our rendering system from scratch[1] and only ~1/3 of sessions see at least a flicker. Very, very few sessions see flickers in rapid succession which was so annoying before. Those numbers will keep dropping as people update.
We've also been working upstream to add synchronized output / DEC mode 2026 support to environments where CC runs and have had patches accepted to VSCode's terminal[2] and tmux[3]. Synchronized output totally eliminates flickering. As always, I recommend using Ghostty which has 2026 support and zero flicker.
Planning serves two purposes - helping the model stay on track and helping the user gain confidence in what the model is about to do. Both sides of that are fuzzy, complex and non-obvious!