{"version":"2.1.323","anchor":"overloaded-retry-path-gated-by-tengu-groovy-rain","canonical_anchor":"overloaded-retry-path-gated-by-tengu-groovy-rain","heading":"First retry after an overloaded server error can be handled differently","tier":"soon","area":"API Requests","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323\/e\/overloaded-retry-path-gated-by-tengu-groovy-rain","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323","markdown":"### First retry after an overloaded server error can be handled differently\n\nBehind a server-side switch, the first retry after an overloaded server error is no longer handled as an overload\n\n**Unclear.** What the overload handling does differently from a normal retry is not stated.\n\n**What**\n\nWhen the server answers with an error that Claude Code classes as overloaded, Claude Code retries the request. A new server-side switch changes the first retry. With the switch on, that first retry is not handled as an overload. Later retries, or any retry with the switch off, are handled as an overload as before.\n\n**Why**\n\nOn accounts where the switch is on, the first retry after an overloaded error behaves differently.\n\n- Flag `tengu_groovy_rain`: Off in both readings (read for one account on one subscription tier against v2.1.323; this account: off, anonymous baseline: off, compiled default: off) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: API Requests\n- Tier: Nothing to try yet\n- Useful: 1\/5\n- Signal: 3\/5\n- Scope: individual\n- Heads-up: no\n- Present in the build but not switched on"}