Comment by chilipepperhott
3 months ago
I find any and all claims like this ridiculous from a company who can't build a terminal application that uses less than a gigabyte of RAM.
3 months ago
I find any and all claims like this ridiculous from a company who can't build a terminal application that uses less than a gigabyte of RAM.
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something."
https://news.ycombinator.com/newsguidelines.html
For some reason, idling Claude Code needs 100% of my CPU.
Like Google’s AI studio tab in browser. Incredible degrade in software quality?
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.
4 replies →
I have iterm2 open right now with Claude in a long session and it's only using 500MB of memory.
Only 500MB!
you are confirming their point even as you contradict the specifics
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.
2 replies →
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.
Yeah. Bonkers considering the brain of the application isn’t even on your device.
Maybe that gigabyte is occupied by useful information: traces/memory?
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.
A gigabyte is a lot of memory. Even the largest context windows are a small fraction of that with any sane engineering discipline.
For each LLM interaction they likely have bunch of thoughts traces, tool calls, etc, which don't go to context, but still can be retrieved.
But I obviously don't know for sure.
Nope. Used to render on the terminal like a game engine.
https://x.com/trq212/status/2014051501786931427
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.
2 replies →
> render on the terminal like a game engine
All those CPU to render this effect
https://x.com/cyrilXBT/status/2060617507615207904
1 reply →
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.
1 reply →
Frankly that's an insult to gamedev. Literally every game engine I can think of could do better. Probably even Unreal Engine could do better.
1 reply →
I sorta remember Quake console running on an 486dx2 ..
1 reply →
Do game engines constantly have buffer issues?
1 reply →
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.
Well, they could very easily if they wanted. There is just no economic value in it.
Really? Let me explain how bigger companies work:
They have different teams for different departments with different type of people.
So the team or teams responsible for writing the terminal application are different people than the researchers doing the learning.
This can lead to dimentral quality aspects.
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.
Incoming rust rewrite branch ready to merge: +1,009,257 -4,024
People already rebuilt Claude Code in Rust after the Claude Code leak, it's on github as claw code (and other variants)
[dead]
I checked out your agent and it looks pretty well designed. Congrats on starting to share it with others!
One thing I noticed: "Your Tools: Aether agents get tools exclusively via MCP servers." "...Aether ships with 1st-party MCPs for file system operations..."
Can you share your thoughts on why you decided to use MCP as the core tool abstraction? I have heard many decry MCP as being context-wasteful. Is this not the case with your agent?
1 reply →
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.