Pitstop / 429 Classifier

Your retry logic is probably
burning budget.

Paste one 429 response. Get the right next action:
wait, shrink, or stop.

3 production fixes shipped within 24h of diagnosis. For engineers shipping agents, SDKs, proxies, or retry loops that misbehave under load.

Try the classifier ↓ No time? Email one redacted failure block →

Example

bash

curl -s -X POST https://web-production-273d3.up.railway.app/classify \
  -H "Content-Type: application/json" \
  -d '{"status":429,"headers":{"retry-after":"30"},"provider":"anthropic"}'

{
  "classification": "WAIT",
  "action":         "Honor Retry-After header. Retry after 30s.",
  "knob":           "retry_after_floor_ms"
}

Why it matters

retry-after: 30 →

WAIT Delay, then retry.

no retry-after →

CAP Reduce concurrency first.

retry-after: 600+ →

STOP Do not retry. Surface to caller.

Treating all 429s as "retry" is how systems amplify failure instead of absorbing it.

Proof

cline/cline #10139 — maintainer confirmed root cause in retry.ts, PR opened within 24h.
oh-my-openagent #3126 — fix merged within 24h, STOP_ERROR_NAMES shipped to production.
MassGen PR #1024 — WAIT/CAP/STOP adopted in production circuit breaker, 1,631 lines, 62 tests, @SirBrenton credited.
Continue.dev PR #11773 — retry architecture fix landed in thread with pitstop-check findings.
26 classified failure receipts across real systems — LangChain, OpenClaw, Vercel AI, Claude Code, and others.

Built from real production failures, not toy examples. github.com/SirBrenton/pitstop-truth →

How it works

Paste status + headers from your 429 response
Get WAIT / CAP / STOP back in seconds
Adjust the first knob instead of guessing

Have a weird 429?

Send one redacted failure block or retry config — stack, error, headers, whatever you have.
I'll tell you what to cap first. No call needed.

brentondwilliams@gmail.com
async · no call · turnaround same day

Your retry logic is probablyburning budget.

Have a weird 429?

Your retry logic is probably
burning budget.