Claude Chill: Fix Claude Code's flickering in terminal
github.com
github.com
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...
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
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.
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.
You mean like a laptop that is trying to stay cool (aka, cpu throttling) on battery power while Claude is running a slightly different version of the test suite for the 5th time to verify it didn't break anything?
Yeah, the typing latency is really bad in those cases. Sometimes waiting for 40 seconds or more.
...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!
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.)
I'm using the latest version and see terrible flicker in tmux still. You guys should be ashamed tbh.
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.
Am I missing some complexity here?
If I cannot follow what the thing is doing the tool becomes useless and expensive.
I use Kitty + zellij, I love TUIs and use them all over the place, this is the only tool I know with this issue.
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`!
> 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.
Thanks for the update!
Besides the UI, it isn't much more than "while llm hasn't made final response, interpret any tool calls and repeat" to the current agents, what exactly would they be using from Claude Code if not the UI? Most of the stuff the agents do is fairly basic, implementation-wise.
Besides the point, but I hadn't heard about that. I take it's about this? https://news.ycombinator.com/item?id=46625918, if so, seems to been reasonable since OpenCode was trying to use endpoints not meant for them?
> They’ve blocked OpenCode from accessing the private Claude Code endpoints. These were not advertised or sold as usable with anything else. OpenCode reverse engineered the API and was trying to use it.
Now where have I seen that before.
> A few months ago, users started reporting that Ghostty was consuming absurd amounts of memory, with one user reporting 37 GB after 10 days of uptime.
> ...
> The leak was present since at least Ghostty 1.0, but it is only recently that popular CLI applications (particularly Claude Code) started producing the correct conditions to trigger it at scale. The limited conditions that triggered the leak are what made it particularly tricky to diagnose.
> The fix is merged and is available in tip/nightly releases, and will be part of the tagged 1.3 release in March.
basically, the rapid replay of the entire conversation history (the CC bug) somehow interacts destructively with something in tmux, causing it to be 10 times worse. The “flicker” becomes a multi-second delay while I wait twiddling my thumbs…
i’ve seen this in every terminal, including ghostty… as nice as ghostty is, expecting everyone to use it is kinda meh (at least support Wezterm too, lol)
I'm not even using it particularly hard. Usually only one agent is running with possibly one sub-agent on occasion. Which is confusing because I've heard of people running ten at once and only then running into this issue...
Possibly related, I DID only upgrade to the $200 tier a few days ago... might there be a now-stale API rate limit in place?? Or maybe it's the long-running multi-compacted context that's the problem?
My account is tied to lumbergh-at-gmail-dot-com
I'm a dev so of course, happy to help run it down from my end
This tool is amazing btw. I'm currently working on a never-existed-before app that would have been impossible before AI... And it's going quite well
I had to use Codex today cause claude kept scrolling up every time the window lost focus. It was so annoying. macOS iTerm
Sounds like only is a bit misplaced. IMHO such bugs that take forever to fix make Anthropic seem very unprofessional.
I’m starting to think that the reason why anthropic doesn’t open source Claude code isn’t due to competitive reasons, it’s because they don’t want people to see what a mess their code base is.
Maybe they bought Bun to increase the rate of flickering so that the text looks solid again
if Amodei hadn't said "90% of code will be written by AI", at least I wouldn't call them hypocrites, but the fact that the company that makes such wild claims can't fix a freaking flicker and scroll issue until an indie-dev steps in just shows how far behind their product is from their claims.
I have CC and use many models with it (Codex in CC, try it!), but I won't let Anthropic "lecture" us about how "the roots of the problem go deep". Literally no other CLI tool has these issues: opencode, codex, gemini, droid, etc.
https://github.com/anthropics/claude-code/issues/769
I locally patched the closed-source CLI npm package but it's not perfect. They would have to switch how their TUI is rendered on their side.
Apparently OpenAI Codex is rust+ratatui which does not have this issue.
example: `ranger` is written in python and it's freaking slow. in comparison, `yazi` (Rust) has been a breeze.
Edit: Sorry, I meant GIL, not single thread.
You probably mean GIL, as python has supported multi threading for like 20 years.
Idk if ranger is slow because it is written in python. Probably it is the specific implementation.
They also probably mean TUIs, as CLIs don't do the whole "Draw every X" thing (and usually aren't interactive), that's basically what sets them apart from CLIs.
https://github.com/jquast/blessed
One reason for the lack of python might be the timing of the TUI renaissance, which I think happened (is happening?) alongside the rise of languages like Go and Rust.
> We originally built Claude Code on Ink, a React renderer for the terminal. [...] Over the past few months, we've rewritten our rendering system from scratch (while still using React).
https://github.com/anthropics/claude-code/issues/769#issueco...
Using TS, React here doesn’t make sense for stability in the long term. As you can see, even when they replaced Ink and built their own, the problem still exists.
There are other alternatives that are better than whatever Anthropic did such as Bubbletea (Go) or Ratatui (Rust) which both are better suited for this.
Maybe they were thinking more about job security with TypeScript over technical correctness and a robust implementation architecture and this shows the lack of it.
While not universally applicable, it's very convenient during development to focus on State without thinking about View, or focus on View without thinking about State.
The concept itself has nothing to do with the actual renderer: HTML, TUI, or whatever. You can render your state to a text file if you want to.
So the flickering is caused either by a faulty renderer, or by using a render target (terminal) that is incompatible with the UI behavior (frequent partial re-renders, outputting a lot of text etc.)
We moved from the go+bubbletea based TUI which had performance and capability issues to an in-house framework (OpenTUI) written in zig+solidjs
Any web react project out there will install react AND react-dom, which is the son implementation of react.
It’s how react translates into mobile, web, etc so well.
It defines contracts and packages like react-dom handle th specific implementation.
Good grief get me off this sloppy ride.
Should it be solved by now? Yes. If anyone on the team is dogfooding it in a typical tmux environment, its painful. But lets give them some leeway here.
To your point about hiring 1000 devs not solving anything: I agree. For a project of this scope, you’re probably going to peak at one or two 3 person teams with at least one principal dev per team with deep experience in the tech stack and in architecting/building TUIs in general. I would hope their devs are making a relatively lucrative salary too, to attract talent.
I have no idea what the internal structure is so this is just pure speculation: judging by the backlog of issues on their GH, they could use better community management and developer relations. I suspect they’re riding on the existing hype/community interest to fulfill these functions but that only provides a piece of the puzzle.
I think thats probably 1 team short, but I agree on the order of magnitude. So if we assume 12 devs, how long do we think its going to take to fix 5k github issues lol?
Again, I 100% agree the flicker bug should be at the top of the list. And I agree their products in general are riddled with bugs. But Im just saying I can understand the situation even if I think this specific bug should have been fixed already if they were regularly using a setup that runs into it (which I have to assume they arent).
And we solved this problem over 30 years ago? Ncurses was made for this. The buffer is kept in memory, you hit page-up and it renders the previous page, page-down and it renders the next page, let it roll and it renders each successive page as a stream, or just the last page, etc.
Sometimes Claude Code scrolls up far away, and I struggle to scroll it down again. And I have to restart the terminal and Claude Code for it to behave well again. But I don't know if this is the flickering issue, or if it's due to a bug in Windows, Alacritty, Zsh or something else.
nit but CC itself doesn't write anything, much like a body w/o brain doesn't program anything. it's possible the OP was using other models like codex/gemini/etc. in CC.
You just can’t use their private APIs, which isn’t really surprising.
It would be a game changer for mobile usage.
We've rewritten Claude Code's terminal rendering to reduce flickering by 85% - https://news.ycombinator.com/item?id=46312507 - Dec 2025 (3 comments)
Anthropic: Please fix this ASAP
Ha! The irony is not lost on anyone.
"We've built the world's most advanced AI coding assistant. It can refactor entire codebases, debug complex issues, and ship production features autonomously. Anyway, here's a terminal bug that makes your screen look like a slot machine. We'll get to it eventually."