Comment by f311a
3 months ago
Infrastructure is a much harder problem. They can't even improve Claude Code, which eats 1GB+ of RAM. Meanwhile, my editor only consumes 80MB of RAM.
3 months ago
Infrastructure is a much harder problem. They can't even improve Claude Code, which eats 1GB+ of RAM. Meanwhile, my editor only consumes 80MB of RAM.
This might explain it, in the opposite way it was meant to:
https://fxtwitter.com/trq212/status/2014051501786931427
> Most people's mental model of Claude Code 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 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
Yup. Overengineering.
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.
[1] https://github.com/emacs-mirror/emacs/blob/c29071587c64efb30... or a more user-friendly overview, Daniel Colascione's seminal "Buttery Smooth Emacs", snapshotted at e.g. https://gist.github.com/ghosty141/c93f21d6cd476417d4a9814eb7...
4 replies →
It's like the Citrix of AI :-D
1 reply →
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.
4 replies →
It's product bloat.
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.
8 replies →
Yup. For me, this translates to "we are using Ink, the react-compatible TUI framework to build Claude Code"
What is "frame" in this context? Video frame, or something else?
2 replies →
Care to explain how you'd engineer it instead?
4 replies →
As someone who maintains a roguelike with a terminal-like UI that:
1. Maintains an internal representation of what the game thinks is on screen.
2. Runs the game for one frame which updates that representation.
3. Generates a diff to see how that differs from what's actually on screen.
4. Executes the minimum set of draw calls to get the screen to match the internal representation.
It's really not that hard. It's a few hundred lines of code.
Sure. For a videogame.
> -> rasterizes them to a 2d screen
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.
It will be _glorious_ (and profoundly stupid)
5 replies →
I hadn't seen that quote before, what an embarrassing thing to go on the internet and write...
Why the hell does it need to be so complex? People have been making TUIs for decades. Did we need a small game engine to run claude code?
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.
3 replies →
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.
3 replies →
Must have 120 fps for answers arriving in [buffering] 30 seconds.
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 is an excellent example of how LLMs let you try new ideas, even if they aren’t necessarily good ones
~ "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.
2 replies →
> 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
That’s rather sickening.
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).
5 replies →
I can't still conceive the fact that a tool that only send/receive text from an external API consumes an absurd amount of RAM
> https://fxtwitter.com
What is this?
Proxy that makes Twitter links embed on discord, for whatever reason. Something about api access without accounts I assume
1 reply →
Well it runs on something they didn't design (Electron) using GUI library they didn't design (React)
For company with that much AI you'd think if it was actually good, doing that part in fast and performant way would be "easy"
It runs in a terminal, it’s not electron
Somebody read/watched too much Casey Muratori.
No, somebody didn't read/watch enough Casey Muratori.
this allows for comfortable ergonomics IMO
not that it could be leaner for sure but i get the reasoning behind the tui rendering layer
comfortable ergonomics? you can't scroll up more than 50 lines before it starts to garble up text
i'd be ashamed of publishing software with this level of polish as a solo dev, let alone as the hottest multibillion startup on the planet
3 replies →
when they announced /pet mode or whatever - that was really the end of the line for me.
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.
And yet, nobody that writes game engines would do it this way because game engines need to be efficient..
If they used an actual game engine to render a 3D UI from scratch it would be more efficient
Try 64K! https://en.wikipedia.org/wiki/Turbo_Pascal
Also remember when XP was super bloated cause it needed 64MB?
I loved Turbo Pascal....
I loved XP. My laptop had 256MB of RAM.
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
The purpose of RAM is to be used.
> The purpose of RAM is to be used.
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.
[dead]
> 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.
Do you work for Anthropic or something?
You seem weirdly invested in defending bad decisions.
Even if you're and AI booster, shouldn't you want a better UI?
They're a multi billion dollar company. Surely they can dedicate a small amount of their resources to improving UX?
> And why are you comparing Claude Code to your editor?
Because Claude Code is also used to - get this - EDIT CODE. It fills the same purpose as an editor, it just has extra hooks for their agentic garbage.