Skip to content

opencode is using CPU for doing nothing! #19466

New issue
New issue
Closed as not planned
Closed as not planned
opencode is using CPU for doing nothing!#19466
Assignees
rekram1-node

Description

@Jaaaky
Jaaaky
opened on Mar 27, 2026

Description

While opencode is waiting for API limit rate - actually doing nothing -

Resource has been exhausted (e.g. check quota). [retrying in 18m 12s attempt #12]

It's actually using ~50% of single core on i9-14900 CPU

Plugins

nothing

OpenCode version

1.3.3

Steps to reproduce

I was working on a project using gemini api tier 1, quickly exhausted my limit, while waiting I noticed that opencode is using this much CPU on htop.
system performance is fine, I've many applications running including browsers, but only opencode is using this much CPU

$ ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | grep -E 'PID|opencode'
    PID    PPID CMD                         %CPU
  76732   76729 opencode                    47.6
  82693   76732 /usr/bin/opencode run /home  0.3

Screenshot and/or share link

No response

Operating System

archlinux, up-to-date

Terminal

konsole

Activity

  1. Jaaaky
    added
    bugSomething isn't working
    on Mar 27, 2026
  2. github-actions
    assigned
    rekram1-node
    on Mar 27, 2026
  3. github-actions
    added
    perfIndicates a performance issue or need for optimization
    on Mar 27, 2026

  4. github-actions commented on Mar 27, 2026

    @github-actions
    github-actionsBot
    on Mar 27, 2026 – with GitHub Actions
    Contributor

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

    If your issue is distinct (specifically tied to the rate-limit retry waiting loop rather than general idle CPU usage), please clarify in this issue. Otherwise, consider adding your findings to the existing report.

  5. gearwatcher commented on Apr 4, 2026

    @gearwatcher
    gearwatcher
    on Apr 4, 2026

    This is absolutely still an open issue, and post-close comments on #4804 (it tops the Google search so most of your users are actually ending there when searching for CPU issues in opencode) prove it, there's comments up to very recently reporting that the original problem has not been closed. Opencode is hitting four cores at about 60-70% on my M1 MBP Max consistently which is A LOT for streaming blocks of text back and forth.

  6. wjrforcyber commented on Apr 17, 2026

    @wjrforcyber
    wjrforcyber
    on Apr 17, 2026

    Same here, MacBook Apple M4 Pro, Tahoe, 24GB, now keeps heating and can only last for less than 3 hours by doing nothing, opencode is the only process takes high CPU usage (without task execution).

  7. imp4ct7 commented on Apr 25, 2026

    @imp4ct7
    imp4ct7
    on Apr 25, 2026

    Same here on Linux Kubuntu 25.10 on Ryzen R9-5900HS with OpenCode version 1.14.25, it takes 50% of CPU with doing nothing. When model is running it takes almost 100% but model is remote so this is weird. Flatpak version 1.4.0 behaves the same almoast permnent CPU load.

  8. thdxr
    removed
    bugSomething isn't working
    perfIndicates a performance issue or need for optimization
    on May 3, 2026

  9. oliver-joos commented on May 9, 2026

    @oliver-joos
    oliver-joos
    on May 9, 2026

    I see this in OpenCode 1.14.41 on Linux Mint 22.2.

    This issue may have the same cause as #13899, which was automatically closed, but may be solved by PR #13901 that simply limits the frame rate of the web UI.
    If you are experienced with TypeScript, please help to test PR #13901!

  10. ezdiy commented on May 12, 2026

    @ezdiy
    ezdiy
    on May 12, 2026

    Same on arch, terminal wezterm. Everything bleeding edge. Busyloop triggers by simply sending a prompt. It's somewhat sporadic, either it happens or it doesn't. Some models trigger the busyloop bug more than others (eg deepseek flash gets "stuck" busy looping almost always, and then suddenly 2 screen of text appear at once, vs glm which is slow and somehow avoids the busyloop).

    Someone who knows how to use profiler in bun will have to look into this.

    strace shows (mostly) this when busylooping. seems like someone (bun?) is using a spinlock while it shouldn't.

    [pid 84214] <... sched_yield resumed>)  = 0
