Follow Discord
Sweep 22 Oct 2026 · 04:32Z Build v2.1.308 527 read Stable v2.1.308 Latest v2.1.308 Next v2.1.308 Feeds RSS JSON llms.txt llms-full.txt Unofficial

Claude Code v2.1.288 ·

API timeouts get their own timedOut cause and are retried

API timeout errors are now classified as timedOut instead of serverError, and are retried or sent to a fallback model rather than failing

Group of 3 You'll notice Internal Changes
JSON All of v2.1.288
You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
2Signal: worth watching, 1 to 5
API ErrorsArea: what it touches
Internal ChangesKind: in v2.1.288,
ImprovementsSection of the release

Unclear Where this label is shown is not stated.

What

When a request to the model fails, Claude Code labels why and decides whether to try again. Timeouts now have their own label:

  • A server error that is a timeout_error is now classified as timedOut instead of serverError.
  • The retry decision handles timedOut: it switches to the fallback model when one is available (when only thinking was produced), and otherwise retries once.
  • A new input, outlastedNonStreamingTimeout, means a serverError that comes after a non-streaming timeout was outlasted is also retried.
  • At the output stage, timedOut is now handled by the same branch as overloaded and serverError.

Why

Requests that time out are more likely to be retried or moved to a fallback model instead of ending the turn with an error, and timeouts can be told apart from other server errors.

How sure we are
Something disagreesSomething we can check disagrees with this entry, or the writer said they could not settle it.
The writer flagged doubtWhere this label is shown is not stated.

See this entry in the whole of v2.1.288 →

Feedback