SSE streaming delivers an agent run's output over Server-Sent Events as it is produced, rather than withholding everything until the run completes. For agent workloads this is close to mandatory: a multi-step run with tool calls can take tens of seconds, and a blank screen for that long reads as a failure.
Why SSE rather than WebSockets
Agent output is one-directional — server to client — for the duration of a run. SSE is a plain HTTP response with a streaming body, so it works through ordinary proxies and CDNs, reconnects natively, and needs no separate connection lifecycle. WebSockets solve bidirectional messaging, which is not the problem here.
Replay is what makes it durable
Streaming alone is fragile: drop the connection and the output is gone. Anter writes chunks monotonically and exposes a deduplicated replay endpoint, so a client can reconnect and pick up from any index without re-triggering the run.
That last clause is the important one. Naive reconnection re-issues the request, producing a second execution — duplicated tool side effects, duplicated cost. Replay reads the existing run's recorded output instead.
Resume vs. restart
Not every interruption can be resumed. The runtime distinguishes between a run whose recorded state is sufficient to continue and one that must start the answer fresh. A run cancelled before producing any output records nothing for that turn — you will never see an orphaned user message with no matching answer.
Implications for clients
If you are building against the streaming API directly:
- Track the last chunk index you received, and reconnect with it
- Do not treat a dropped connection as a failed run — check the run's termination reason before retrying
- Expect internal activity (tool calls, handoffs) in the stream that will not appear in persisted session history afterwards; see execution trace