This is a decades-old design pattern when CPU >> IO. Emacs has been doing just that since the 80s, when people were complaining about "Eight Megs And Constantly Swapping". See "redisplay" [1]
This minimizes screen flash. You can't rely on terminals doing double-buffering.
> This minimizes screen flash. You can't rely on terminals doing double-buffering.
GUI and TUI have different architecture model. Most GUI have have a 2D surface that is redrawn multiple times per second. Double buffering is for decoupling update and render. TUI is a grid of characters that are updated one at a time via an active element, the cursor. Double buffering there is very wrong. Like adding airbags to a bicycle.
There’s a reason you see most old TUI either have an option to redraw the screen (automatically like top, or manually) and those that have a scrolling option allow to scroll by page. The TTY (the underlying concepts) used to be slow and it can be slow today as well (ssh connection). You need to be thoughtful about whole screen updates.
It's not recognizing that they are just one building block that should do one thing well, like tmux.
You don't need a computer display on your fridge for the same reason, but Anthropic think you do. You should see virtual ice getting created and they should correspond to the actual ice behind the door - think of how amazing that is!
And it's not even completely a bad idea. make it claude-code-react-beauty of some way to take it off, it would be far more palatable.
I love the idea of installing high resolution cameras in the fridge to monitor the ice maker to feed into a vision model that renders digital ice to the exact position of the real ice on the fridge’s giant screen
Put a servo on the door and a camera on the front. Train a vision model to recognize when your eyes are looking at the door and automatically open it for you.
Another camera inside will detect when you are done and close it.
React part maybe. The rest is what any TUI that's using ncurses would do. :)
It really bothers me that most of the TUI harnesses are using 100% CPU quite a lot just printing stuff to terminal. Seems ridiculous.
I guess it comes from syntax highlighting/formatting, which is probably not done incrementally, but over the entire so far displayed block of output, recomputed from the beginning for each new streamed in character. Can't imagine anything else causing the rendering to gradually grind to halt when eg. thinking block is open in opnecode and updates get palpably slow as it grows.
Terminal output itself is fast and consumes almost nothing. You can have 60fps terminal apps that update content every frame and that consume almost no CPU time.
> Terminal output itself is fast and consumes almost nothing. You can have 60fps terminal apps that update content every frame and that consume almost no CPU time.
The TUI mode is a client-server architecture. An analogy would be like an html page where all content is updated server side. Try to do 60 fps and you’ll have flickering as well.
No. Fetching pages from remote server will just make the client wait for I/O. That takes 0 CPU load and if the server can't respond at 60fps, lowered redrawing frequency would mean even less CPU load from the terminal redrawing itself.
This does not explain 100% CPU load these harnesses sometimes exhibit.
> We have a ~16ms frame budget so we have roughly ~5ms to go from the React scene graph to ANSI written.
It looks like video frame, full framebuffer, generated and parsed at 60fps. It surprises me they haven't introduced GPU shaders, 16x oversampling and raytracing. Maybe for next release.
Also you forgot "render to a framebuffer, then parse the framebuffer back to chars".
Anyway, I'm off to construct the new `ls` command. It will render the list of files to a mesh of billions of polygons in a GPU with advanced shaders, 16x oversampling, HDR and all the graphic acronyms I don't understand, then read the resulting image, find the nearest character in the ANSI charset and use that one.
Could be improved. Encode the image to webp with high compression settings and handle the ASCII mapping by spinning up a local LLM to do OCR on it. Individually. For each cell.
My roguelike's "graphics" are a simulated terminal, so it's a 2D grid of colored characters. It's essentially a TUI, just like Claude Code, except instead of rendering to a real terminal using ANSI escapes, I render to a web canvas using... something probably more complex than what Claude has to do. It's still not hard.
They forgot to add 'make it as simple as possible' in the prompt is one possible cause.
On a more serious note using a react-like lib for TUI in the hope you'll share the codebase with the web version is a more likely explanation. Still not the best idea.
React is not that stupid to re-render in a loop at 60fps and instead waits for changes to happen before re-rendering. It even batches changes and stuff.
You don't need React for reactive TUIs - at all. I can understand chosing React for web, but for a TUI it sounds like a really poor idea. And in practice we can see that the claude code TUI is also poor.
It doesn’t need to be that complex, but it can be that complex without being slow. Claude Code’s interface is extremely simple. It has tons and tons of headroom to tack on performance overhead without it being noticeable at all. You just have to not do dumb things like redraw the entire UI every time a spinner spins.
"We made our app chew up so many unnecessary resources that we can use even more resources in the future, and no one will notice" is not the strongest engineering idea I've ever heard.
I can't help but think it's their engineer's and PM's making these decisions, since I know that if you asked Claude to write a TUI there is no world it would recommend whatever the frontend architecture of claude code is.
~ "it's not a TUI! <describes an outrageously overengineered TUI> and my dad works at Nintendo"
curses, bud. curses.
It's genuinely difficult to tell how much of this is true. The post is obviously 100% posturing, but some of the words describe things that could be done.
Very few game engines do anything I'd describe as rasterisation. That's kind of the point of a GPU. Well, it used to be.
I suppose "small game engines" might be more likely on average to include a rasteriser. The typical reason for this is because the author wanted to write it.
Whereas big engine make triangle give hardware go brrr.
So I assume here 'rasterize' means 'printf'.
And diffing screens means diffing 50..150 lines of text.
And "generating ANSI sequences to draw" means 'printf' with some ANSI sequences interpolated in.
Then there's the frame budget. You have to understand they are operating within a strict frame budget -- they're not messing around, OK. They have a 16 ms frame budget, so they burned 11 ms and now have a (roughly) ~5 ms approx. budget for the final 'printf' in the chain???
Your broader point is well taken but I thought I'd stop by with some trivia. High end engines such as unreal will rasterize absurd quantities of micro-geometry manually using compute shaders in order to avoid the bottleneck of the hardware rasterizer.
High end engines such as unreal have the excuse of being tasked with rendering millions of polygons, in which case a complex approach makes sense. Claude Code is only being asked to render a few thousand UTF-8 characters.
> For each frame our pipeline constructs a scene graph with React then
-> layouts elements
-> rasterizes them to a 2d screen
-> diffs that against the previous screen
-> finally uses the diff to generate ANSI sequences to draw
So I’m wondering what ‘rasterizing’ literally means in this case. I imagine it’s just creating a 2D map of elements at a very low (probably character) resolution, then diffing that against the last generated map to come up with an optimal ANSI sequence to send to the terminal, would that be right?
Seems like a cool puzzle to solve. I wonder what the engineering and organisation tradeoffs were that lead to it — does it let them reuse a bunch of existing code?
I wrote a TUI library back in the day for Turbo Pascal — it was essentially taking an immediate-mode approach (which in this context is just a fancy way of saying it was procedural haha).
"Rasterizing" means just one thing in this context: to transform a data structure into an array of pixels. It seems absurd to do this, given that the next step must be to convert back from pixels to text data, but maybe they have some way to generate predictable sequences of pixels (e.g. the character "t" is always rendered as the same pattern of pixels), such that they're cheap to convert back.
If they're doing anything else, the word "rasterizing" is being misused.
Yes, the much more plausible explanation is that the word rasterize was misused there. They are generating and diffing text data which has been a standard approach to drawing a TUI since the dawn of computing. It is not even remotely resource intensive.
> They are generating and diffing text data which has been a standard approach to drawing a TUI since the dawn of computing. It is not even remotely resource intensive
No one has ever done that. Even top[0], which does full screen refresh, clear the screen (if necessary) and write the new information (the period is in seconds, not ms). No need to diff. That would be like diffing a file, just to find which bytes to update.
I don't understand why you would make such a confident negative claim rather than ask for an example or otherwise engage in discussion. Particularly given that you replied to a comment elsewhere in this very thread that links to a real world example of exactly such an implementation! [0] See in particular this part of the source. [1]
I agree that most programs don't bother to do that but please recall that my claim was merely that what Claude Code is claimed to be doing with regards to diffing is a well established and long standing optimization. The important point being that it is neither expensive, novel, or particularly complex thus not an excuse for poor performance.
The emacs code is not purely diffing. They already have the final output, they’re mostly comparing it to see a cheaper way to update than render the output. I’m pretty sure the curses library have the same thing.
But ink, the library Claude is using, defines a tree data structure for the main concept. The diff there is about comparing the old tree and the new tree created by the update, and then updating the node that has changed. That means if a single character change inside a bing panel, the whole thing is rewritten. And if you have something that is updating a lot, that means flickering.
The diffing that ink does is just architecturally wrong. You can create a dom, but a dom is not a concept for the terminal. It’s up to you to optimize its rendering. But just diffing the dom structure like react does is not optimizing, it’s busywork.
Hmm I thought this was due to me using tmux with claude-code, also it seems that `claude agents` doesn't have this issue.
By comfortable ergonomics, meant the forgiving and asynchronous input system. You can start typing, cancel, retry with previous input, accumulate messages while the agent is active. I don't know all TUIs but this is not common IMO.
> You can start typing, cancel, retry with previous input, accumulate messages while the agent is active. I don't know all TUIs but this is not common IMO.
Literally every audio player or anything that uses threads.
good point, i didn't classify tui audio players in a way, they don't converse, they allow asynchronous effects and stacking, that said i might be lagging about these, last i used was mocp, any names i should check out ?
Maybe Claude is operating at a higher, self-improving level than all of us poor HN commenters. Wasting the local machine's resources to look pretty is a plausibly deniable way to make the Claude Code FE unusable with local LLMs, starving the competition.
I dont think they need to optimize their infrastructure (at least not from their perspective). They have high-end PCs with 64GB of RAM, so 1GB doesn't matter to them. For example, I have 8GB of RAM, and I make my apps very performant. Honestly, I probably wouldn't bother if I had 16GB+ of RAM
For useful things, by the computer's owner. It's not there to be used just because Anthropic can't be bothered to give a shit about the quality of their product.
> which eats 1GB+ of RAM. Meanwhile, my editor only consumes 80MB of RAM
And why are you comparing Claude Code to your editor?
> They can't even improve Claude Code
That depends on how you define "improve". They've added a ton of features to it over time. Who said minimizing RAM usage was something they are prioritizing right now?
> why are you comparing Claude Code to your editor?
Because the editor does more. All the compute-intensive parts of the agent are in the cloud. Zero reason for an agent harness to require anything beyond a potato to run.
You can ask LLMs about high-level techniques, and their answers will usually be good enough.
What you can't get from LLMs is the taste and judgment, which you can only obtain by having a strong CS base and coding manually for years.
High-level techniques were never a problem. You could Google tens of articles on this topic. They are useless too, it's like learning how to drive a racing bicycle from reading a book. Sure, you will know a lot about nuances, but you will fail miserably when it comes to a real race.
The other day I just wanted to loop through characters in a std::string to copy data to a new string with a few escape characters (sending to peripheral device). Simple enough task for AI. I got a coroutine monstrocity back, with copies to std::array and a range based iterator, since I specified C++23. If I specified C++11, I would have received a:
char p = src.data();
while (p)
{
…
p++;
}
I had the experience to keep calling out AI to simplify and downgrade the solution to something primitive, which ended up smaller, faster, easier to maintain. Juniors with real world experience would not bother, they’ll take the first working AI result.
taste and judgment, which you can only obtain by having a strong CS base and coding manually for years.
I disagree, the definers of taste; art and food critics, movie and book reviewers, don’t need to have learned the craft by doing. Taste is a separate skill.
No one seriously expects a food critic to be able to cook a Michelin-starred meal. The job of that kind of critic is to be insightful and entertaining, and it's very different to the taste required to create top quality food, which is a combination of solid technical skill and creative flair.
Taste in coding is a combination of insight, experience, native talent, technical skill, and flair. Tasteful coding produces clever but straightforward minimal elegant solutions that an average developer can't imagine but can adapt and maintain.
If critics were forced to be actually skilled at the craft of creation, the world would be infinitely better off. Both the cello and the player are better off by the cello maker also finally being the cello player. Alienation was a mistake and this part Marx of all people understood well.
This is why "critical thinking" is a meme. Being a critic takes no skill. I want far fewer critics and far more constructive thinking. GenAI being the ultimate constructor is a bonus.
I'd say taste is a consequence of lifestyle, which is learned by doing. And art critics often have bad lifestyle, which is visible in their bad taste. When art is virtual life, it would define a lifestyle, which is adopted by doing, in its turn producing taste.
> which you can only obtain by having a strong CS base and coding manually for years.
I hope this isn’t the case. It is the route I took, but it also doesn’t seem to be a likely route going forward. Strong CS grounding is feasible for sure, but I have a hard time believing that a meaningful number of people will be spending the requisite years coding manually.
Can you show me an example of a hard task that can't be achieved using light models? When we don't want the model to work on autopilot without reviewing the code at all. Even SOTA models will produce garbage code, if you don't guide them all the time.
Hard tasks require a lot of guidance and code reviewing, unless you are creating another throw away project where correctness, maintainability and code understanding does not matter.
How many more months do we need to wait, until big companies realize that flash models work just fine if you:
1) Don't ask LLMs for big changes
2) Review everything and point them in the right direction
Large models still suck at big changes, they produce questionable architecture and you still have to review the code, if your project is serious enough.
The codebase quickly become a mess, if you don't pay enough attention. Does not matter which model.
So why bother with big models, when flash models are 10x cheaper and much faster to iterate under guidance? Large models can be used for security and bug audits. Flash models work almost the same for changes under 300 LOC when you dictate how you want your code to look.
It's pretty simple; organizations are willing to tolerate paying $1500/month/engineer, which seems to be roughly inline with "normal" consumption for most full-time engineers. If that number grows significantly, then I bet companies will start exploring flash models more, as you propose.
They are willing to tolerate it now, which is quite a switch up from the free for all we had a few weeks ago, and if they aren’t able to tie in this new ~$1500p/m cap to demonstrable productivity and revenue increases then that will be kneecapped even faster
There are plenty of expenses in this order of magnitude that are not tied to direct increases in productivity. I think it may become a serious hiring impediment for companies to be really skimpy on these budgets for example.
There was a time when some employees wanted 1000$ per month for rent, imagine that.
It's absolutely insane, 1500 * 12 is north of 17K dollars, I know that in Google outside of few specific cities and roles.
Getting a 17k bump in salary is good enough to switch, if I was being 17k extra I am more than willing to use my local qwen and hand code most if not all stuff.
Companies can pay for code review tools to make life easier but writing code with AI if it's 10-15% pay cut is just too much.
Everyone is happy right now because this money hasn't been a line item in your salary/benefits.
Imagine 10k yearly AI allowance, I will probably just ask to keep that money.
All the work I do if I was judicious I could do just as much with a 20$ spend or on a local model.
Few tasks need Mythos like models, and if your task does you are already doing too much with AI
The easy decision is to just go with the biggest SOTA model you can afford.
But this overlooks the other critical part of getting the most out of these things: the harness. I run an autonomous plan/design/code/build/test pipeline with agents using my own orchestrator. Different models are better at different stages, and I use LLMs to judge the output between them. Not everything needs Opus 4.8.
The harness provides both the scaffolding to get the right things into the model, and the right things out. But it also lets you dictate which model does which work.
It's the pipeline, not the model, that gets you quality at a given token budget.
If you had a business task to complete that was only possible with ai and it cost you >$1500/month of work, how long would you have to delay the task so that it's cheaper long run to buy hardware and do local models?
$1,500/mo * 14 months = $21,000.
If local models are 14mo behind as many in HN say it may be profitable to just wait. Maybe just spend a few hundred dollars of your tokens and buy hardware piece by piece.
Nearly no one is doing anything that is “only possible with AI”. This doesn’t seem like a relevant calculation. People spend on AI as an investment in their current productivity.
I agree, outside of the AI bubble, there's a lot of wait-and-see happening in the B2B world right now, I'd say we're currently 6-8 months into that 14 months.
I wonder to what extent models should figure out which model to forward a query to. Or perhaps the big models could learn the difference between an easy and a hard question and charge accordingly? Perhaps, if it can measure complexity, even generate a quote?
Small models are fine for small coding tasks but I don't see why big ones can't be broken down most of the time.
Many harnesses do this, I've recently dropped all my big subscriptions for using deepseek. Codewhale (formerly deepseek-tui) will use pro for large tasks and route smaller ones to flash. It's pretty good, but I just use pro and everything as the cost is quite low.
This one does not have routing, but reasonix is insane, absolutely insane for saving money. I've used 1.3billion tokens at the cost of 4$. (99-100% cache hit)
> I wonder to what extent models should figure out which model to forward a query to. Or perhaps the big models could learn the difference between an easy and a hard question and charge accordingly?
This sounds like something a harness could do (and might already be doing), with work delegated to subagents running on lower-cost models.
I'm legit annoyed at opus 4.8 at any setting above 4.8.
I believe it can be great for vibe coding, but mundane day work? Hell no, I'd rather work with Haiku. It's too slow, checks too many things, it's annoying as hell.
It is targeted at tech literate people who obviously know about reader's mode, that they can load a custom css or not even load a css and set the font and size of their choice from their web client.
It’s still ugly as hell, the contrast ratios are godawful and it makes me question why I’d even do that to my eyes. Target or not, this is really hard to read.
Or... just hit the reader mode browser button that has been standard for years longer than LLMs have existed.
I had a coworker talking about how great some AI coding tool is because it can sort a bunch of strings alphabetically for him. This coworker is a programmer. Working with a language that has a builtin sort function.
It all depends on the code quality bar. If it's high, a lot of tasks will not be completed much faster. The main speed comes from trusting LLMs output. When you review each change and reprompt LLMs to make the code look like you want. Suddenly, things become much slower and reviews/reprompts are very mentally exhausting.
reply