{"version":"2.1.281","anchor":"api-error-kind-some-errors-lose-the-no-retry-suffix-new-5","canonical_anchor":"api-error-kind-some-errors-lose-the-no-retry-suffix-new-5","heading":"API error kind: some errors lose the _no_retry suffix; new 503 no-retry helper","tier":"internal","area":"Internals","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281\/e\/api-error-kind-some-errors-lose-the-no-retry-suffix-new-5","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.281","markdown":"### API error kind: some errors lose the _no_retry suffix; new 503 no-retry helper\n\nSome API errors are now labelled plain `http_` without the `_no_retry` suffix, and 503 no-retry responses get their own check\n\n**Unclear.** The finding does not say what the internal check tests or where the new 503 helper is used.\n\n**What**\n\nWhen a request to the API fails, Claude Code labels the error by its HTTP status, adding `_no_retry` when the server's `x-should-retry` header says not to retry. When a certain internal check returns a value, the label is now plain `http_${status}` even if `x-should-retry` is false. A new helper matches status 503 (service unavailable) with `x-should-retry` set to \"false\".\n\n- Area: Internals\n- Tier: Under the hood\n- Useful: 1\/5\n- Signal: 1\/5"}