Skip to content

Opencode severe performance issues #24771

Closed as not planned
Closed as not planned
Opencode severe performance issues#24771
Assignees
thdxr

Description

@alexanderbrueck
alexanderbrueck
opened on Apr 28, 2026

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?

Activity

  1. github-actions
    assigned
    thdxr
    on Apr 28, 2026
  2. github-actions
    added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    perfIndicates a performance issue or need for optimization
    on Apr 28, 2026

  3. github-actions commented on Apr 28, 2026

    @github-actions
    github-actionsBot
    on Apr 28, 2026 – with GitHub Actions
    Contributor

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

    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.

  4. thdxr
    removed
    perfIndicates a performance issue or need for optimization
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026

  5. laluka commented on May 10, 2026

    @laluka
    laluka
    on May 10, 2026

    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.

  6. honarewto-a11y commented on May 13, 2026

    @honarewto-a11y
    honarewto-a11y
    on May 13, 2026

    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.

  7. alexanderbrueck commented on May 18, 2026

    @alexanderbrueck
    alexanderbrueck
    on May 18, 2026
    Author

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

  8. alexanderbrueck commented on May 18, 2026

    @alexanderbrueck
    alexanderbrueck
    on May 18, 2026
    Author

    @laluka what are you talking about?^^

  9. rekram1-node commented on Jun 23, 2026

    @rekram1-node
    rekram1-node
    on Jun 23, 2026
    Contributor

    Automated: closing question issues.

    GitHub Issues are for bug reports and feature requests only — questions / support are no longer tracked here.

    If this is a bug or feature request, please open a new issue with the appropriate template.

  10. rekram1-node
    closed this as not plannedon Jun 23, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions