opencode process consumes 185% avg CPU / 500MB+ RAM constantly

[ASTL2022]

Description

Environment

• macOS 27.0 (Apple Silicon)
• opencode 1.17.3
• model: deepseek/deepseek-v4-pro (custom provider)
• node: [fill with node -v]

Description

opencode keeps consuming high CPU even when idle (no active conversation).

10-min Monitoring (5s interval, 119 samples)

	CPU %	RAM
AVG	185.9	543MB
MAX	490.0	931MB
>50%	101/119 (85%)

11:14:33   175.4   1023MB
11:14:43   231.2    921MB
11:14:53   237.2    903MB
11:15:13   350.6    890MB
11:15:23   442.6    898MB
11:16:19   386.8    562MB
11:17:04   331.2    420MB
11:18:45   297.2    446MB
11:19:55   490.0    495MB
11:20:25   388.0    452MB
11:21:01   423.9    470MB
11:22:01   390.6    466MB
11:23:26   407.9    509MB
11:24:32   266.0    579MB

Steps

1. opencode with DeepSeek provider
2. No active conversation, just sit idle
3. ps -p $(pgrep opencode) -o %cpu=,rss= every 5s

Expected

Idle CPU < 5%, RAM < 200MB

Actual

Idle CPU 150–490%, RAM 400–1000MB

Config

{
  "model": "deepseek/deepseek-v4-pro",
  "provider": {
    "deepseek": {
      "id": "deepseek",
      "api": "https://api.deepseek.com",
      "options": {
        "apiKey": "<redacted>",
        "baseURL": "https://api.deepseek.com"
      },
      "models": {
        "deepseek-v4-pro": { "id": "deepseek-v4-pro", "name": "DeepSeek V4 Pro" },
        "deepseek-v4-flash": { "id": "deepseek-v4-flash", "name": "DeepSeek V4 Flash" }
      }
    }
  }
}

opencode_monitor_111433.log

Plugins

Skills only

OpenCode version

1.17.3

Steps to reproduce

1. Start opencode
2. Run normal coding tasks (multi-turn conversation with file edits/bash execution)
3. Monitor CPU/memory with ps -p $(pgrep opencode) -o %cpu=,rss= every few seconds
4. Compare to previous version / previous experience — CPU is ~2x higher, with noticeable overheating

Screenshot and/or share link

opencode_monitor_111433.log

Operating System

macos27.0

Terminal

Apple Terminal (480)

[github-actions]

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

• High CPU usage in newer versions of OpenCode #30086: High CPU usage in newer OpenCode versions — same symptom (elevated CPU after recent updates)
• Memory Megathread #20695: Memory Megathread — covers high RAM / memory issues; maintainers are actively collecting heap snapshots there

If your issue is specifically about memory growth, please follow the instructions in #20695 (heap snapshot upload) to help the team diagnose it.

[thaoula]

Corroborating report on the latest version (v1.17.13). Same symptom — high CPU while idle (no active conversation) — with thread-level data that may help narrow it down.

Environment

• macOS 26.4.1 (build 25E253), Apple Silicon
• 16 cores / 128 GB RAM
• opencode v1.17.13 (latest release)
• Two opencode processes running against a large TS monorepo (cwd = repo root)

Measurements (idle, no active prompt)

Two processes, both top-2 CPU consumers on the whole machine (above WindowServer):

PID	invocation	%CPU	RSS	accumulated CPU time
15573	opencode (TUI)	~200%	~1.86 GB	80+ min
77486	opencode -s ses_… (serve)	~100%	~1.10 GB	177+ min

5 samples at 3s intervals — the load is sustained, not a spike, and RSS is flat (this is a CPU busy-loop, not a memory leak):

15:22:53  77486  100.2%  1100112KB    15573  198.0%  1855968KB
15:22:56  77486   99.5%  1100112KB    15573  200.4%  1855968KB
15:22:59  77486  100.1%  1100960KB    15573  198.9%  1855968KB
15:23:02  77486   98.8%  1100112KB    15573  200.1%  1855968KB
15:23:05  77486   99.4%  1100112KB    15573  197.8%  1855968KB

Per-thread breakdown (ps -M 15573)

