In this article
Transport reconnection, request replay and resuming an existing generation are different operations. SSE alone does not establish resume support.
A stream disappears, the client reconnects and text appears again. This can look like restoration of the original generation, but mechanisms differ: repeating a request, starting another generation or replaying stored events. Without an explicit contract, the application cannot tell which work occurred or what content was already delivered. Providers should separate these actions rather than promise resume merely because they use SSE.
Start with the client mechanism
The SSE standard defines EventSource, reconnection and Last-Event-ID. Those rules concern a particular event-consumption model. A stream read through POST fetch with a JSON body should not automatically inherit browser-managed EventSource reconnection behavior.
Record client and endpoint. Data lines do not establish recovery semantics. If a library adds retries, document that policy separately. Otherwise a user operation can execute again while the application believes it merely restored reading existing data.
Separate three actions
Reconnect restores transport. Replay repeats a request or saved sequence. Resume continues a previously defined operation from an agreed boundary. These are not synonyms: they impose different identifier, state-retention and work-accounting requirements.
RFC 9110 defines method semantics and automatic-retry limits. A generation POST does not become idempotent because its response uses SSE. An owned resume protocol is a separate design requiring retention periods and valid transitions.
Check identifier meaning
Last-Event-ID can identify an event-sequence position only where sender and receiver define that meaning. It is not a universal model request ID. A saved generation identifier alone does not establish an API capable of continuing computation.
A technical contract must answer which operation continues, how the last acknowledged position is determined, whether duplicate events are possible and what happens after state expiry. Without those answers, describe a new attempt rather than seamless continuation.
Build a disconnection fixture
Use a synthetic stream with numbered events. Interrupt reading after a known position, then perform the client’s documented recovery action. Compare request IDs, delivered events and attempt count. A repeated prefix can reveal replay but must not be removed automatically without a deduplication rule.
The OpenRouter streaming documentation describes stream reading and cancellation. It should not be interpreted as a general promise to resume any upstream generation. A bounded fixture tests only the selected interface’s declared behavior; added mechanisms require their own evidence.
Preserve ambiguity explicitly
After disconnection, original server completion may remain unknown. Do not hide that uncertainty behind “connection restored.” The final record should distinguish the original attempt from the subsequent action so user-visible output is not confused with executed-operation count.
Related guides cover incremental clients and fallback limits. Neither replaces a resume contract: a correct parser and a controlled retry solve different problems from continuing one previously accepted generation. Keep the exact interruption point and client policy with the fixture so the same recovery claim can be checked after upgrades.