[pid 84220] sched_yield( <unfinished ...>
[pid 84219] <... sched_yield resumed>)  = 0
[pid 84218] <... sched_yield resumed>)  = 0
[pid 84217] futex(0x7fad100f8150, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 172812, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
[pid 84216] futex(0x7fad100f8150, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 84215] sched_yield( <unfinished ...>
[pid 84214] sched_yield( <unfinished ...>
[pid 84220] <... sched_yield resumed>)  = 0
[pid 84219] sched_yield( <unfinished ...>
[pid 84218] sched_yield( <unfinished ...>
[pid 84217] <... futex resumed>)        = -1 EAGAIN (Resource temporarily unavailable)
[pid 84216] <... futex resumed>)        = 0
[pid 84215] <... sched_yield resumed>)  = 0
[pid 84214] <... sched_yield resumed>)  = 0
[pid 84220] sched_yield( <unfinished ...>
[pid 84219] <... sched_yield resumed>)  = 0
[pid 84218] <... sched_yield resumed>)  = 0
[pid 84217] futex(0x7fad100f8108, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 84216] futex(0x7fad100f0150, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 172914, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
[pid 84215] futex(0x7fad100f0150, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 84214] sched_yield( <unfinished ...>
[pid 84220] <... sched_yield resumed>)  = 0
[pid 84219] sched_yield( <unfinished ...>
[pid 84218] sched_yield( <unfinished ...>
[pid 84217] <... futex resumed>)        = 0
[pid 84216] <... futex resumed>)        = -1 EAGAIN (Resource temporarily unavailable)
[pid 84215] <... futex resumed>)        = 0
[pid 84214] <... sched_yield resumed>)  = 0
[pid 84220] sched_yield( <unfinished ...>
[pid 84219] <... sched_yield resumed>)  = 0
[pid 84218] <... sched_yield resumed>)  = 0
[pid 84217] sched_yield( <unfinished ...>
[pid 84216] futex(0x7fad100f0108, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 84215] futex(0x7fad100e0154, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 176989, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>
[pid 84214] futex(0x7fad100e0154, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 84220] <... sched_yield resumed>)  = 0
[pid 84219] sched_yield( <unfinished ...>
[pid 84218] sched_yield( <unfinished ...>
[pid 84217] <... sched_yield resumed>)  = 0
[pid 84216] <... futex resumed>)        = 0
[pid 84215] <... futex resumed>)        = -1 EAGAIN (Resource temporarily unavailable)
[pid 84214] <... futex resumed>)        = 0
[pid 84220] sched_yield( <unfinished ...>
[pid 84219] <... sched_yield resumed>)  = 0
[pid 84218] <... sched_yield resumed>)  = 0
[pid 84217] sched_yield( <unfinished ...>
[pid 84216] sched_yield( <unfinished ...>
[pid 84215] futex(0x7fad100e0108, FUTEX_WAKE_PRIVATE, 1 <unfinished ...>
[pid 84214] futex(0x7fad100d4154, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 177485, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...>

  11. Retamogordo commented on May 30, 2026

    @Retamogordo
    Retamogordo
    on May 30, 2026

    Same on Ubuntu 22.04, opencode version 1.15.12.

  12. life00 commented on Jun 17, 2026

    @life00
    life00
    on Jun 17, 2026

    Same here on Fedora 42, opencode version 1.17.7

  13. gdevenyi commented on Jun 17, 2026

    @gdevenyi
    gdevenyi
    on Jun 17, 2026

    I'm seeing this right now for
    Usage limit reached for 5 hour. Your limit will reset at 2026-06-18 03:02:54 [retrying in 7m 41s attempt #9]

    Huge cpu usage spinning away waiting. Is it the animation?

  14. viktor-ferenczi commented on Jun 26, 2026

    @viktor-ferenczi
    viktor-ferenczi
    on Jun 26, 2026

    I'm seeing this right now for Usage limit reached for 5 hour. Your limit will reset at 2026-06-18 03:02:54 [retrying in 7m 41s attempt #9]

    Huge cpu usage spinning away waiting. Is it the animation?

    Yes, it is: #34045

  15. skhaz commented on Jun 29, 2026

    @skhaz
    skhaz
    on Jun 29, 2026

    I also have this issue, even with simple sessions

  16. igallart commented on Jul 6, 2026

    @igallart
    igallart
    on Jul 6, 2026

    Same problem, high cpu doing nothing.

    opencode -v
    1.17.13

    cat /etc/os-release
    PRETTY_NAME="Ubuntu 26.04 LTS"
    NAME="Ubuntu"
    VERSION_ID="26.04"
    VERSION="26.04 LTS (Resolute Raccoon)"
    VERSION_CODENAME=resolute
    ID=ubuntu
    ID_LIKE=debian
    HOME_URL="https://www.ubuntu.com/"
    SUPPORT_URL="https://help.ubuntu.com/"
    BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
    PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
    UBUNTU_CODENAME=resolute
    LOGO=ubuntu-logo

    uname -a
    Linux namek 7.0.0-27-generic #27-Ubuntu SMP PREEMPT_DYNAMIC Thu Jun 18 19:13:49 UTC 2026 x86_64 GNU/Linux

  17. jmarcosfer commented on Jul 7, 2026

    @jmarcosfer
    jmarcosfer
    on Jul 7, 2026

    Same here,

    opencode -v
    1.17.14

    macOS 15.7.7
    MacBookPro15,1
    2,2 GHz 6 core i7
    16GB RAM

  18. DavidGOrtega commented on Jul 11, 2026

    @DavidGOrtega
    DavidGOrtega
    on Jul 11, 2026

    Same heree every instance eats a full core beyond 100% over time

  19. dkamins commented on Jul 22, 2026

    @dkamins
    dkamins
    on Jul 22, 2026

    This is a very real issue! There is a (closed/abandoned) feature request to limit the TUI FPS here, where I just engaged:
    #13817

    Here is a blurb I posted there, with the actual script in the comment on that issue in the link below.

    Unsupported workaround: Binary patch OpenCode TUI to throttle FPS

    (targets binary in official Docker image ghcr.io/anomalyco/opencode)

    While native FPS configuration is being considered...
    I developed a binary-patch workaround that makes a copy of the opencode binary with both targetFps and maxFps set as specified. You can easily make separate binaries for different uses, e.g. opencode-fps-30, opencode-fps-10, opencode-fps-1, etc.

    At some point in the future when OpenCode changes the relevant code, this patch will no longer work (but it should fail gracefully as opposed to created a corrupt binary).

    This patch is provided for experimentation, with no warranties. Review the script before running it.

    See patch posted in comment:
    #13817 (comment)

  20. ShreyashKore commented on Sep 1, 2026

    @ShreyashKore
    ShreyashKore
    on Sep 1, 2026

    My Macbook becomes crazy hot even when kept idle. Even when opencode is not open in any window an opencode process keep running which has to be force closed.

  21. jm57c commented on Sep 5, 2026

    @jm57c
    jm57c
    on Sep 5, 2026

    Same here. Can confirm this is still happening on 1.18.29.

    OS: Artix Linux x86_64 (KDE Wayland)
    CPU: i7-10610U
    Process: opencode TUI (cwd=$HOME)

    Sits at ~100%+ CPU on a single core doing completely nothing.

    % time seconds usecs/call calls errors syscall
    57.06 9.859336 188 52375 2515 futex
    25.93 4.480677 16473 272 epoll_pwait2
    13.36 2.307910 40 57374 sched_yield
    3.30 0.569416 43801 13 4 restart_syscall

    Tried disabling fff with OPENCODE_DISABLE_FFF=1 (verified in env) and it made zero difference. $HOME isn't a git repo either so it's not the git status polling issue (#21699). No child processes running, 41 FDs open, just sitting idle on an established connection.

    Looks like a tight busy-wait loop in the event bus / SDK layer. epoll_pwait2 immediately returns ready and spins sched_yield ~7k times/sec instead of actually sleeping. Bun's GC (HeapHelper) constantly sits at ~40% combined CPU just trying to keep up with the allocations from whatever loop is running.

  22. neriousy
    marked High CPU use in idle on macOS (Desktop & cli) #26416 as a duplicate of this issue on Oct 1, 2026
  23. neriousy
    marked High CPU usage in newer versions of OpenCode #30086 as a duplicate of this issue on Oct 1, 2026
  24. neriousy
    marked opencode utilization at 99-100% randomly - opencode unresponsive #33399 as a duplicate of this issue on Oct 1, 2026

  25. keyle commented on Oct 2, 2026

    @keyle
    keyle
    on Oct 2, 2026

    This is definitely an issue if I'm using opencode TUI as a client

  26. mrvigneshvt commented on Oct 5, 2026

    @mrvigneshvt
    mrvigneshvt
    on Oct 5, 2026

    Something to add to this thread — the failure mode I'm hitting doesn't match most of the reports here. The process doesn't just spin until I force-quit it; it terminates itself.

    Sequence:

    1. Runs normally for a while.
    2. CPU suddenly pins a core at ~100% — the whole laptop stalls at this point, not just OpenCode.
    3. While still spiking, OpenCode kills itself. No manual kill needed.

    Digging through the source, there are at least two paths that would produce a self-termination under load:

    Neither of those seems to be called out in this thread yet, which is why I'm adding it here instead of opening a new issue.

    Happy to supply logs, exact version, platform, and a dmesg | grep -i "killed process" OOM check if that helps narrow down which path it is.

  27. mrvigneshvt commented on Oct 5, 2026

    @mrvigneshvt
    mrvigneshvt
    on Oct 5, 2026

    Correction to my comment above: I'm on v2 (@opencode/cli, managed serve --service), not 1.18.x — I should have checked before posting.

    So the self-termination detail belongs with the v2 trackers, and I've added it to #51852 (the v2 Linux idle-spin / liveness-kill report). Leaving this comment here since the exit-on-escaped-error path in index.ts and the watchdog cross-refs are shared between trees, but the v2 thread is where my case actually lives.

    Possibly useful for anyone else landing here on v2: the follow-up in #50591 describes a trigger worth checking — a stray .git above the working directory makes OpenCode treat a very large tree as the project and re-scan it (~26s per pass, twice per message). That exceeds the watchdog window, so the service looks dead and gets replaced.

  28. thdxr commented on Oct 11, 2026

    @thdxr
    thdxr
    on Oct 11, 2026
    Member

    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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

  29. thdxr
    closed this as not plannedon Oct 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions