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

[sundoon]

Description

Problem Background
There are two computers on a local area network. I run a service on one computer using the command:
bun run dev serve --hostname 0.0.0.0 --port 4096
On the other computer, I perform the following operations:
Run curl.exe -N http://172.50.84.80:4096/global/event to listen to the global/event endpoint on port 4096 of the other computer.
Access 172.50.84.80:4096 using a web browser.
Problem Phenomenon
After sending a message in the remote chat box, the global/event endpoint receives the response from the LLM almost immediately, but the chat box takes more than a minute to display the reply.

Plugins

No response

OpenCode version

1.3.3

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

all

Terminal

all

[sundoon]

hello?

[Svtter]

@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.

[Svtter]

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. :)

[samiralibabic]

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.