OpenCode is heavily cpu-bound #21470
Description
Description
In my experience with claude, most of the time is spent waiting on external tools or model API calls, but with opencode + gemini-3.1, it seems the overwhelming majority of time is in opencode itself. My current session has 300k tokens at $8.30 spent, but opencode itself has over 1.5hrs of CPU time. Has it been profiled at all? Is there any appetite to re-implement parts of it in something faster than js (multithreaded rust?). I am willing to contribute in this direction if it's something that would be accepted.
Plugins
None
OpenCode version
1.4.0
Steps to reproduce
No response
Screenshot and/or share link
Operating System
MacOS 26.4, M5 Max
Terminal
WezTerm
Reacted by Lee B, dlopez-legrand, Daniel, Arek, Ehtz, imp4ct7, Motoi Washida, yaronshanisima, Nikita Rudenko, Sou Chanrojame and 10 more
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Apr 8, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is distinct (e.g., specific to token processing overhead vs. rendering/streaming), please add more details to differentiate it.
mrjared16 commentedon Apr 8, 2026
I suspect there’s a regression in version 1.4.0, as CPU usage has spiked even higher than before
lopdan commentedon Apr 9, 2026
I'm experiencing the same issue. Lately, opencode has been killing my EC2 machine with just one session open, whereas before I could run multiple sessions for long periods without any problems
mrjared16 commentedon Apr 13, 2026
It's been almost a week, but there is no update. I guess I'll stick with v1.3 for now
imp4ct7 commentedon Apr 26, 2026
I'm experiencing the same problem on Linux Kubuntu 25.10 on Ryzen R9-5900HS with OpenCode version 1.14.25 ( 1.4.0 Flatpak the same issue ) , it takes 50% of CPU with doing nothing. When model is running it takes almost 100% but model is remote so this is weird.
murbot commentedon Apr 28, 2026
I love opencode but it's almost unusable for me over the past day. CPU is pinned at 100% and it just hangs and takes forever to do anything. I've noticed high CPU in the past, but this is next level. I primarily use it in web mode these days, but I did switch back to terminal to confirm the issue exists there as well.
Lauritz-Timm commentedon May 1, 2026
I am seeing the same thing of opencode using a lot of CPU, but mostly on 1 core.
Processor:
AMD Ryzen™ 7 7735HS with Radeon™ Graphics × 16
Operating system:
Ubuntu 24.04
kirill-dev-pro commentedon May 4, 2026
Any interaction with opencode is melting my macbook because of high cpu usage. It can use up to 4 cores 100% to just render the incoming stream. There should be a way to limit updates count or fps or whatever
thevtm commentedon May 10, 2026
I'm experiencing the same issue.
I've tested a few versions.
1.3.17seems to be fine1.14.0issue is present1.14.7issue is present1.14.20issue is present1.14.46issue is present(running on Arch Linux)
james5635 commentedon Jun 8, 2026
I have similar issue. I use
google/gemma-4-26B-A4B-it-qat-q4_0-ggufonllama.cpp. At long thinking, OpenCode freeze and consume roughly 100% CPUs.I also tested on Claude Code with the same model and prompt, but Claude Code works well.
vzwjustin commentedon Jun 16, 2026
Env: OpenCode Flatpak 1.4.0 and newer, CachyOS (also seen on macOS/M3 Max)
Bug: Desktop registers $HOME (sometimes /) as a workspace. The file watcher runs inotify over the whole tree, times out, and retries in a loop → opencode-cli sits at ~100% CPU.
Deleting workspace state doesn't stick — a normal launch recreates it.
Workaround: Wrapper that resets opencode.global.dat to a single project and uses flatpak override --env=HOME=/path/to/project so the watcher only sees that dir. CPU stays low.
phonkd commentedon Jun 24, 2026
i almost returned my mac but found that opencode (wasnt even open) used 300% cpu and slimed my battery
jmencak commentedon Jun 24, 2026
Yeah, feel your pain. I was about to give up on opencode cli until I found this issue. Using 1.3.17 and it does work for me fine. I still get occasionally very high CPU usage, but never once there's no more output expected from the model. That was bothering me the most. I wanted to test if this really fixes it, but didn't manage to get round to it.
viktor-ferenczi commentedon Jun 26, 2026
Related: #34045
Astro-Han commentedon Jul 14, 2026
One concrete data point for the incoming-stream case: on macOS arm64 with OpenCode 1.17.20, toggling TUI animations changed the same active process from 24-43% CPU to 1-13%. Repeating the toggle reproduced the increase and decrease. The model was remote, and the FFF workers were asleep.
The spinner advances every 80ms and requests a render for each frame. OpenTUI then enters
root.render()and walks the render list. I posted the measurements, sample symbols, and source links here: #30086 (comment)This does not explain every report in this thread, especially watcher and long-session cases, but it accounts for the streaming CPU on this setup.
bornmw commentedon Aug 30, 2026
explained here: #6172
thdxr commentedon Oct 11, 2026
Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (
opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