Developers can develop leaner applications, but they're usually not incentivized to.
Frankly, I love efficiency too, but I've hard to learn the hard way that what the market wants is features. Or at the very least, the executive team wants that.
Their whole argument is that AI's added efficiency means they don't need to set aside valuable human time anymore. Why can't they just point Claude at Claude Code and ask it to reduce memory usage by 90%?
You can do that. But I'm telling you, in tech (and enterprise shops I've worked at too) they don't care.
I'm using the internal Google tools and it's helping me write code much faster too, but it still takes time. I could make the CLI tool I work on faster, but no one cares except the end users, and their minor concerns have no impact on our internal politics.
At the end of the day you have to do what you're paid to do, unfortunately.
And highlighting a disconnect in the developer community. Some of us are okay with unnecessary overhead for quick results. I always felt gross dealing with Electron apps, but they're popular for a reason.
Followup: I closed out Claude completely, iterm2 completely. Reopened iterm2, and it appears iterm2 is using about 500MB of memory. So this has nothing to do with Claude Code CLI.
Traces and memory are text. A gigabyte of text is an insane amount. That is an equivalent of tens of millions of lines of code, or hundreds of millions of AI tokens.
This kind of immediate-mode rendering is quite standard for TUIs. Although immediate-mode rendering tends to be significantly simpler and use less memory than retained-mode rendering, at the cost of some redundant computation. So I am not sure if this is the reason for the bloat.
It’s possible that it doesn’t play well with JS garbage collection, since it recreates the whole UI structure for every frame (which tends to not to be an issue in the languages immediate-mode is usually employed).
But yes it’s a bit more akin to game renderings than web rendering. Which can be totally fine if done well.
I haven't tried to make a TUI admittedly, but double buffering is the oldest technique on the planet. A TUI doesn't even need to pay the cost of a lot of pixels since its effective resolution is much lower
How on earth are you spending more than 50us on a UI like this from start to finish? What the actual hell? 11ms to construct a scenegraph of this complexity? I don't even know what to say to that.
If I saw our UI show up in the profiler eating 5ms of CPU time every frame, I'd send whoever was responsible to QA hell until they find some way to redeem themselves. Not even fancy animated 3D UIs, like what you get in Death Stranding, eat up these kinds of resources. Not even remotely close.
So would you take these claims seriously if they came from OpenAI (since Codex is a pretty lean CLI app)?
If so, I think it would be in the spirit of HN to discuss the subject matter of the blogpost (increasingly autonomous coding towards the end goal of RSI) as if the blog post was indeed from OpenAI. OpenAI is, by all accounts, going through a very similar process anyways.
A came here just to write: Pretty please let it churn for a few nights and redo Claude Code in Rust. Because the harness is very very good as are their models, but that node thing is a hog for no good reason at all.
They obviously don't care, aren't making any attempt whatsoever to do this, and 99% of users don't care either.
If you want to pollute your own priors with weird artificial litmus tests, it's a free country, but the artificial world-model you build in your head does not affect the real world around you.
https://news.ycombinator.com/newsguidelines.html