Repository navigation
opencode process consumes 185% avg CPU / 500MB+ RAM constantly #31831
Description
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
opencodewith DeepSeek provider- No active conversation, just sit idle
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" }
}
}
}
}Plugins
Skills only
OpenCode version
1.17.3
Steps to reproduce
- Start
opencode - Run normal coding tasks (multi-turn conversation with file edits/bash execution)
- Monitor CPU/memory with
ps -p $(pgrep opencode) -o %cpu=,rss=every few seconds - Compare to previous version / previous experience — CPU is ~2x higher, with noticeable overheating
Screenshot and/or share link
Operating System
macos27.0
Terminal
Apple Terminal (480)
Reacted by Cyantix, Zane, José Guerreiro and Matteo Ricupero
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Jun 11, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is specifically about memory growth, please follow the instructions in #20695 (heap snapshot upload) to help the team diagnose it.
thaoula commentedon Jul 3, 2026
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
Measurements (idle, no active prompt)
Two processes, both top-2 CPU consumers on the whole machine (above WindowServer):
opencode(TUI)opencode -s ses_…(serve)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):
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:Thread names (from
sample)The process has ~57 threads. Named worker pools present:
Bun Pool 0..7,Heap Helper Threadx3,JavaScriptCore libpas scavenger, anHTTP Client, and notablyfff-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 inkevent64as expected — the CPU is being burned on the separateRthread above:Happy to run a targeted trace (e.g.
sampleon the specificRthread TID,fs_usage, ordtrussfor 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 commentedon Jul 6, 2026
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 commentedon Jul 18, 2026
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
Observed behavior
topsamples showed 77.5% and then 100.2% two seconds apart;psalso reported about 99%./usr/bin/samplecapture reported a 6.6 GB physical footprint.psreported roughly 1.18 GB RSS. The process had 33 threads.kevent64for essentially the entire sample. The HTTP client, Bun pools, heap helper threads, FFF background threads, and file-watcher threads were also waiting/sleeping.Workerremained 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:
Preceding session state
The log showed a long agent run reaching 56 steps and exiting normally. Two later requests logged:
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
samplecapture was retained and can be sanitized further if maintainers need it.fix(shell): throttle streaming output metadata updates to cut CPU
fix(shell): throttle streaming output metadata updates to cut CPU
fix(tui): reduce per-frame allocation and re-parse while streaming
github-actions commentedon Sep 18, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.