Repository navigation
tui: animated session tabs cause high CPU/GPU use and slow other apps #57462
Description
Description
On an Intel HD 520 laptop, OpenCode's TUI animations cause sustained CLI,
terminal and compositor CPU/GPU activity. Other apps take longer to open beside
the visible TUI. Disabling OpenCode animations reproducibly removes most of the
penalty. It happens in Foot too, but is much worse in Ghostty.
An idle selected session is also affected when another session is working and
the tab strip is visible. With that same idle session selected, setting
tabs.mode: "off" removes the penalty even with animations enabled. This
implicates animated tab/status rendering, but the exact implementation is not
isolated. The all-sessions-idle case has not been tested.
Median launch-to-window-map latency beside the same working OpenCode session
(two launches per cell, forward/reverse order):
| App | Foot animations on/off | Ghostty animations on/off |
|---|---|---|
| Flea | 1.13 / 0.66 s | 2.29 / 0.77 s |
| Firefox | 2.38 / 1.60 s | 5.19 / 1.76 s |
| Chromium | 1.80 / 1.20 s | 4.07 / 1.32 s |
In those tests, Ghostty itself used 72–79% of one CPU core and 52–53% GPU
render-engine time with animations on, versus 1.5–1.75% CPU and ~2.5% GPU with
animations off. The OpenCode CLI used 69–78% versus 2–2.5% CPU. Foot's CLI also
used ~63–64% CPU with animations on. These are short samples, not whole-device
GPU measurements.
Ten-second CLI CPU profiles captured with SIGPROF show the animation-on profile
dominated by rendering work: render, addToHitGrid, bufferDrawBox,
bufferDrawTextBufferView, and bufferFillRect. Profiles are available on request.
Expected: small status animations should not continuously redraw enough of the
UI to materially slow other desktop apps, especially while viewing an idle tab.
Plugins
No third-party plugins found; built-in plugins only.
OpenCode version
2.0.32, latest release channel installed through mise/npm; shared background service.
Steps to reproduce
- Open a TUI session with its tab strip visible and start agent work. Our test
used a long existing conversation, not a minimal new transcript. - While it is working, compare these client overrides on the same session:
OPENCODE_CLI_CONFIG_CONTENT='{"animations":true}' opencode --session <id>
versusOPENCODE_CLI_CONFIG_CONTENT='{"animations":false}' opencode --session <id>. - Keep the TUI visible and measure CLI/terminal CPU usage; open another app on
the same workspace. Repeat in Ghostty and Foot. - Select an older idle session while the other session continues working.
Compare animations enabled with tabs visible against
{"animations":true,"tabs":{"mode":"off"}}.
Persistent workaround: "animations": false in ~/.config/opencode/cli.json.
Disabling Hyprland animations or switching scrolling to dwindle did not help.
Ordinary idle terminal windows did not reproduce the large slowdown.
Screenshot
None; measurements and paired CPU profiles were collected instead.
Operating System
Omarchy/Arch Linux x86_64, kernel 7.2.8-9-omarchy, Hyprland 0.56.2 Wayland,
Intel HD Graphics 520/i915, Mesa 26.2.5, 1920×1080 at 1.25 scale, ~8 GB RAM.
Custom Phantomat overview plugin loaded but inactive; not isolated by unloading.
Noticed after a system update, but update causation is not established.
Terminal
Ghostty 1.3.1+omarchy.3 and Foot 1.28.0. Bash; truecolor. Agent subprocess
environment reported TERM=xterm-256color and TERM_PROGRAM=ghostty.
Foot logged an unsupported OSC-66 s parameter warning, so protocol fidelity
is not identical. No Alacritty/Kitty comparison performed.
Activity
opencode-agent commentedon Oct 20, 2026
Thanks for the detailed measurements. I could reproduce this in kind on 2.0.32 and on the latest release, 2.1.1. The sandbox can't measure terminal or GPU load, so I measured only the OpenCode process.
What I did: I opened a session with the tab strip on and a long transcript, then held a turn open for 25 s with a simulated model and sampled the TUI process's CPU and terminal output:
The absolute numbers are much lower than yours because the sandbox has a fast CPU and no real terminal or GPU. The pattern matches what you describe, though: while a session is busy, the animations keep the whole UI re-rendering and writing frames to the terminal, which your terminal then has to redraw. The screenshot below shows the busy tab spinner during the measurement, and the script below reproduces it.
I couldn't run the current
devbranch from source here, so this was checked against the 2.1.1 release. I also didn't test your idle-selected-tab case. Until this is looked at,"animations": falseincli.jsonremains the workaround. Related: #39681 (an earlier tab pulse frame-rate fix) and #42306.Reproduction script (drive.ts)
Run it with opencode-drive:
opencode-drive run ./drive.ts. It drivesopencodefrom yourPATH; setOC_DEVto the path of an OpenCode checkout to run that from source instead.opencode-agent commentedon Oct 20, 2026
User opencode-agent[bot] does not have write permissions
github run