Repository navigation
TUI lag with multi-subagent sessions (97% CPU on render thread) #42657
Description
Description
When running sessions with 2-4 concurrent subagents, the TUI becomes unresponsive: typing has 1-3 second delay, spinner animation stutters/freezes. Tested across Warp, Windows Terminal, and WezTerm — same lag in all three.
Profiled during 4 concurrent subagents:
- opencode process: 2,029 MB RAM, 97% CPU realtime, 42 threads
- RAM grows from ~300 MB to 2+ GB within 20 minutes
The render loop appears to re-render on every state change from every subagent stream, saturating a full CPU core.
Already ruled out: terminal emulator (3 tested), Chrome memory pressure, orphaned node processes, 61 MB log file, power plan (High Performance), PowerShell version.
Setup: Windows 11 Boot Camp (MacBook Pro 16,1, i9-9980HK, 64 GB RAM), 15+ agents configured (orchestrator + SDD workflow), 3 MCP servers. Node v22.22.2.
Suggestion: throttle render frequency (max 30 FPS) or batch state updates when multiple subagents are active.
Plugins
opencode-subagent-statusline, opencode-sdd-engram-manage, custom TUI logo plugin
OpenCode version
1.18.18
Steps to reproduce
- Configure an orchestrator agent with 15+ subagent definitions
- Connect 3 MCP servers (codegraph, context7, engram)
- Enable TUI plugins (subagent-statusline, sdd-engram-manage)
- Start a session and trigger a task that launches 2-4 subagents concurrently
- Try typing while subagents are running — input is delayed 1-3 seconds
Screenshot and/or share link
No response
Operating System
No response
Terminal
No response
Activity
github-actions commentedon Aug 14, 2026
This issue might be a duplicate of existing issues. Please check:
BenjaMolina commentedon Aug 14, 2026
This appears to be the same root cause as #42306.
That report confirms the render loop never idles even with no active output.
My report adds Windows/Boot Camp reproduction and multi-subagent load data (97% CPU, 2 GB RAM growth in 20 min).
masterlifting commentedon Aug 20, 2026
I can independently reproduce a closely matching issue on Windows with OpenCode 1.18.19.
When multiple OpenCode instances have active agent/subagent work, the entire system becomes sluggish, including delayed typing in the TUI. With 3-4 OpenCode processes active, total CPU usage reached 87-100%; each OpenCode process used roughly 0.9-1.2 GB working set memory.
After restarting and leaving one OpenCode process, the same controlled tool-loop tests stayed responsive:
deepseek/deepseek-v4-flashandopenai/gpt-5.6-terra, so the symptom does not appear to depend on one model provider.Update: further A/B testing points to Zed’s integrated terminal on Windows as the primary cause. OpenCode remains responsive with the same workloads in Windows Terminal and VS Code, while system lag starts when Zed is launched even separately. Multiple OpenCode instances appear to amplify the symptom, but are not the root cause in my case.
freaksdotcom commentedon Aug 27, 2026
I reproduced the same symptom on Linux with OpenCode 1.18.23 under tmux. After about seven hours with concurrent subagent activity, the TUI process used 2.67 GiB RSS and about 84% CPU. Seven
HeapHelperthreads each consumed roughly 6.8% CPU, in addition to the main thread and a worker.A paired heap capture found 10.9 million nodes in the TUI heap versus 2.4 million in the server heap. The TUI retained 3.2 million closures and 3.3 million arrays. One minified closure named
sJaccounted for 969,251 live instances. Its incoming references include reactive-looking objects and fields associated with message and part state, includingmetadata,output,state,text, andsessionID. The server snapshot did not contain the same closure population.Restarting the TUI reduced RSS to about 846 MiB and stopped the sustained garbage-collection load. The resumed session contained 11,199 persisted events and about 113 MiB of serialized event payload, so its post-restart baseline remained higher than a new session would be.
I prepared the raw paired snapshots for the upload flow in #20695. The evidence is consistent with TUI state retained across high-volume session and part updates; it does not establish that the spinner alone is the heap owner.
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 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