Menu

What's your rule for when an LLM call should NOT be retried?
πŸ“°

What's your rule for when an LLM call should NOT be retried?

DEV Community: apiΒ·nRouterΒ·about 2 hours ago
#X1x3KdD3
#devtoapi#devto#dev#retry#request
Reading 0:00
15s threshold

nRouter

nRouter

Posted on AI-assisted

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 Retry-After winning over our schedule.
  • Never retry 400/401/403. Fail fast, surface it, fix the request.
  • A retry budget, not just a count: retries get a slice of the task's total budget, then the task fails honestly.
  • If it dies mid-stream, restart the message cleanly β€” never append to a half-generated answer.

What I haven't settled: provider 529s / overloaded errors during peak. Retry in place, or fail over to a different model immediately and accept the quality change?

What's your rule set β€” and which error taught it to you?