Opencode severe performance issues

[alexanderbrueck]

Question

Hey there, I have been using opencode 1.14.20 for around 4 weeks and while I really love working with it, me (and my team, too) constantly run into severe performance issues. Sometimes opencode works totally fine and fast, then it becomes super slow meaning even the response to something like "Hey there" takes 10 minutes if it responds anything at all. This happens even in new sessions and across all the providers we tried incl. the free models. It is impossible to work like this and we are considering moving away from opencode. Does anyone know what could cause this and how to fix it?

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Memory Megathread #20695: Memory Megathread — centralized tracking of performance/memory issues; includes instructions for collecting heap snapshots to help diagnose slow/hanging behavior
• Performance Issue in 1.3.0 #18946: Performance Issue in 1.3.0 — general performance degradation reports
• OpenCode Go Performance is abysmal #17173: OpenCode Go Performance is abysmal — slow responses across providers
• Why is the new version so laggy? v1.3.17 and v1.4.0 #21450: Why is the new version so laggy? — similar reports of slowness across versions

If your issue is related to memory growth causing slowdowns, #20695 has actionable steps (heap snapshots) that the maintainers are actively using to diagnose and fix these problems.

[laluka]

Heya !
Here's my early impact assessment, if someone want to throw this one to a dev agent and see how it can improve our beloved opencode! :)
Cheers! ✌️

---

High CPU usage on long/tool-heavy sessions (web UI)

Summary

The OpenCode web UI causes sustained high CPU usage (~80-100% on the renderer process) when viewing sessions with many tool calls. The browser becomes unresponsive and the machine heats up significantly, even though the page is otherwise idle (not scrolling, not interacting).

Environment

• Browser: Google Chrome (latest stable)
• OS: Linux 6.19.11-1-cachyos (Arch-based)
• Hardware: Laptop, multi-core Intel CPU
• OpenCode version: Latest (web UI at 127.0.0.1:3000)

Steps to Reproduce

1. Start a session with an LLM that uses many tool calls (shell, explore, edit, etc.)
2. Let the session run for a while — roughly 100+ assistant message blocks / tool invocations
3. Open the session in the web UI
4. Observe CPU usage via top or system monitor

Observed Behavior

The Chrome renderer process for the OpenCode tab consumes 80-100% CPU continuously, even when the session is idle or just showing the "Thinking" indicator. The laptop becomes hot and fans spin up.

Root Cause Analysis

Profiling via Chrome DevTools revealed three compounding issues:

1. No DOM virtualization — 9,089 nodes rendered

The entire conversation history is rendered into the DOM at once. A single long session produced:

Container	Direct children	Total descendants
Assistant turn 1	130	3,822
Assistant turn 2	53	1,608

Every tool call block (Shell, Explore, Edit, etc.) adds significant DOM subtrees. None of these are virtualized or removed when scrolled off-screen.

2. 15 infinite CSS animations running simultaneously

Active animations found during profiling:

Animation	Target	Count
session-progress-whip	Thinking spinner (<div>)	1
pulse-opacity	SVG <rect> skeleton placeholders	4
pulse-opacity-dim	SVG <rect> skeleton placeholders	10

These run in infinite loops at varying durations (~1.3–2.0s each). Many of these appear to be on off-screen collapsed tool call blocks that are no longer visible.

3. 9,249 elements have CSS transition/animation properties

Nearly every element in the DOM has blanket CSS transition rules applied. Combined with the 15 active animations, the browser is forced to recalculate styles across ~9K elements on every animation frame — at 60 FPS.

The result: constant style recalculation + layout + paint across a massive DOM tree, every 16ms, indefinitely.

Measured Impact

Metric	Value
Total DOM nodes	9,089
Active CSS animations	15 (infinite loop)
Elements with transition/animation rules	9,249
requestAnimationFrame rate	60 FPS (continuous)
DOM mutations (idle, 2s sample)	27 mutations, 15 text changes
Chrome renderer CPU	~80% sustained
CPU package temp	79-85C (vs ~65C after killing the tab)

Suggested Fixes

High impact

• Virtualize the message list. Only render messages/tool-blocks that are in or near the viewport. Libraries like @tanstack/react-virtual or similar can handle this. This alone would likely cut DOM size by 80%+ on long sessions.
• Pause or remove animations on off-screen elements. Skeleton pulse-opacity animations on collapsed/off-screen tool blocks serve no purpose but still trigger compositing work. Use IntersectionObserver to pause them, or remove the animation entirely once the tool block has loaded.

Medium impact

• Scope CSS transitions. Avoid applying transition: all ... or broad transition rules to every element. Restrict transitions to elements that actually animate on user interaction (buttons, menus, expand/collapse). This prevents the browser from tracking transition-eligible properties on thousands of static elements.

Low impact / workaround

• Paginate or collapse old messages. For very long sessions, consider collapsing older turns into a summary or loading them on demand when the user scrolls up.

[honarewto-a11y]

The findings line up with what I’d expect from long unvirtualized message trees — the 9k+ DOM nodes, global transitions, and always‑running animations explain the sustained CPU load.
If you'd like, I can help test a virtualized message renderer or review changes that scope transitions/animations to visible elements only.

[alexanderbrueck]

@honarewto-a11y no clue what you are talking about ^^

[alexanderbrueck]

@laluka what are you talking about?^^