Comment by chrislloyd
8 hours ago
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.
Happy to answer questions!
[1]: https://github.com/anthropics/claude-code/issues/769#issueco... [2]: https://github.com/xtermjs/xterm.js/pull/5453 [3]: https://github.com/tmux/tmux/pull/4744
Why has public comms been so poor on this issue? There's been lots of Github issues posted in the Claude Code repo with lots of new comments each day screaming into the void, but radio silence from Anthropic since the revert in December. It's clearly causing a lot of frustration for users leading to clever workarounds like this.
It was obviously a complex issue (I appreciate that and your work!). But I think there's a lot to be improved on with communication. This issue in particular seems like it has lost a lot of user trust - not because it was hard to solve and took awhile - but because the comms and progress around it was so limited.
Eg issues: * https://github.com/anthropics/claude-code/issues/1913 * https://github.com/anthropics/claude-code/issues/826 * https://github.com/anthropics/claude-code/issues/3648
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.
I’m really surprised that GC is an issue at the bits/sec throughput a TUI would be pushing. At the risk of making an obvious observation: your render loop is doing way too much work for what it is producing.
2 replies →
Have you guys seriously considered decoupling the TUI / UI so anyone can write their own on top of Claude Code proper? I love how Zed did it, but its not always the most stable experience, but it is definitely better than staring at a TUI.
Thanks for the update!
I believe the CC editor extensions and Zed's ACP both use the Claude Agent SDK.
Interesting, I'm only an end-user so I don't know too much about it, but the reason I ask is because of "OpenCode" or whatever it was called, that people were using instead of Claude Code itself, I figured if there was a way to make your own UI on top of Claude Code, surely OpenCode would have used it? Not sure whatever came of that whole fiasco. I never used OpenCode, but I like having the option to swap UIs as needed.
1 reply →
> differential rendering
Now where have I seen that before.
I wonder how much of Claude Code is developed using Claude?
A lot of it, and their Claude Cowork is all claude's work (according to claude code's creator).
> only ~1/3 of sessions see at least a flicker.
...after many months, for such a visible bug, is such a crazy thing to say.
In case the above comes across as too hostile, to balance this, I would say thank you to the claude code team for such an amazing product!
More than 30% of the times you use Claude Code it "flickers"? That can't be right? I use neovim and codex side by side with tmux, both flicker about 0%, what is Claude Code doing that makes it flicker so much? Seems strange
> 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.
I'm using the latest version and see terrible flicker in tmux still. You guys should be ashamed tbh.
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`!
Thanks for your response.
> 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.
It's full screen ("maximized" as tmux calls it).
> Another option is to rebuild tmux from latest source so it buffers synchronized output, which should prevent the flicker entirely.
I'll give it a shot.
I'm sorry for the low quality comment, but man, get some perspective.
> low quality comment
What else do you want me to say? It's ironic that one has to jump through hoops (like this post) to get basic functionality right in a tool that claims it'll replace software engineers.
Perspective is: how hard can it possibly be? It’s a TUI. This should be able to run on a calculator.
Am I missing some complexity here?