# Retries और Exponential Backoff — Agent Loops, Stop Conditions और Token Budgets

Source: https://www.geekswithgeeks.com/hi/agent-loops/fail-retries-backoff

> अस्थायी errors को बढ़ती देरी से retry करें और स्थायी errors पर हार मान लें।

## सही errors को retry करें

Network की रुकावटें, rate limits (HTTP 429) और server errors (5xx) अक्सर **अस्थायी** होते हैं, इसलिए प्रतीक्षा के बाद retry सफल हो सकता है। ग़लत अनुरोध (400) या अनुमति errors (403) **स्थायी** हैं: retry सिर्फ़ पैसा बर्बाद करता है। सीमा के साथ **exponential backoff** (1s, 2s, 4s, 8s…) उपयोग करें, थोड़ा random jitter जोड़ें ताकि कई clients एक साथ retry न करें, और कोशिशें सीमित रखें।

## देरी की अनुसूची

यह जैसा दिखाया गया वैसा ही चला: देरी दोगुनी होती है जब तक 8 सेकंड की सीमा न आ जाए। असली कोड में हर एक में `random.uniform(0, 0.5)` जोड़ें।

```python
def delays(base=1.0, cap=8.0, tries=5):
    return [min(cap, base * 2 ** i) for i in range(tries)]

print(delays())
```

Output:

```
[1.0, 2.0, 4.0, 8.0, 8.0]
```

## Retry-After का सम्मान करें

Response में `Retry-After` header हो तो अपनी अनुसूची की जगह कम से कम उतनी देर रुकें। कई SDKs पहले से अस्थायी errors को retry करते हैं; अपनी परत जोड़ने से पहले जाँचें।

**Quiz:** प्रतीक्षा के बाद किस error को retry करना आम तौर पर सार्थक है?

- [ ] 400 Bad Request
- [ ] 403 Forbidden
- [x] 429 Too Many Requests
- [ ] ग़लत ID के लिए 404 Not Found

*Answer:* 429 Too Many Requests. Rate limits अस्थायी हैं; बाक़ी तब तक उसी तरह विफल होंगे जब तक अनुरोध न बदले।