[elliot07]

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

[chrislloyd]

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.

[catlifeonmars]

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.

[pqtyw]

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?