chrislloyd

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.

I believe the CC editor extensions and Zed's ACP both use the Claude Agent SDK.

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.

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

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.

[1]: https://hledger.org [2]: https://blog.danslimmon.com/2019/07/15/do-nothing-scripting-... [3]: https://github.com/adept/full-fledged-hledger

If they drove profits to zero by distributing it to their members, wouldn't that incur income tax?

What is something that you think the average HN user would find useful/surprising about Life? How could it apply to their daily lives?

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.

Interesting reading along the same lines is Language Oriented Programming (1994) http://www.gkc.org.uk/martin/papers/middle-out-t.pdf

Attend incident postmortem meetings.

I hadn't thought of personal learning as a multi-armed bandit problem before! Thank you.

If anybody is interested in reading more about Henry George and a land-value tax, Radical Markets[1] has an in-depth chapter on it.

[1]: http://radicalmarkets.com

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.

By that reasoning (which I mostly agree with) making it cheaper to build great experiences is a good thing to do.

From https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2755844

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

I highly recommend Beancount and Ledger-likes[0] too. Mint-style net-worth trackers have limited usefulness. Once you have visibility into your assets, you'll likely want to take more active management of them. Modelling that with spreadsheets is possible but can become complicated quickly and you'll likely end up re-inventing a lot of established accounting practices. A disclaimer: Ledger-like systems are described as whole "all bran" of personal finance - there's steep learning curve but once you get through that you'll have a powerful, life-long tool.

[0] https://plaintextaccounting.org

Same as what other commenters have suggested, both runtime and compile time checks are useful. We'd like to consolidate around Flow (our docs specify flow types) but just haven't gotten around to adding/vetting that Babel plugin (or alternatives). I'd personally like to just use static types but it would mean that all users would have to use Flow + our specific version of Flow.

Thanks! It's been a big group effort. We've put a lot of work into them (with much more to come) and they've massively helped Gestalt's adoption in both the eng. and design orgs.

Not currently, though this is a question that gets asked a lot.

One of the benefits of Gestalt is that all styling is statically resolvable. This means that all it's CSS can be built to one small file or inline styles. We get a bunch of perf. & portability for free. (Unconstrained) theming requires runtime style resolution which would negate those benefits. There are also things that we'd like to be able to change and tweak globally and those get difficult if everybody is running separate themes. We recently switched to using system fonts and we're planning on bumping the color contrast.

However, we're generally _really_ open to constrained theming (i.e. more button colors).

I (alongside some very talented people) work on this. AMA!

I'd love you to go into more detail with this proposal. How would taxing ads be different than just taxing corporations?

If they wanted to get more extreme, they could take the initial filing fee as a deposit and only refund it with successful applications. That would help prevent the persistent applications and incentivize the USPTO to reject more. In the eyes of the examiner, the value of the patent has to be worth more to them through society than the individual filing fee.

I’ve used Ohm for a few small parsers. What’s great about the editor is that you can take it and share it with somebody else and they’re given insights into _how_ the parser works.

I identify with conservative economic policies but liberal social policies. My views around a whole bunch of topics have changed over time. What option should I select when I sign up?

I'd be very curious to hear about the OPs specific experience with Flow. I've found the opposite to be true of Flow vs Typescript with the added benefit that Flow is easy to integrate into an existing codebase.