4 ms·

I never knew that running an interactive program in my terminal would absolutely rinse my CPU and battery but that's what Claude, OpenCode and Ghostty have coll

by ljm 3mo ago

I never knew that running an interactive program in my terminal would absolutely rinse my CPU and battery but that's what Claude, OpenCode and Ghostty have colluded to achieve. Even when the laptop is asleep overnight it's practically melting. I'm sure there was some logical reason for shoehorning web technology into this stack given that we have a good 40 years or so of experience with interactive terminal programs that use curses/ncurses, alongside emacs, vim, almost the entirety of MS-DOS, and so on.

deleted 3mo ago
[deleted]
senderista 3mo ago
Why are you implicating ghostty? Have you compared its CPU usage to any other terminal?
- agrippanux 3mo ago
  I don't know if its still the case anymore since 1.3 but Ghostty did have a documented issue with Claude causing resource issues.
- tdhz77 3mo ago
  I think the author is saying everything that touches llm.
- ljm 3mo ago
  Of course I have. If I see ghostty constantly consuming the most energy and helping reduce my battery life to barely 2 or 3 hours, the first thing I'm going to do is switch terminal to see if I can improve that situation. The built in terminal and WezTerm have been fine and I've had much more reasonable battery life since. This does not even speak to it pegging my CPU and keeping the fans running on full blast even when the laptop is supposed to be idle overnight.
  - st3fan 3mo ago
    Same. I really want to file a proper bug report for this but I haven't been able to really dig into the details and the last thing I want is a "ghostty is a cpu hog" kind of report without useful info on how to debug that.
  - andruby 3mo ago
    This seems a suspicious. How do you measure the CPU load of Ghostty? Is the measure/reporting method just attributing the cpu load of the commands/programs you're running in Ghostty to Ghostty? You could test this by running "yes > /dev/null" in Ghostty. In Activity Monitor on my Macbook it shows `yes` using 100% and Ghostty using 0.5% of cpu.
  - benrutter 3mo ago
    If you're looking for a non-ghostty recommendation (not that I have anything against ghostty) I use alacritty + zellij and it works fantastic. It doesn't seem to impact battery, I certainly get good battery usage on both my work and home laptops.
    - mtlmtlmtlmtl 3mo ago
      I've messed around with pretty much all the fancy new terms to varying extents. Ghostty, wezterm, alacritty, etc. And I'm all in favour of people innovating in this space again. But at the end of the day, I always end up back with xterm. It's reasonably lightweight, runs and is packaged absolutely everywhere, I never have to muck about with termcap files and/or $TERM on remote hosts, and I've never had it break, crash, or exhibit any kind of bug or strange behaviour in over a decade of using it. The only TUI that has some quirks in xterm is Emacs, but Emacs has weird quirks in every term I've tried to run it in, and different quirks in every case somehow, so I just chalk that up to Emacs being weird. I'm sure xterm has some bugs buried in it still, but I bet all of them are in codepaths that are almost never reached nowadays, or at least are extremely niche. It does lack some features like ligature fonts(I just decided not to care), sixels and similar graphics things(again, don't really care) and panes/tabs/yadda yadda(tmux or screen or whatever you like can do all of that anyway). Never had to dig through the xterm bug tracker to figure something out. I don't even know what version I'm running, or even what the versioning scheme looks like. I haven't changed the configuration since the first time I set it up. It just works.
myaccountonhn 3mo ago
Its so wasteful, but that tracks with the modus operandi of AI companies.
vmg12 3mo ago
The fundamental problem with all Js based apps is how they are very single threaded. With js you get 1 thread at 100% utilization. Power usage and heat scale non-linearly with cpu utilization and 100% utilization on a single threaded js app means you will have ui lag. Other languages like golang would split work across 8 threads and have 8 threads at 20% utilization and this would result in less power usage. Claude Code would have been better off performance wise being an electron app because it would be offloading rendering to the browser and gpu. Also, the architecture of Open Code is actually a lot better here than Claude Code. ClaudeCode does everything, including rendering in a single thread and it's all in js. OpenCode has a zig based tui renderer it offloads that work onto. But I will also say these coding agent tuis do get unfairly maligned because they launch subprocesses and those subprocesses tend to be expensive. If you are using Rust analyzer with claude code, it's rust analyzer that's causing the majority of your problems.
- cozzyd 3mo ago
  I'm not concerned with CPU use/wakeups while actively using it, but with it sitting idle doing nothing.
- skydhash 3mo ago
  That’s not really a big issue. In major OS like the BSD, SMP implementation are not that old. If we can have a full OS running in single core mode, we can have an application being performant too. I’m currently running OpenBSD on 4 cores and it’s basically 99% idle. Bad coding is just bad coding.
  - vmg12 3mo ago
    It's basically idle because it's not doing anything. If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work. It's also all cpu bound work. The majority of the stuff on your screen is being rendered by the gpu.
    - wild_egg 3mo ago
blt 3mo ago
yep, developers from 10 or even 5 years ago would have considered it a hilarious joke
LtWorf 3mo ago
> Even when the laptop is asleep overnight it's practically melting. Then something is waking it up and it's not asleep at all. Asleep the CPU shouldn't be running.

by ljm 3mo ago

deleted 3mo ago

[deleted]

senderista 3mo ago

Why are you implicating ghostty? Have you compared its CPU usage to any other terminal?

agrippanux 3mo ago
I don't know if its still the case anymore since 1.3 but Ghostty did have a documented issue with Claude causing resource issues.
tdhz77 3mo ago
I think the author is saying everything that touches llm.
ljm 3mo ago
Of course I have. If I see ghostty constantly consuming the most energy and helping reduce my battery life to barely 2 or 3 hours, the first thing I'm going to do is switch terminal to see if I can improve that situation. The built in terminal and WezTerm have been fine and I've had much more reasonable battery life since. This does not even speak to it pegging my CPU and keeping the fans running on full blast even when the laptop is supposed to be idle overnight.
- st3fan 3mo ago
  Same. I really want to file a proper bug report for this but I haven't been able to really dig into the details and the last thing I want is a "ghostty is a cpu hog" kind of report without useful info on how to debug that.
- andruby 3mo ago
  This seems a suspicious. How do you measure the CPU load of Ghostty? Is the measure/reporting method just attributing the cpu load of the commands/programs you're running in Ghostty to Ghostty? You could test this by running "yes > /dev/null" in Ghostty. In Activity Monitor on my Macbook it shows `yes` using 100% and Ghostty using 0.5% of cpu.
- benrutter 3mo ago
  If you're looking for a non-ghostty recommendation (not that I have anything against ghostty) I use alacritty + zellij and it works fantastic. It doesn't seem to impact battery, I certainly get good battery usage on both my work and home laptops.
  - mtlmtlmtlmtl 3mo ago
    I've messed around with pretty much all the fancy new terms to varying extents. Ghostty, wezterm, alacritty, etc. And I'm all in favour of people innovating in this space again. But at the end of the day, I always end up back with xterm. It's reasonably lightweight, runs and is packaged absolutely everywhere, I never have to muck about with termcap files and/or $TERM on remote hosts, and I've never had it break, crash, or exhibit any kind of bug or strange behaviour in over a decade of using it. The only TUI that has some quirks in xterm is Emacs, but Emacs has weird quirks in every term I've tried to run it in, and different quirks in every case somehow, so I just chalk that up to Emacs being weird. I'm sure xterm has some bugs buried in it still, but I bet all of them are in codepaths that are almost never reached nowadays, or at least are extremely niche. It does lack some features like ligature fonts(I just decided not to care), sixels and similar graphics things(again, don't really care) and panes/tabs/yadda yadda(tmux or screen or whatever you like can do all of that anyway). Never had to dig through the xterm bug tracker to figure something out. I don't even know what version I'm running, or even what the versioning scheme looks like. I haven't changed the configuration since the first time I set it up. It just works.

myaccountonhn 3mo ago

Its so wasteful, but that tracks with the modus operandi of AI companies.

vmg12 3mo ago

The fundamental problem with all Js based apps is how they are very single threaded. With js you get 1 thread at 100% utilization. Power usage and heat scale non-linearly with cpu utilization and 100% utilization on a single threaded js app means you will have ui lag. Other languages like golang would split work across 8 threads and have 8 threads at 20% utilization and this would result in less power usage. Claude Code would have been better off performance wise being an electron app because it would be offloading rendering to the browser and gpu. Also, the architecture of Open Code is actually a lot better here than Claude Code. ClaudeCode does everything, including rendering in a single thread and it's all in js. OpenCode has a zig based tui renderer it offloads that work onto. But I will also say these coding agent tuis do get unfairly maligned because they launch subprocesses and those subprocesses tend to be expensive. If you are using Rust analyzer with claude code, it's rust analyzer that's causing the majority of your problems.

cozzyd 3mo ago
I'm not concerned with CPU use/wakeups while actively using it, but with it sitting idle doing nothing.
skydhash 3mo ago
That’s not really a big issue. In major OS like the BSD, SMP implementation are not that old. If we can have a full OS running in single core mode, we can have an application being performant too. I’m currently running OpenBSD on 4 cores and it’s basically 99% idle. Bad coding is just bad coding.
- vmg12 3mo ago
  It's basically idle because it's not doing anything. If you are streaming in markdown and code and then doing syntax highlighting on this code in real time, then rendering it on the screen you are doing actual work. It's also all cpu bound work. The majority of the stuff on your screen is being rendered by the gpu.
  - wild_egg 3mo ago

blt 3mo ago

yep, developers from 10 or even 5 years ago would have considered it a hilarious joke

LtWorf 3mo ago

> Even when the laptop is asleep overnight it's practically melting. Then something is waking it up and it's not asleep at all. Asleep the CPU shouldn't be running.