High CPU usage in newer versions of OpenCode

Description

Since around 7 days ago, the CPU usage of OpenCode has spiked dramatically. Before, I was able to use over 10 OpenCode sessions at the same time; since the last updates, my PC has problems with 3.
~~The result of this is a heavily slowed-down and laggy mouse cursor reaction time; therefore, you can't properly use OpenCode nor anything else.~~ Unrelated to OpenCode; same behaviour on my end by using CpuStress for finding this out.
I can't say for sure when this error appeared; however, reverting to v1.14.51 fixed it. Also, I noticed that in Task Manager, as I launch it inside VSCode (X in standalone terminal, PowerShell in my case), at v1.15.12 - one of the problematic versions - it shows Bun (which OpenCode uses) as a stand-alone process there, but after I reverted to v1.14.51, it's back again included as a subprocess of VSCode.
Both versions installed using npm X desktop app (at least its new versions) have the same behaviour.

Plugins

Used some plugins --> deactivated them --> no difference

OpenCode version

Problematic: v1.15.12 + few older ones (v1.15.X); without error: v1.14.51

Steps to reproduce

Install a new version of OpenCode (like v1.15.12) - desktop or terminal
1B (opt.). Install VSCode
Launch multiple sessions of OpenCode. The more, the better.
In each session, provide it with a task (for example, some refactoring, researching, analysing, etc.; so it'd use the codebase you use).
See and check the CPU usage of Bun for each one.
Uninstall the new version, install the older one (like v1.14.51), and repeat steps 2-4.
Compare CPU usage between versions.

Screenshot and/or share link

No response

Operating System

Windows 10

Terminal

PowerShell (standalone/in VSCode)

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

Open Code and bun using way more resources #22548: Same symptom of Bun using significantly more CPU/resources on Windows, visible in Task Manager
High CPU usage in IDLE on Linux Kubuntu 25.10 #24393: High CPU usage reported since a specific version on desktop
High CPU use in idle on macOS (Desktop & cli) #26416: High CPU use in idle across Desktop and CLI versions

If your issue is distinct (e.g. specific to the version regression between v1.14.x and v1.15.x or the Bun subprocess vs. standalone process behavior), please note that in a comment so maintainers can differentiate.

This issue might be a duplicate of existing issues. Please check:
* [Open Code and bun using way more resources #22548](https://github.com/anomalyco/opencode/issues/22548): Same symptom of Bun using significantly more CPU/resources on Windows, visible in Task Manager

* [High CPU usage in IDLE on Linux Kubuntu 25.10 #24393](https://github.com/anomalyco/opencode/issues/24393): High CPU usage reported since a specific version on desktop

* [High CPU use in idle on macOS (Desktop & cli) #26416](https://github.com/anomalyco/opencode/issues/26416): High CPU use in idle across Desktop and CLI versions
If your issue is distinct (e.g. specific to the version regression between v1.14.x and v1.15.x or the Bun subprocess vs. standalone process behavior), please note that in a comment so maintainers can differentiate.

#22548 is probably an infinite loop error inside OpenCode; however, from the attached picture, the problem was memory and maybe disk usage, and not CPU. I've seen less than 1.5 GB RAM used per Bun.
#24393 might be a similar or somehow related issue. The same applies for #26416

CPU 174% at my ubuntu, the latest version

+1, cpu 200+% and 10.2G memory on ubuntu 24.04(wsl)

Same here

Are your high-cpu-usage sessions stuck in a weird state after a tool call that potentially modified files and generated large diff?

It might be related to the diff check bug:
#29762

Also having this problem with one console open, using 1.15.13 on Ubuntu 26.04

Are your high-cpu-usage sessions stuck in a weird state after a tool call that potentially modified files and generated large diff?

It might be related to the diff check bug: #29762

From what I can see, at least not in my case (not saying yours isn't a problem).
From what I've noticed, my problem is probably related to glob and grep tool calls that are called incorrectly, either in an unnecessarily big folder or outside the codespace (whether possible without permissions, probably not X can't say). Can't say whether this reason (glob/grep tool calls) causes the high CPU usage, but that's what I noticed when one of my sessions was using CPU significantly more than the others (we're talking about 2-5 times bigger usage on my HW).

Same here. Altho ive only started using it recently, it hogs the cpu so bad other tasks are getting starved hard (even after using renice 19; 2c-Ryzen5):

opencode_monitor_111433.log

Related: #34045

I am using OpenCode (1.17.11) inside WSL and noticed similar high CPU usage. In my case, my host machine's 'vmmem' and 'COM Surrogate' usage hit 100% when OpenCode opened and stayed high. Disabling snapshot with opencode.json and decreasing the WSL CPU core count to 2 reduced the CPU and memory usage, but it didn't completely fix the issue.

I am using OpenCode (1.17.11) inside WSL and noticed similar high CPU usage. In my case, my host machine's 'vmmem' and 'COM Surrogate' usage hit 100% when OpenCode opened and stayed high. Disabling snapshot with opencode.json and decreasing the WSL CPU core count to 2 reduced the CPU and memory usage, but it didn't completely fix the issue.

Can confirm that even on the latest version the high CPU usage problem persists and is not solved.

Also, I noticed that in Task Manager, as I launch it inside VSCode (X in standalone terminal, PowerShell in my case), at v1.15.12 - one of the problematic versions - it shows Bun (which OpenCode uses) as a stand-alone process there, but after I reverted to v1.14.51, it's back again included as a subprocess of VSCode.

Regarding this behaviour, it's doing what it wants, I guess - often all on Bun processes from OpenCode are shown outside of VSCode in Task Manager, sometimes, however, one of them is shown inside of it. Launched through VSCode native terminal through 'opencode' command.
Also, on my end in my case, the average RAM usage is 1GB per Bun/OpenCode session, which is a lot. And the CPU usage is probably even worse - on my AMD Ryzen 5 2400G, each Bun/OpenCode session achieves over 10 % in average for the majority of its 'active' running (aka with running an AI model through API) time, often exceeding 15 % and sometimes over 20 %. I know it heavily depends on what the AI is doing, and also where aka how heavy performance-wise is the folder the user is running OpenCode in, and which tools it uses; it still makes OpenCode not the best choice for multiple sessions at one time and heavily relying on it.

Have switched to Pi and not looked back. It's sad because I really liked opencode :(

I reproduced the animation-specific CPU path on the official 1.18.13 Linux binary.

Controlled same-PID test: empty workspace, --pure, OPENCODE_DISABLE_FFF=1, provider-free !sleep 240, 156×37 terminal.

animations enabled: 28.89% CPU over 30 seconds
animations disabled: 1.40% CPU over 30 seconds
enabled: 203 terminal writes in 10 seconds
disabled: zero terminal writes
main thread: 14.30% enabled vs. 0.30% disabled
seven HeapHelpers: 13.99% combined vs. 0.64%

Official binary SHA-256:
bcebc898d22419417b8dbec0f5e3f00f5b67b5a38c1de37c77c699d0e31fe0dd

The prompt spinner runs every 40 ms and calls requestRender(). OpenTUI then renders from the root, traverses/draws the visible tree, and performs a native full-grid diff even though only the spinner changed. This reproduces without plugins, provider streaming, FFF, or project activity.

Reducing the spinner to 350 ms lowered CPU to 8.39% and terminal writes to 2.7/s, confirming cadence is the controlling variable, but that is only a mitigation. The structural fix appears to require retained/dirty-region rendering plus a native regional-diff path so a spinner update does not redraw the transcript.

Data point for the animation-related portion of this, on the Desktop app (macOS, M1 Pro): emulating prefers-reduced-motion: reduce via DevTools → Rendering dropped total GPU from 61% to 5% and OpenCode Helper CPU from ~37% to ~10% instantly, with the same sessions active. Full before/after screenshots and details here: #31664 (comment)

For desktop users the animation path appears to be the dominant cost — a persistent reduce-motion/disable-animations setting (or honoring OS-level Reduce Motion) would resolve it.

I switched to beta v2 and this is no longer an issue for me

I opened a bug in Opentui regarding this anomalyco/opentui#1339

Meanwhile ctrl+p -> Disable animations fixes it

Disabling animations doesn't work for me, and occasionally the memory spikes to 4GB 😭

Disabling animations doesn't work for me, and occasionally the memory spikes to 4GB 😭

for memory spike, what worked for me in the past is to uninstall and start from 0 (maybe it’s the cache, so clearing the cache should be sufficient?) and turned off snapshot in opencode.json with "snapshots": false, and i’ve been a happy opencode user ever since. last i remember it’s about huge diffs made by openai models with apply patch (especially during a giga refactor) then opencode saves it in the db, which will in turn load it into RAM if the session is opened.

"snapshots": false fixed the issue for me using opencode in a large monorepo 🙏

Confirmed on macOS — v1.18.28 (Apple Silicon)

Same high CPU issue on macOS. The GPU process alone consumes 20-27% CPU at idle.

My findings:

GPU Process: 20-27% CPU continuously, even with no tasks running
Renderer: 23-34% CPU
Node Service: 64% CPU
Total: 113%+ CPU usage while idle

The problem appears to be the GPU process stuck in a rendering loop. All standard Electron GPU disable flags are ignored by the app (--disable-gpu, electron-flags.conf, env vars).

Updating from v1.18.16 to v1.18.28 did not resolve the issue.

Related to #31664 (high iGPU load).

@Raviu56

Decomposition of this issue into four independent causes with different fix paths:

1. TUI animation render path (CLI/TUI, all platforms)

The status-bar spinner (packages/tui/src/component/prompt/index.tsx, interval={40}) fires requestRender() per tick, and opentui's CliRenderer.loop() unconditionally calls root.render(), walking the full scene graph every frame. A one-cell animation therefore drives 25 full-frame renders/sec, with per-frame cost scaling with timeline size — the #42306 strace shows ~15fps writev with the CPU time spent between writes, i.e. per-frame cost exceeding the 40ms budget. Controlled measurements in this thread: @Raviu56 28.89% CPU enabled vs 1.40% disabled, @Astro-Han 24-43% enabled vs 1-5% disabled on a reversible same-PID toggle; 350ms spinner → 8.39%, confirming cadence as the controlling variable. Structural fix (dirty-region rendering) is upstream: anomalyco/opentui#1339. Throttling the spinner interval (400ms when no message.updated/message.part.* event has landed for 1.5s, 100ms while streaming) is being coordinated in #42306.

2. FFF double-watch and index maintenance (macOS/Linux, scales with tree size)

packages/core/src/filesystem/search.ts creates one Fff.create({ basePath, aiMode: true, disableMmapCache: true, disableContentIndexing: true }) per location. fff maintains its own native background watcher and live index (disableWatch defaults to false and is not passed), so every tree is watched twice: fff's internal watcher plus opencode's @parcel/watcher (filesystem/watcher.ts). fff's API has no ignore-glob support, so watcher.ignore config does not apply to its watcher — consistent with @arcv's findings. CPU scales with tree size; OPENCODE_DISABLE_FFF=1 removes the load (@arcv). Windows is unaffected because fff is disabled there by default (flag.ts:34).

Fix options:

a. disableWatch: true + debounced fff.rescan() driven by opencode's own watcher events — single-watch architecture, at the cost of full rescans.
b. disableWatch: true + accept index staleness between rescans (files created after boot missing from search).
c. Defensive guard: enableHomeDirScanning/enableFsRootScanning are off by default in the fff API; passing them explicitly removes the dependency on fff defaults.

3. Snapshot persistence → memory on session load (large monorepos)

Full message snapshots including summary.diffs are persisted per message.updated event and loaded into memory when the session is opened. "snapshots": false disables this persistence and removes the load (@brandon-julio-t, @nhojb). Write-side retention is tracked in #33356; the read path is not covered by the open PRs there — readAfter in packages/core/src/event.ts loads an aggregate with .all(), unpaginated (#32005).

4. Desktop GPU process (Electron)

GPU-process render loop at idle; prefers-reduced-motion drops GPU 61% → 5% (@brandon-julio-t); tracked in #31664.

The 1.18.30 still hasn't fixed the issue, even with the animation disabled.

Disabling animations didn't help in my case. Setting "snapshot": false increased CPU usage from 100% to 200% 🙃

Disabling animations didn't work for me either

update - turns out my issue was a plugin i built that had a bug in it. It was probably amplified by a potential solidjs lifecycle bug in OpenCode. But once i fixed the plugin the issue went away.

The OpenCode bug i found is here:

 // bug - in packages/tui/src/plugin/api.tsx
  <PluginContextProvider value={context}>
    {render()}
  </PluginContextProvider>

  // fix
  <PluginContextProvider value={context}>
    {untrack(render)}
  </PluginContextProvider>

Suppose this is a the plugin's render implementation:

render: () => {
    const status = gitStatus()

    onMount(() => {
      startGitRefreshTimer()
    })

    return <text>{status.branch}</text>
  }

gitStatus() is a Solid signal. Solid saw that signal read while evaluating the Provider’s children, so it recorded this dependency:

  gitStatus changes
        ↓
  run the entire render function again
        ↓
  run lifecycle setup again
        ↓
  create more timers and listeners

That's the bug. The screen needed an update, but OpenCode recreated the plugin component instead.

it was not the main issue in my plugin, but it probably amplified the issue

Closing as a duplicate of #19466, which tracks OpenCode's high CPU usage. Please add your platform, version and a profile there if you can.

Navigation Menu

Repository navigation

High CPU usage in newer versions of OpenCode #30086

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

27 remaining items

Confirmed on macOS — v1.18.28 (Apple Silicon)

My findings:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

High CPU usage in newer versions of OpenCode #30086

Description

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on May 31, 2026

DenisSilent commented on May 31, 2026

shuans commented on Jun 1, 2026

zzzhc commented on Jun 1, 2026

guilhermezaparoli commented on Jun 2, 2026

asaf92 commented on Jun 2, 2026

frankyw commented on Jun 3, 2026

DenisSilent commented on Jun 3, 2026

fidodido48 commented on Jun 11, 2026

ASTL2022 commented on Jun 11, 2026

viktor-ferenczi commented on Jun 26, 2026

arcv commented on Jun 27, 2026

DenisSilent commented on Jun 27, 2026

DenisSilent commented on Jun 27, 2026

27 remaining items

kungfusaini commented on Jul 30, 2026

Raviu56 commented on Aug 4, 2026

brandon-julio-t commented on Aug 6, 2026

benknab commented on Aug 10, 2026

jclaveau commented on Aug 10, 2026

rijieli commented on Aug 21, 2026

brandon-julio-t commented on Aug 21, 2026

nhojb commented on Sep 3, 2026

opp4s commented on Sep 4, 2026

Confirmed on macOS — v1.18.28 (Apple Silicon)

My findings:

ghwinter commented on Sep 8, 2026

rijieli commented on Sep 11, 2026

scana commented on Sep 15, 2026

dkarter commented on Sep 18, 2026

neriousy commented on Oct 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions