Environment
- opencode
1.18.18 (npm latest)
- Linux x86_64, run in a terminal (
/dev/pts/*)
Observed (confirmed via strace + per-thread /proc sampling)
- The TUI main thread holds ~1 full core (~94-100%) even when the user is not interacting.
strace shows the main thread repeatedly calling writev(1, ...) writing a ~106-byte spinner frame (~15 fps) to the tty, e.g. \x1b[?2026h\x1b[?25l\x1b[60;4H\x1b[38;2;42;67;101m ... \u2b1d\u2b1d\u2b1d ....
- In the same window there are no network / disk / log syscalls — the CPU time is spent between the writes.
- Behavior varies by process: in some instances the burn is entirely on the main thread (HeapHelper threads idle), in others HeapHelper threads also show elevated GC activity.
Why this looks like a bug
- Writing a 106-byte frame 15x/s should cost <1% CPU. The ~100% burn is in the rendering/layout work before each
writev, and the spinner appears to keep animating even with no visible active turn, so the render loop never idles.
Not yet determined (needs a perf profile)
- Whether the spinner is "stuck" because a background task (e.g. title generation or a hung turn) never completes, vs. the render loop simply not being throttled. We did not capture a perf profile, so the exact hot function is unconfirmed. Filing this as a bug report rather than a definitive root cause.
Impact
- Each such session burns ~1 core and makes the terminal feel frozen/hung. We killed several
opencode -c processes assuming a deadlock before tracing the actual CPU usage.
Notes
app_toggle_animations keybind defaults to none, and there is no persistent config option to disable animations.
- npm latest is
1.18.18, so there is no newer version to try as a workaround.
Happy to provide full strace output or a perf profile if that helps narrow it down.
Environment
1.18.18(npm latest)/dev/pts/*)Observed (confirmed via strace + per-thread /proc sampling)
straceshows the main thread repeatedly callingwritev(1, ...)writing a ~106-byte spinner frame (~15 fps) to the tty, e.g.\x1b[?2026h\x1b[?25l\x1b[60;4H\x1b[38;2;42;67;101m ... \u2b1d\u2b1d\u2b1d ....Why this looks like a bug
writev, and the spinner appears to keep animating even with no visible active turn, so the render loop never idles.Not yet determined (needs a perf profile)
Impact
opencode -cprocesses assuming a deadlock before tracing the actual CPU usage.Notes
app_toggle_animationskeybind defaults tonone, and there is no persistent config option to disable animations.1.18.18, so there is no newer version to try as a workaround.Happy to provide full strace output or a perf profile if that helps narrow it down.