How do you detect a stalled Anthropic SSE stream, and what timeout should you set?

## Why the obvious timeout is the wrong one Every HTTP client you have used defaults to a total-request timeout, and for ordinary JSON APIs that is exactly right. Streaming breaks the assumption behind it. A long generation can legitimately keep the response open for minutes; Anthropic's own guidance is to stream long requests rather than wait on a buffered response. So a 30-second total timeout does not protect you from anything — it just cancels valid work — while a 10-minute one lets a genuinely wedged socket hold a request slot for ten minutes. The useful question is not "how long has this run?" but "how long since anything happened?". A healthy stream produces frames continuously: content deltas while the model generates, and `ping` events, which carry no payload and exist so a stream that is briefly quiet still shows signs of life. Silence for longer than a few tens of seconds is anomalous; five minutes of steady deltas is not. ## Building the watchdog Keep a deadline that is reset on **every** received frame, not only on ones you find interesting. This is where implementations go wrong: a relay that resets its timer only when it forwards visible text will consider a stream dead during a stretch of pings or of non-text blocks. Skip unknown and uninteresting events for *processing* purposes, but count them as liveness. HTTP clients give you part of this for free. A read timeout is measured per read rather than across the whole response, so when you consume a stream chunk by chunk it already behaves as an idle timeout — the SDK's timeout setting flows down to that behaviour. What it cannot cover is the layers you add: if you buffer events, hand them to a queue, or re-emit them into your own SSE or WebSocket stream to a browser, each hop needs its own liveness notion, and the browser side needs one too, since a healthy backend that stops producing looks identical to a network partition from the client's seat. ## Completion is a separate check from liveness Timeouts answer "is it still alive?". They do not answer "did it finish?". Those are different failures and both must be handled. A stream that terminates without `message_stop` was truncated, no matter how promptly its bytes arrived; treat the absence of the terminator as an error in the accumulator itself, rather than trusting callers to notice. Conversely, a stream that is slow but eventually delivers `message_delta` and `message_stop` succeeded, and any timeout that killed it was misconfigured. ## Infrastructure that fakes a stall Before blaming the provider, check your own path. Reverse proxies, CDNs, API gateways and some serverless platforms buffer responses by default, holding output until a size threshold or the response ends. Behind such a hop, a perfectly healthy stream arrives as one lump at the end — which destroys the entire point of streaming and reads, from the client, as a long stall followed by a burst. The fix is per-platform: disable response buffering on that route, or use whichever mechanism your proxy honours to mark the response as unbuffered. Compression middleware that buffers to compress causes the same symptom. Any "streaming is broken in production but fine locally" report should send you here first. ## Reasonable settings There is no universal number, but the reasoning is portable. Pick an idle budget comfortably above the largest normal inter-event gap you observe — the interesting gap is usually the one before the *first* content event, since the model may think before it speaks, and that gap grows when extended thinking or a large cached prefix is involved. Instrument time-to-first-event and the maximum inter-event gap as histograms, then set the budget from the tail rather than from intuition. Keep a generous ceiling on total duration as a backstop against pathological cases, but do not make it your primary control. ## What to do on a stall A stalled stream is a mid-flight failure like any other: you may already have shown text to the user. Cancel the request to release the connection, emit an explicit failure into your own client protocol rather than just hanging up, and decide deliberately whether to retry — remembering that a retry regenerates from the start and re-bills the input. Track stalls separately from clean errors; a rising stall rate usually points at your own network path or a newly introduced buffering hop, not at the model.