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.
MCPs goal is to standardize the transfer of application context and tool definitions to a client (let’s ignore prompts for the moment). That’s the same goal as Hypertext. In HTML, context is <p>, <img/> etc. and “tools” are <form>, <a> and <button>s. Instead of separating the two (like in MCP) - it’s all included in the same document.
I’ve used MCP quite a bit but perhaps I’m misunderstanding something? Happy to hear why you think it’s “wacky”.
MCP strikes me as roughly equivalent to HTML. Headline features like dynamic “tool” discovery (and more!) are solved well with HTML.
MCP is probably easier for clients to implement but suffers from poor standardization, immaturity and non-human readability. It clearly scratches an itch but I think it’s a local-minimum that requires a tremendous amount of work to implement.
I have a very similar setup but with HLedger[1]. A "do-nothing"[2] script helps me download statements by opening bank websites, waits for manual import and finally checks balances. That makes it a lot less repetitive and error prone. Or at least, I catch the errors faster.
I've found HLedger and Shake to be fast enough to process almost a decade of finances. Dmitry Astapov has an extremely well produced tutorial workflow[3].
How have you managed the PDF parsing? Mine has become a bit of a mess dealing with slight variations in formatting as they change over time. I've been considering using LLMs but have been nervous about quality.
The other benefit of codegen in situations like this (a company wide schema) is the potential for multi language bindings. Entgo demonstrates this by bridging a Go ORM, SQL migrations and a GraphQl schema.
I've found being "fun for programmers" to be undervalued. Using Ledger is fun, which has caused me to spend more time thinking and understanding my personal finances which have in turn improve my personal finances. I haven't cared as much using less hackable tools.
> g Likert has never done; engages a higher level of thoughtfulness; attenuates extremism to expose deeper insight; and predicts behavior better than Likert at high levels preference intensity.
Basically extreme views and polarization are poorly weighted in large populations and this can be _exposed_ by QV.
The biggest shift in my mental model of React was considering it closer to a programming language than traditional UI libraries. Dan hints at this when describing how it is used to manipulate view trees and proposing special syntax for hooks.
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!