429 handling inconsistent across providers → retry amplification under concurrency

[SirBrenton]

Checked other resources

• This is a bug, not a usage question. For questions, please use the LangChain Forum (https://forum.langchain.com/).
• I added a very descriptive title to this issue.
• I searched the LangChain.js documentation with the integrated search.
• I used the GitHub search to find a similar question and didn't find it.
• I am sure that this is a bug in LangChain.js rather than my code.
• The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code

// Current behavior in errors.ts:45 (langchain-anthropic)
if (e.status === 429) {
  // No Retry-After inspection
  // No distinction between transient vs quota exhaustion
  throw new RateLimitError(e);
}

// Missing: semantic classification before retry
// Retry-After: 30  → WAIT (retry after delay)
// Retry-After: 600 → STOP (quota exhaustion, do not retry)
// No header        → CAP (reduce concurrency first)

Error Message and Stack Trace (if applicable)

429 "You have exceeded the 5-hour usage quota. It will reset at [time]"
→ retried repeatedly
→ same message processed 90+ times
→ fallback never triggered

Description

Ran pitstop-check against the provider error handlers and found the same pattern across all four providers:

• libs/providers/langchain-anthropic/src/utils/errors.ts:45 — 429 without Retry-After
• libs/providers/langchain-openai/src/utils/client.ts:54 — 429 without Retry-After
• libs/providers/langchain-google/src/utils/errors.ts:191 — 429 without Retry-After, CAP vs WAIT not distinguished
• libs/providers/langchain-google/src/chat_models/base.ts:648 — no max elapsed bound
• libs/providers/langchain-openrouter/src/utils/errors.ts:44 — 429 without Retry-After, CAP vs WAIT not distinguished
• libs/providers/langchain-openrouter/src/chat_models/index.ts:478 — no max elapsed bound

Different 429 cases require different handling:

• short-lived pressure → retry after delay
• concurrency pressure → reduce parallelism before retry
• quota / billing exhaustion → do not retry

When collapsed into one branch, retries can't succeed and systems loop or amplify load.

Seen in a live system: quota-window 429 retried 90+ times, fallback never triggered.

Static check: github.com/SirBrenton/pitstop-check

cc Hunter Lovell (@hntrl) Christian Bromann (@christian-bromann) (via Jacob Lee (@jacoblee93))

System Info

Static analysis only — no runtime reproduction required.
Pattern confirmed in current main branch (cloned 2026-03-31).

[open-swe]

Fix PR: #10569

Changes:

• AsyncCaller now extracts Retry-After from 429 error responses (supports SDK Headers objects, plain header objects, and response.headers)
• Short Retry-After (≤60s): used as minimum backoff delay in p-retry, overriding the calculated exponential delay when larger
• Large Retry-After (>60s, indicating quota/billing exhaustion): aborts retries immediately with RateLimitQuotaExhaustedError
• OpenRouter error classes now capture response headers so Retry-After is available to the retry logic
• Anthropic, OpenAI, and Google providers already expose headers on their error objects and work automatically

[SirBrenton]

This is a solid improvement — especially pulling Retry-After into the retry loop and exposing headers consistently.

One thing worth flagging from the original issue: the core problem wasn't just missing Retry-After, but that different 429s were being treated as the same failure mode.

The >60s threshold is practical, but still a heuristic. In practice we've seen:

• long Retry-After values that still resolve with waiting
• shorter values that correlate with quota or burst exhaustion

So Retry-After alone doesn't fully disambiguate whether the correct action is wait, reduce rate, or stop entirely.

Curious whether incorporating additional signals — attempt history, total elapsed, retry budget — into that decision would be worth exploring, rather than relying on threshold alone?