anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-21 17:56:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

High CPU usage since 1.1.60 using Ghostty #9268

New Issue
Open
opened 2026-02-16 18:12:02 -05:00 by yindo · 7 comments
yindo commented 2026-02-16 18:12:02 -05:00
Owner
Copy Link
Copy Source

Originally created by @akhansari on GitHub (Feb 13, 2026).

Originally assigned to: @rekram1-node on GitHub.

Description

Since version 1.1.60, when I have some plugins, and I run opencode in Ghostty, I have systematically high CPU usage.

  • Without any plugins, it's ok.
  • When I rollback to 1.1.59 with plugins, it's ok.
  • When I switch to another Ghostty tab or another window, it stops the CPU usage.
  • With Alacritty, it's ok.

I already tried to clean ~/.local/share/opencode and ~/.cache/opencode.

Plugins

@sveltejs/opencode

OpenCode version

1.1.65

Steps to reproduce

  1. add plugins like @sveltejs/opencode or @nick-vi/opencode-type-inject
  2. run opencode in Ghostty

Screenshot and/or share link

No response

Operating System

Fedora Cosmic Atomic

Terminal

Ghostty

Originally created by @akhansari on GitHub (Feb 13, 2026). Originally assigned to: @rekram1-node on GitHub. ### Description Since version 1.1.60, when I have some plugins, and I run opencode in Ghostty, I have systematically high CPU usage. - Without any plugins, it's ok. - When I rollback to 1.1.59 with plugins, it's ok. - When I switch to another Ghostty tab or another window, it stops the CPU usage. - With Alacritty, it's ok. I already tried to clean `~/.local/share/opencode` and `~/.cache/opencode`. ### Plugins @sveltejs/opencode ### OpenCode version 1.1.65 ### Steps to reproduce 1. add plugins like `@sveltejs/opencode` or `@nick-vi/opencode-type-inject` 2. run opencode in Ghostty ### Screenshot and/or share link _No response_ ### Operating System Fedora Cosmic Atomic ### Terminal Ghostty
yindo added the bugperf labels 2026-02-16 18:12:02 -05:00
yindo commented 2026-02-16 18:12:02 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Feb 13, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #9358: CPU usage is high (also with plugins)
  • #12513: [Performance] Critical CPU usage and memory leak even when starting a new session (also with oh-my-opencode plugin)
  • #12255: cpu and memory is high at the latest version (starting from v1.1.50)

All of these report similar CPU/memory spikes when running opencode with plugins. This might help with finding the root cause if it's plugin-related.

@github-actions[bot] commented on GitHub (Feb 13, 2026): This issue might be a duplicate of existing issues. Please check: - #9358: CPU usage is high (also with plugins) - #12513: [Performance] Critical CPU usage and memory leak even when starting a new session (also with oh-my-opencode plugin) - #12255: cpu and memory is high at the latest version (starting from v1.1.50) All of these report similar CPU/memory spikes when running opencode with plugins. This might help with finding the root cause if it's plugin-related.
yindo commented 2026-02-16 18:12:02 -05:00
Author
Owner
Copy Link
Copy Source

@dekoza commented on GitHub (Feb 13, 2026):

I'm using ghostty and instead high CPU usage I see memory leaks since at least 1.1.56 - extended sessions grow up to 50% of memory, then it eats the CPU and gets killed.

@dekoza commented on GitHub (Feb 13, 2026): I'm using ghostty and instead high CPU usage I see memory leaks since at least 1.1.56 - extended sessions grow up to 50% of memory, then it eats the CPU and gets killed.
yindo commented 2026-02-16 18:12:03 -05:00
Author
Owner
Copy Link
Copy Source

@segordon commented on GitHub (Feb 13, 2026):

I'm using ghostty and instead high CPU usage I see memory leaks since at least 1.1.56 - extended sessions grow up to 50% of memory, then it eats the CPU and gets killed.

same here, but I see this after switching from konsole to ghostty for exactly the same reasons, so I tend to believe it's not the terminal emulator..

@segordon commented on GitHub (Feb 13, 2026): > I'm using ghostty and instead high CPU usage I see memory leaks since at least 1.1.56 - extended sessions grow up to 50% of memory, then it eats the CPU and gets killed. same here, but I see this after switching from konsole to ghostty for exactly the same reasons, so I tend to believe it's not the terminal emulator..
yindo commented 2026-02-16 18:12:03 -05:00
Author
Owner
Copy Link
Copy Source

@aaronnewsome commented on GitHub (Feb 13, 2026):

