{"version":"2.1.288","anchor":"rate-limit-style-timeouts-timedout-no-longer-retriedhandl","canonical_anchor":"rate-limit-style-timeouts-timedout-no-longer-retriedhandl","heading":"API timeouts get their own timedOut cause and are retried","tier":"notice","area":"API Errors","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.288\/e\/rate-limit-style-timeouts-timedout-no-longer-retriedhandl","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.288","markdown":"### API timeouts get their own timedOut cause and are retried\n\nAPI timeout errors are now classified as timedOut instead of serverError, and are retried or sent to a fallback model rather than failing\n\n**Unclear.** It is not clear what this handling actually does, for example whether it retries the request or skips a fallback.\n\n**What**\n\nWhen a request to the model fails, Claude Code labels why and decides whether to try again. Timeouts now have their own label:\n\n- A server error that is a `timeout_error` is now classified as `timedOut` instead of `serverError`.\n\n- The retry decision handles `timedOut`: it switches to the fallback model when one is available (when only thinking was produced), and otherwise retries once.\n\n- A new input, `outlastedNonStreamingTimeout`, means a `serverError` that comes after a non-streaming timeout was outlasted is also retried.\n\n- At the output stage, `timedOut` is now handled by the same branch as `overloaded` and `serverError`.\n\n**Why**\n\nRequests 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.\n\n- Area: API Errors\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}