You'll noticeTier: how much it should matter to you
3Useful: my rating, 1 to 5
1Signal: worth watching, 1 to 5
API ErrorsArea: what it touches
ImprovementsKind: in v2.1.288,
ImprovementsSection of the release
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 doubtIt is not clear what this handling actually does, for example whether it retries the request or skips a fallback.
