| ▲ | chilipepperhott 5 hours 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. |
|
| ▲ | thesmtsolver2 3 hours ago | parent | next [-] |
| For some reason, idling Claude Code needs 100% of my CPU. |
| |
| ▲ | nicce 2 hours ago | parent [-] | | Like Google’s AI studio tab in browser. Incredible degrade in software quality? |
|
|
| ▲ | toephu2 3 hours ago | parent | prev | next [-] |
| I have iterm2 open right now with Claude in a long session and it's only using 500MB of memory. |
| |
| ▲ | pizlonator 3 hours ago | parent [-] | | Only 500MB! you are confirming their point even as you contradict the specifics | | |
| ▲ | ChrisLTD 4 minutes ago | parent | next [-] | | Yeah. Bonkers considering the brain of the application isn’t even on your device. | |
| ▲ | z3c0 2 hours ago | parent | prev [-] | | 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. | | |
| ▲ | deathanatos 2 hours ago | parent | next [-] | | But each day now that overhead becomes more costly as AI drives up the very cost per byte of RAM. | |
| ▲ | verdverm 2 hours ago | parent | prev [-] | | they make one of those electron apps too |
|
|
|
|
| ▲ | davidatbu 35 minutes ago | parent | prev | next [-] |
| 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. |
|
| ▲ | andriy_koval 4 hours ago | parent | prev | next [-] |
| Maybe that gigabyte is occupied by useful information: traces/memory? |
| |
| ▲ | overgard 3 hours ago | parent | next [-] | | A gigabyte is a lot of memory. Even the largest context windows are a small fraction of that with any sane engineering discipline. | | |
| ▲ | andriy_koval 3 hours ago | parent [-] | | 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. |
| |
| ▲ | javcasas 4 hours ago | parent | prev [-] | | Nope. Used to render on the terminal like a game engine. https://x.com/trq212/status/2014051501786931427 | | |
| ▲ | oersted 3 hours ago | parent | next [-] | | 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. | | |
| ▲ | overgard 3 hours ago | parent [-] | | 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 |
| |
| ▲ | ux266478 3 hours ago | parent | prev | next [-] | | 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. | |
| ▲ | fg137 3 hours ago | parent | prev | next [-] | | Do game engines constantly have buffer issues? | | | |
| ▲ | lstodd 3 hours ago | parent | prev | next [-] | | I sorta remember Quake console running on an 486dx2 .. | |
| ▲ | krapp 3 hours ago | parent | prev [-] | | 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. | | |
| ▲ | ux266478 3 hours ago | parent [-] | | 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. |
|
|
|
|
| ▲ | 5 hours ago | parent | prev | next [-] |
| [deleted] |
|
| ▲ | Jtarii 3 hours ago | parent | prev | next [-] |
| Well, they could very easily if they wanted. There is just no economic value in it. |
|
| ▲ | asdfman123 4 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | j2kun 4 hours ago | parent [-] | | 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%? | | |
| ▲ | asdfman123 3 hours ago | parent [-] | | 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. | | |
| ▲ | fg137 3 hours ago | parent [-] | | In other words, performance is almost always an afterthought. | | |
|
|
|
|
| ▲ | Lplololopo 4 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | bpodgursky 4 hours ago | parent | prev | next [-] |
| 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. |
|
| ▲ | cpursley 5 hours ago | parent | prev [-] |
| 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. |
| |
| ▲ | ale 5 hours ago | parent | next [-] | | Incoming rust rewrite branch ready to merge: +1,009,257 -4,024 | |
| ▲ | canadiantim 5 hours ago | parent | prev | next [-] | | People already rebuilt Claude Code in Rust after the Claude Code leak, it's on github as claw code (and other variants) | |
| ▲ | jcarver 5 hours ago | parent | prev [-] | | [dead] | | |
| ▲ | rytill 4 hours ago | parent [-] | | 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? | | |
| ▲ | jcarver 4 hours ago | parent [-] | | Great question. The MCP protocol has gotten a bad rap for wasting context due to most MCP clients dumping tool definitions directly into context, which is wasteful. Aether doesn’t do that. It uses an opt-in "proxy" that puts MCP tool schemas on the filesystem so the agent can browse, search and load the tool schemas it needs progressively. As for motivation there's several advantages to taking a MCP 1st approach, including: 1. It allows Aether to be a truly blank slate agent as 0 tools are hardcoded into the core runtime. 2. It allows users to extend Aether using any language they want 3. MCP gives a standard way to deal with local+remote tools, progress notifications, permission prompts (e.g. ask the user to allow/deny a tool call), OAuth flows etc. 4. There's a big ecosystem of existing MCP servers users can connect to But that's all optional, you can just as easily give Aether a single Bash tool and only use CLIs too. |
|
|
|