Repository navigation
cli: service becomes unresponsive under multi-session load — single process bottleneck #49095
Description
Description
When running 5+ concurrent sessions, the opencode service becomes severely degraded. A single Node.js process hitting single-core CPU saturation causes:
- Creating new sessions takes excessively long
- Switching between sessions shows the session list loading for an extended period
- Switching models within a session is also extremely slow
- The entire service becomes unresponsive until CPU usage drops
The root cause appears to be that all active sessions share a single Node.js process. When one session's workload (e.g., a long-running LLM response or tool execution) saturates a CPU core, all other sessions — including UI operations like listing sessions or switching models — are starved and become unresponsive.
Steps to reproduce
- Open 5 sessions simultaneously in opencode
- Trigger heavy workloads across multiple sessions (e.g., long-running code generation, tool execution)
- While workloads are running, try to create a new session
- Try to switch between sessions — observe the session list taking a very long time to load
- Try to switch the model in any session
Expected Behavior
- UI operations (session list, model switching, creating new sessions) should remain responsive regardless of background workload
- Heavy computation in one session should not block or degrade other sessions
- Consider using Node.js worker threads to isolate session workloads, so a CPU-bound task in one session does not starve the event loop shared by all sessions
Actual Behavior
- Session list loading takes an abnormally long time under load
- Creating new sessions is extremely slow
- Switching models hangs
- The service becomes effectively unresponsive until the CPU-intensive work completes
Additional Context
- opencode version: 2.0.3
- OS: Windows_NT 10.0.26200 (MINGW64_NT-10.0-26200, win32 x64)
- Terminal: Git Bash (xterm-256color)
- Shell: /usr/bin/bash (MINGW64)
- Install/channel: npm global, latest
- Active plugins: none
Possible improvement: If active sessions could use dedicated worker threads, a CPU-saturated session would only block itself, not the entire service. This would make multi-session usage significantly more resilient.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Sep 15, 2026
This issue might be a duplicate of existing issues. Please check:
Please review those issues and add any new details there if they cover your case, or clarify what distinguishes this report if it is different.
XXLxhPLMM commentedon Sep 15, 2026
Thanks for flagging these. I've reviewed both issues and there are meaningful differences worth clarifying:
How this differs from #43891 and #42567:
Severity spectrum — My experience is not always a full freeze. When only a single core is saturated, the service is still usable but significantly degraded (slow session list loading, slow model switching, slow session creation). It only escalates to a full freeze under heavier load. This is a gradual performance degradation, not just a binary works/doesn't-work scenario.
Multi-client architecture pressure — The bottleneck is amplified when multiple clients (e.g., desktop app + TUI, or multiple TUI instances) connect to the same service process. A single service process handling requests from multiple clients can easily saturate one core on an 8-core CPU (observed ~12.6% CPU = one full core). This multi-client scenario is not covered by tui: background subagent load freezes tab switching and text input #43891 or Client stalls at single-core 100% CPU during long sessions with many rapid tool-calling turns — unrecoverable except via SIGINT #42567.
Client-side impact from expanded UI elements — In addition to server-side slowness, expanding a very long "thinking" output in the client causes the client itself to become unresponsive. This is a client rendering issue separate from the server-side bottleneck, and is not reported in the other two issues.
Criticality — I've already removed opencode v1 to fully migrate to v2. This is not a minor inconvenience — it directly blocks daily workflow. The multi-session + multi-client scenario is a common real-world usage pattern, and the single-process bottleneck makes it unreliable.