For me, the memory usage spins out of control and then the system starts swapping like crazy and eventually my system is unresponsive completely. I added more ram to get to 8gb but it also exhausted that too. I have to kill the entire system to get control back since I can't ssh in, use the UI or really do much of anything except power down. I'm not using any plugins that I'm aware of, but for me the app is not usable in the current state. I've migrate the VM to another host and give it 32GB of ram to see if that helps but it seems excessive that it was even able to completely exahaust 4 and then 8GB of ram.

@aaronnewsome commented on GitHub (Feb 13, 2026): For me, the memory usage spins out of control and then the system starts swapping like crazy and eventually my system is unresponsive completely. I added more ram to get to 8gb but it also exhausted that too. I have to kill the entire system to get control back since I can't ssh in, use the UI or really do much of anything except power down. I'm not using any plugins that I'm aware of, but for me the app is not usable in the current state. I've migrate the VM to another host and give it 32GB of ram to see if that helps but it seems excessive that it was even able to completely exahaust 4 and then 8GB of ram.
yindo commented 2026-02-16 18:12:03 -05:00
Author
Owner
Copy Link
Copy Source

@segordon commented on GitHub (Feb 13, 2026):

For me, the memory usage spins out of control and then the system starts swapping like crazy and eventually my system is unresponsive completely. I added more ram to get to 8gb but it also exhausted that too. I have to kill the entire system to get control back since I can't ssh in, use the UI or really do much of anything except power down. I'm not using any plugins that I'm aware of, but for me the app is not usable in the current state. I've migrate the VM to another host and give it 32GB of ram to see if that helps but it seems excessive that it was even able to completely exahaust 4 and then 8GB of ram.

If you can stand the possible process crashes I would suggest tuning whatever out-of-memory killer your system uses to be extra sensitive to the terminal emulator and opencode process to prevent total system instability. the only reason i'm not losing my VMs all together during these events is the use of an OOM killer w/ terminal emulator tuned to have a higher OOM score.

https://unix.stackexchange.com/questions/153585/how-does-the-oom-killer-decide-which-process-to-kill-first

it sucks to babysit the thing for when the emulator eats itself but at least it's a bit less friction ( maybe? ) than a VM restart.

@segordon commented on GitHub (Feb 13, 2026): > For me, the memory usage spins out of control and then the system starts swapping like crazy and eventually my system is unresponsive completely. I added more ram to get to 8gb but it also exhausted that too. I have to kill the entire system to get control back since I can't ssh in, use the UI or really do much of anything except power down. I'm not using any plugins that I'm aware of, but for me the app is not usable in the current state. I've migrate the VM to another host and give it 32GB of ram to see if that helps but it seems excessive that it was even able to completely exahaust 4 and then 8GB of ram. If you can stand the possible process crashes I would suggest tuning whatever out-of-memory killer your system uses to be extra sensitive to the terminal emulator and opencode process to prevent total system instability. the only reason i'm not losing my VMs all together during these events is the use of an OOM killer w/ terminal emulator tuned to have a higher OOM score. https://unix.stackexchange.com/questions/153585/how-does-the-oom-killer-decide-which-process-to-kill-first it sucks to babysit the thing for when the emulator eats itself but at least it's a bit less friction ( maybe? ) than a VM restart.
yindo commented 2026-02-16 18:12:03 -05:00
Author
Owner
Copy Link
Copy Source

@sageil commented on GitHub (Feb 14, 2026):

Using Ghostty with only superpowers plugin, it takes around 10 to 15 seconds to open with a noticeable CPU spike. Wezterm starts in less than 3 seconds using the same configs

@sageil commented on GitHub (Feb 14, 2026): Using Ghostty with only superpowers plugin, it takes around 10 to 15 seconds to open with a noticeable CPU spike. Wezterm starts in less than 3 seconds using the same configs
yindo commented 2026-02-16 18:12:03 -05:00
Author
Owner
Copy Link
Copy Source

@akhansari commented on GitHub (Feb 16, 2026):

It's definitively the TUI.
I have no issues with opencode web or using alacritty.

(I wish opencode was written in Rust or Go... First time I have so many issues with a CLI/TUI and my workflow is fully in terminal)

@akhansari commented on GitHub (Feb 16, 2026): It's definitively the TUI. I have no issues with opencode web or using alacritty. (I wish opencode was written in Rust or Go... First time I have so many issues with a CLI/TUI and my workflow is fully in terminal)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label bug perf
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#9268
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?