Chat response delayed over 1 minute in browser, but /global/event receives LLM reply instantly #19514

Activity

1. sundoon

   added

   bugSomething isn't workingSomething isn't working

   on Mar 28, 2026
2. github-actions

   assigned

   Brendonovich

   on Mar 28, 2026
3. github-actions

   added

   webRelates to opencode on web / desktopRelates to opencode on web / desktop

   on Mar 28, 2026
4. sundoon commented on Mar 30, 2026

   

   sundoon

   on Mar 30, 2026

   Author

   More actions

   hello?
5. Svtter commented on Mar 31, 2026

   

   Svtter

   on Mar 31, 2026

   Last edited by Svtter

   More actions

   @sundoon This appears to be related to the broader SSE streaming architecture issue being tracked in #17020 (session-scoped streaming responses for message submission). The root cause seems to be that the current /event endpoint broadcasts all events to all subscribers, requiring heavy client-side filtering — see also #9650 and #5627 for related discussions on session-scoped SSE filtering.
6. Svtter commented on Mar 31, 2026

   

   Svtter

   on Mar 31, 2026

   More actions

   Hi, I did some digging into this and the broader web/SSE situation in OpenCode. Here's what I found:

   Root cause appears to be architectural:

   • The /event SSE endpoint broadcasts all events from all sessions to every subscriber (ACP event subscription architecture causes cross-session pollution and duplicate events #5627). Clients must filter by sessionID on their own, which is expensive and likely the source of the delay you're seeing.
   • The POST /session/:id/message endpoint is synchronous/blocking ([FEATURE]: Support session-scoped streaming responses for message submission #17020), not designed for streaming.
   • A related issue ([Performance] Web UI consumes excessive bandwidth via SSE streaming (~25MB/min) #14114) reports the web UI consumes ~25MB/min of bandwidth via SSE — further evidence of the broadcast problem.

   There are open proposals but no movement:

   • [FEATURE]:Support sessionID Filter for SSE Event Subscription #9650 — add sessionID filter to /event (no maintainer response)
   • [FEATURE]: Support session-scoped streaming responses for message submission #17020 — session-scoped streaming responses (no maintainer response)
   • fix(opencode): add session query param to /event OpenAPI #15028 — add session query param to /event OpenAPI (no maintainer response, PR open)

   Honest assessment: The core team hasn't engaged with any of these web/SSE architecture issues. TUI (terminal) is clearly the priority, and web seems to be in a "works but not a focus" state. I wouldn't expect this to be fixed in the short term.

   That said, OpenCode is still a fantastic project — the TUI experience is excellent, the plugin/SDK system is powerful, and the open-source approach is really commendable. It's worth keeping an eye on as the project matures. :)
7. samiralibabic commented on Apr 9, 2026

   

   samiralibabic

   on Apr 9, 2026

   More actions

   Can confirm a closely related regression here, but with a tighter version split and more backend detail.

   My case:

   • local opencode web on 127.0.0.1:4096
   • macOS
   • browser was Safari during the web repro
   • same model works fine for me via another client, so this does not look like a provider responsiveness problem

   What I observed on the broken version:

   • UI gets stuck around "verifying tool functionality"
   • server logs show tool resolution completes quickly and then the LLM stream starts
   • server logs also show message.part.updated publishing
   • so the backend appears to be receiving/publishing output while the web UI looks stale
   • I also saw an early PTY hiccup (Session not found on /pty/.../connect) followed by a successful PTY recreate/connect, so the later stuck state does not seem to be just "PTY failed and nothing else happened"

   Important version split:

   • works: 1.3.17
   • broken: 1.4.2

   That downgrade fixes the problem immediately for me.

   Because TUI also regressed on the same version for me, I suspect this is broader than a browser-only issue, but this ticket still seems like the best existing match for the web symptom.
8. thdxr

   removed

   bugSomething isn't workingSomething isn't working

   webRelates to opencode on web / desktopRelates to opencode on web / desktop

   on May 3, 2026
9. github-actions commented on Jul 3, 2026

   

   github-actionsBot

   on Jul 3, 2026 – with GitHub Actions

   Contributor

   More actions

   To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
10. github-actions

    closed this as not plannedon Jul 3, 2026