{"version":"2.1.323","anchor":"rate-limit-retry-classifier-no-longer-treats-529-as-retryabl","canonical_anchor":"rate-limit-retry-classifier-no-longer-treats-529-as-retryabl","heading":"Retry check no longer names the 529 overloaded status directly","tier":"internal","area":"API Requests","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323\/e\/rate-limit-retry-classifier-no-longer-treats-529-as-retryabl","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323","markdown":"### Retry check no longer names the 529 overloaded status directly\n\nClaude Code's check for retryable rate-limit errors no longer looks for HTTP status 529 by name and still accepts 429\n\n**Unclear.** It is not clear whether 529 errors are still caught some other way, so overloaded requests may or may not still be retried.\n\n**What**\n\nWhen a request to the API fails, Claude Code checks whether the error is a rate-limit or overload error that it should retry. That check still accepts status 429, which means \"too many requests\". It no longer contains a separate check for status 529, the code the API uses to say it is overloaded.\n\n**Why**\n\nThis could change whether Claude Code retries a request on its own when the API reports that it is overloaded.\n\n- Area: API Requests\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}