Nice work on this! The unified SSE endpoint is a solid approach for the connection limit issue, and the code is well-documented.

One area to flag: the SSEFetchClient changes and how they interact with the Conversation streaming use case.

Design consideration: SSEFetchClient now has two modes: simple streaming (Conversation) vs managed connection with heartbeat/reconnect/auto-close (file/resource watching). These use cases have pretty different needs:

The params approach works, but it makes the class fairly modal. It is worth considering whether the connection management logic (heartbeat, auto-close, reconnect) should live in a wrapper instead, keeping SSEFetchClient as a simple streaming primitive. Not a blocker, just thinking about maintainability.

Minor items:

1. close event behavior changed - It previously fired in a finally block (always), but now only fires on AbortError. I checked and the Conversation handler is a no-op, so nothing will break. However, for correct SSE semantics, it is probably good to fire close whenever the stream ends, regardless of how it ends. Moving it back to a finally block would restore that behavior.

2. The backend's event: error is not explicitly handled in setupSSEEventHandlers() - it falls through to default and logs a warning.

Happy to chat through any of this!

Developed in collaboration with Claude Code

@ericpgreen2 Reworked as a wrapper.

@ericpgreen2 Reworked as a wrapper.

Looks good! Let me know when ready for final review.