How do I set Claude Code's overloaded retry delay with `CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS`?

Q: What's the exact variable name?

CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS (CHANGELOG 2.1.292).

Q: What's the default value?

[GAP] — not stated in the CHANGELOG. Don't invent one.

Q: Is this for 429 rate limits?

No. It targets overloaded (529) retry backoff. For plan/rate-limit management, see the rate-limits Spec.

Claude Code 2.1.292 adds CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS for longer 529 overloaded retry backoff. Docs lag. Default ms is [GAP]. 529 ≠ 429.

From Claude Code 2.1.292, you can set a longer base delay for the backoff when retrying an overloaded (529) request with CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS. That name and purpose come verbatim from the CHANGELOG. As of 2026-10-07, the official env-vars page still does not list this variable. This is not the same knob as plan 429 / usage rate limits — see How do I manage Claude Code rate limits?.

TL;DR: Env CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS · purpose = longer base delay for 529 overloaded retry backoff · floor 2.1.292 · default ms [GAP] (not in CHANGELOG) · env-vars docs lag confirmed 2026-10-07 · 529 ≠ 429. Checked 2026-10-07.

What 2.1.292 added

Use this when Claude Code is retrying after an overloaded (529) response and you want a longer base backoff delay than the built-in default. The CHANGELOG only says you can set a longer base delay — it does not say what the built-in default is [GAP].

The Claude Code CHANGELOG entry for 2.1.292 includes this bullet (verbatim):

Added CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS environment variable to set a longer base delay for the backoff when retrying an overloaded (529) request

Facts that bullet supports, and no more:

Exact env name: CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS
Purpose: set a longer base delay for backoff when retrying an overloaded (529) request
Shipped in 2.1.292

The CHANGELOG does not give a numeric default, min/max, calendar ship date, slash command, or interaction with other retry-related envs. Those are [GAP] — do not invent them. The _MS suffix in the name implies milliseconds as the unit convention; that is naming only, not a published default integer.

How to set `CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS`

Shell, before launching claude:

export CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS=<value>   # value semantics unpublished beyond "longer base delay"; no default published
claude

Settings file, using the generic env key documented for any variable on the env-vars page (this page still has no row for this var by name):

{
  "env": {
    "CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS": "<value>"
  }
}

Use ~/.claude/settings.json for yourself, or managed settings for org-wide. Whether project .claude/settings.json may set this env is [GAP] — CHANGELOG is silent; prefer shell, user, or managed until docs say.

Relaunch. Shell exports always need a new claude process. Settings env often reapplies on save, but which variables are startup-only isn't stated for this one [GAP] — relaunch to be sure.

Check claude --version. You need 2.1.292 or later.

Docs lag — what to trust

Rechecked 2026-10-07 ~08:15 CEST:

Source	What it says
CHANGELOG 2.1.292	Adds `CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS` for longer base delay on overloaded (529) retry backoff
env-vars	No row for `CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS` / `OVERLOADED_RETRY` (string search)

Our read: trust the CHANGELOG for the env name and 529 purpose until env-vars publishes a row. Other retry wording on the same docs page (for example harness/CLAUDE_CODE_RETRY_WATCHDOG context that mentions 429/529) is not this variable — do not invent a default from that text.

If env-vars catches up and renames or documents a default, follow the live docs and update this page.

529 ≠ 429 — rate-limits Spec

529 overloaded = capacity/overloaded response; this Spec's env lengthens the retry base delay for that backoff.
429 / plan usage limits = shared five-hour and weekly bars (and related ceilings). Manage those with /usage and the habits in How do I manage Claude Code rate limits?. Optional context: Claude usage limits.
Sibling env Specs are different knobs: WebSearch refill · turn off WebFetch.

Setting this env does not raise plan usage limits or change 429 handling.

If you are hitting plan ceilings and seeing usage-limit messages rather than overloaded retries, fix the usage side first (/usage, wait for reset, or the habits on the rate-limits Spec). Lengthening 529 backoff only helps when the failure mode is overloaded capacity retries.

Pitfalls

Expecting env-vars to list it already. It didn't as of 2026-10-07.
Setting it on a build older than 2.1.292. CHANGELOG first names it there.
Inventing a default such as "5000ms." Not published — [GAP].
Treating the rate-limits Spec as this knob. That page is 429 / plan usage; this page is 529 retry base delay.
Inventing a slash command. None found in the 2.1.292 bullet.

FAQ

What's the exact variable name?

CLAUDE_CODE_OVERLOADED_RETRY_BASE_DELAY_MS (CHANGELOG 2.1.292).

What's the default value?

[GAP] — not stated in the CHANGELOG. Don't invent one.

Is this for 429 rate limits?

No. It targets overloaded (529) retry backoff. For plan/rate-limit management, see the rate-limits Spec.

Why isn't it in env-vars docs?

Docs lag as of 2026-10-07. Recheck the env-vars page; until then cite CHANGELOG 2.1.292.

Sources (checked 2026-10-07 ~08:15 CEST)

Claude Code CHANGELOG, entry 2.1.292 (OVERLOADED bullet)
Environment variables (no OVERLOADED row yet)