Show HN: Pitstop-check – finds the retry bug that turns 429s into request storms

I kept running into the same bug in AI agent codebases: retry logic that ignores Retry-After under concurrency. Looks fine at first. Under load it turns rate limits into request storms. I wrote a small CLI to catch it: npx pitstop-check ./src It scans TS/JS and flags things like: - 429 handled without Retry-After - blanket retry of all 429s (no CAP vs WAIT distinction) - unbounded retry loops (no max elapsed) Example (ran against OpenClaw): [WARN] src/agents/venice-models.ts:24 — 429 handled without Retry-After [WARN] src/agents/venice-models.ts:24 — All 429s treated as retryable — CAP vs WAIT not distinguished The retry primitive supports Retry-After. The callers just don’t wire it up. So when the API returns Retry-After: 600, the client retries on its own schedule instead of backing off. What’s going on is basically collapsing different failure modes into one: WAIT — respect Retry-After CAP — limit retries / concurrency STOP — don’t retry Most code just does: retry() The tool is heuristic (will flag some test files), but it’s been useful for quickly spotting this in real repos. https://github.com/SirBrenton/pitstop-check https://github.com/SirBrenton/pitstop-check