Hacker News Reader

Comment by chrislloyd | Hacker News Reader

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

View on HN

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.

I think this is the main issue. When I would get into flickering mode, it appeared that the entire TUI was re-rendering on every key press. I don’t know if it’s maybe just the limitation of Ink or even terminals.

Well vim doesn’t flicker so it’s definitely not a limitation of terminals, but you’re probably right about the Ink/React stack.

So why are you stuck with ink/react stack?

I don’t use React/Ink for anything, what do you mean?

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.

Maybe the problem is using React for that.

Thanks for the in depth explanation! I think the comparison to a game engine makes a lot of sense. Is the diff just part of the react rendering engine, or is it something you intentionally introduce as a performance optimization? Mostly I’m wondering how much the diff saves on rendering performance if you’ve already generated a 2D raster. In the browser, this saves on API calls to the DOM but at that point you haven’t rendered anything resembling an image. Is this what helps to resolve flickering, perhaps?

Can I ask why you used JavaScript at all for CC? Or even React for a simple UI? It seems misaligned with the app’s nature. This bug, GC pauses, everything else you mention… This isn’t criticism, because I believe people make good judgements and you and Anthropic will have good reasons! It’s just puzzlement, in that I don’t understand what the balance judgement was that led you here, and having experienced all the issues it led to I would love to know what the reasons were. Thankyou for any insights you can share :)

Supposedly using react allows CC to have structured output so it can understand what’s on the screen.

Should have used Go with Bubbletea.

What the fuck? What's wrong with idk, ncurses?

TUI development is a lost art these days, apparently.

TUIs are experiencing something of a renaissance, I think. My hypothesis is that the popularity attracts newcomers who inevitably bring their own preconceptions from other domains. Many are unaware of the state of the art and reinvent the wheel. I don’t think this categorically a bad thing, but it can be a mixed bag of slop and genuinely useful cross-pollination.

Code sharing with their web app. Layouts. Event handling. Not wanting to reimplement all that from scratch when React and Ink is a popular and full featured option.

> 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.

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.

Presumably they had no clue how to fix it and just ignored it and pretended everything works fine because they didn't want to admit it?

On the Ghostty recommendation, read this first - https://mitchellh.com/writing/ghostty-memory-leak-fix

> 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.

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.

> I figured if there was a way to make your own UI on top of Claude Code, surely OpenCode would have used it?

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.

Sure but that doesn't explain why OpenCode was basically barred from using Claude Code.

Why would they need to use Claude Code? If you're building your own thing, why would you have to use your "competitors" thing to build you own thing? Something doesn't make sense there.

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.

While I have you on the line, I'm also experiencing tons of API request timeouts using Claude Code's own TUI client (on the $200/mo plan!!) and I don't know how to mitigate that, and it is frustrating

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

> differential rendering

Now where have I seen that before.

> and only ~1/3 of sessions see at least a flicker

Sounds like only is a bit misplaced. IMHO such bugs that take forever to fix make Anthropic seem very unprofessional.

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).

after trying out Claude Cowork, I can definitely believe it was vibe coded

Can you guys give this some love? https://github.com/anthropics/claude-code/issues/769

I had to use Codex today cause claude kept scrolling up every time the window lost focus. It was so annoying. macOS iTerm

> 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

(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.)

There is absolutely a way to incrementally update scrollback in a terminal, 100% flicker-free. Whether it works in every terminal is a different question. But if you can accept that your code will work in pretty much every modern terminal -- this is absolutely doable. I double people are still using xterm and other older terminals for this. And in that case, you can fall back to this more compatible way.

Seeing massive slowdowns in console interactions today... is there a correlation? Others here at my work are seeing it too!

> 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.

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?

It’s really hard, because they’re trying to use a hammer as a hacksaw. It was simply made with ridiculous technology choices.

I think you described 99% of commercial software :)

This seems stupid but after evaluating Claude vs Codex, this problem alone made me pick Codex.

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.

Well it's for profit company and a closed code app. How cares about "hurting their feeling" or whatever? Harsh criticism seems perfectly appropriate here...

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’ve noticed the issue with tmux more than with specific terminals.

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)

Reply on news.ycombinator.com