{
  "id": 16715696,
  "title": "What's your rule for when an LLM call should NOT be retried?",
  "url": "https://urgent.news/2026/10/27/whats-your-rule-for-when-an-llm-call-should-not-be-retried",
  "topic": "ai",
  "section": "AI",
  "published": "2026-10-27T06:16:41.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/support_nrouter_32e2e550b/whats-your-rule-for-when-an-llm-call-should-not-be-retried-10eb"
  },
  "original_language": "en",
  "account": "Everyone has a rule for when to stop retrying an LLM call. Mine is simple: don't retry a 400, 401, or 403 error. The request is inherently flawed, so continuing to send it is pointless. Instead, surface the problem and fix the request. I also enforce a retry budget, allocating a portion of the task's total budget for retries. Once the budget is exhausted, the task fails honestly. I never append to a half-generated answer after a mid-stream failure; instead, I restart the message cleanly. The one area I'm still unsure about is how to handle provider 529 errors or other overloaded conditions during peak times. Should I retry in place, or fail over to a different model and accept a potential drop in quality? This particular error taught me the importance of having a nuanced retry strategy that considers the specific nature of the error and its potential impact on the user experience.",
  "summary": "Everyone has a retry story. Mine: an agent that retried a malformed request eleven times before anyone noticed, each attempt replaying the full conversation. The request was never going to succeed — a 400 doesn't heal — but the retry policy didn't care, because it only looked at \"did it throw?\" Our working rules now: Retry timeouts, 429s and 5xx — with backoff, jitter, and the server's…",
  "key_points": [
    "Don't retry 400, 401, or 403 errors as requests are flawed",
    "Enforce retry budget, exhaust budget leads to task failure",
    "Uncertain about handling 529 errors, consider retry vs model switch"
  ],
  "editors_take": "Distinguishing between client-side flaws and server-side congestion allows developers to avoid wasted compute while deciding whether to prioritize system reliability or model quality during peak traffic periods.",
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}