What probably matters to youSection of the release
A new environment variable, CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS, controls the timeout for the first byte of a streamed API response; it is now recognized and passed through by the CLI's allowed-env-var list, and stream-start timeout logic was simplified to read it directly.
The retry-status UI in the chat now special-cases requests where the API gave no response at all, showing 'No response from the API after {duration}' with either 'retrying once, waiting up to {t}' (final attempt) or 'retrying, waiting up to {t} · attempt X/Y', plus a hint about buffering proxies and the CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS setting.
When a request fails with a StreamNoResponseError (no first byte received in time), the error message now reports how long Claude Code waited, including whether it escalated to a retry window, and suggests raising API_TIMEOUT_MS or CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS if a proxy or gateway is holding responses.
The entry above is what we published on the day. These lines were added later, as Anthropic's own pages caught up, and they sit beside the original rather than replacing it.
Confirmed sinceAnthropic's documentation has since written up CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS, on Error reference.| [`CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS`](/docs/en/env-vars) | unset | Deadline in milliseconds for the first response byte of a streaming request. Requires Claude Code v2.1.242 or later. For how Claude Code picks the deadline when this is…errorssee the edit
How sure we are
One source agreesOne thing we can check says the same as this entry.
Anthropic's documentation agreesAnthropic's documentation has since written up CLAUDE_STREAM_FIRST_BYTE_TIMEOUT_MS, on Error reference.