One thread is pinned at exactly 100.0% in state R (runnable/spinning) with ~31 min of UTIME on that single thread. A handful of others show elevated cumulative UTIME (~1:27 each); the rest are idle:

%CPU STAT     STIME     UTIME
100.0 R     2:36.53  31:16.74   <-- hot spinning thread
  0.0 S     0:06.12   1:27.09
  0.0 S     0:06.05   1:27.06
  0.0 S     0:06.48   1:24.11
  0.0 S     0:04.03   1:32.69
  ... (remaining threads idle)

Thread names (from sample)

The process has ~57 threads. Named worker pools present: Bun Pool 0..7, Heap Helper Thread x3, JavaScriptCore libpas scavenger, an HTTP Client, and notably fff-bg-0..3 (background file-finder / watcher workers). Given the spinning thread + a large monorepo as cwd, a file-watch / indexing busy-loop seems a plausible culprit.

Sample stack (main thread)

The binary ships stripped (symbols show as ???), so the deep frames aren't resolvable, but the main thread is parked in kevent64 as expected — the CPU is being burned on the separate R thread above:

Call graph:
    Thread   DispatchQueue_1: com.apple.main-thread (serial)
      start (in dyld)
        ??? (in opencode) +0x9bdd0c
          ... +0x9be670 / +0x9c7138 / +0x3c14e0 / +0x117f3d0 / +0xe735ec / +0xe78b2c / +0x599a98
            kevent64 (in libsystem_kernel.dylib)

Happy to run a targeted trace (e.g. sample on the specific R thread TID, fs_usage, or dtruss for the busy loop's syscalls) if a maintainer can point me at what would be most useful. If a debug/unstripped build is available I can get resolved frames for the hot thread.

[thaoula]

Hey Team / @thdxr,

Is there anything we can do to provide more information to help track this issue?

OpenCode is frequently smashing the CPU and I have to close it when not in use.

Regards,
Tarek

[arichyx]

Additional reproduction on opencode 1.18.3. This was a transient stuck state: restarting opencode immediately returned CPU usage to normal, and it has not reproduced yet.

Environment

• macOS 26.5.1, Apple Silicon
• opencode 1.18.3 TUI
• Started at a repository root with roughly 6.5k files
• All LSPs were disabled
• MCP child processes were idle at 0% CPU

Observed behavior

• The opencode process remained at approximately 99–100% CPU after the active work had ended.
• Repeated top samples showed 77.5% and then 100.2% two seconds apart; ps also reported about 99%.
• A five-second /usr/bin/sample capture reported a 6.6 GB physical footprint. ps reported roughly 1.18 GB RSS. The process had 33 threads.
• The main thread was parked in kevent64 for essentially the entire sample. The HTTP client, Bun pools, heap helper threads, FFF background threads, and file-watcher threads were also waiting/sleeping.
• One separate thread named Worker remained inside JIT/unknown code for all 3772/3772 samples, consistent with a single-thread busy loop. The release binary is stripped, so the JavaScript frames could not be resolved.

Abridged hot-thread stack from the 1.18.3 binary:

Thread: Worker
  opencode +0x129c4f4
  opencode +0x3c14e0
  opencode +0x1893eac
  opencode +0xe78918
  opencode +0x1402c44
  opencode +0xe7876c
  opencode +0x4840b8
  opencode +0x11e0e4
  opencode +0x2d499a0
  opencode +0x2c5e4b0
  opencode +0x2c5e600
  opencode +0x2ad50b8
  opencode +0x2ad6c0c
  opencode +0x2ad95a0
  opencode +0x32642b8
  JIT / unknown binary (busy for the full sample)

Preceding session state

The log showed a long agent run reaching 56 steps and exiting normally. Two later requests logged:

error=Aborted stack=undefined

A subsequent run also exited normally, but the process was still pinned near 100% CPU a couple of minutes later. Restarting opencode cleared both the high CPU condition and the inflated memory footprint.

There is no deterministic reproduction yet. The evidence appears consistent with a Worker lifecycle/cleanup issue after a long session and aborted requests, but that is only a hypothesis; the native FFF threads themselves were asleep during this sample.

Local paths, project name, provider/model information, process/session/run/message IDs, and timestamps have been omitted. A full sample capture was retained and can be sanitized further if maintainers need it.