Knowledge base · TOPIC-07

Claude starts responding, then the stream stops

Short answer: Initial reachability and stream continuity are different observations. A response can begin after successful DNS, TCP, TLS, and HTTP work, then stop because a long-lived connection is interrupted or the application ends it.

The first byte proves that a responder returned data at that time. It does not prove that an intermediary, local path, client, or provider completed the full stream. Without termination evidence, root cause remains unknown.

Safe checks

• Record connect, TLS, first-byte, interruption, and total timing when available.
• Compare a short request with the affected long-running workflow.
• Check official provider status as a separate provider-reported signal.
• Correlate the interruption with sleep/wake, interface changes, or network transitions.
• Try one trusted alternate network, then verify with the same long-running task.

Do not infer that low latency guarantees stream reliability. Do not disable TLS validation or publish raw client logs containing prompts, cookies, or tokens. A defensible diagnostic should preserve the distinction between “stream began” and “completion observed” when such evidence exists. Tivor Open Probe V0.1 does not measure Claude application-layer streaming or long-lived connection continuity; its Claude scope is DNS, TCP, and certificate-validated TLS only.