Rate-limit headers decoder

What it does

Paste the headers of a response, as curl -i, curl -v or your browser's DevTools show them. The decoder shows:

• how much of each limit is left;
• when each limit is fully replenished;
• how long to wait before retrying, counting down;
• which limit decides.

Everything runs in your browser: nothing you paste is sent anywhere.

Secrets are hidden as you paste

An authorization header, a cookie or an API key header can be in what you copy. Their values are replaced with [hidden] the moment you paste them, before the tool keeps, shows or shares anything. That holds in every layout it reads: name: value lines, a value on the next line, folded lines, curl's [HTTP/2] lines and a JSON object. Any value that looks like a credential, such as Bearer … or sk-…, is hidden too, whatever the header. A shared link or a saved file opened here is hidden the same way before it is read.

What it reads

A header is read only when a source says what it means:

• Salyro's headers: x-ratelimit-limit-requests, x-ratelimit-remaining-requests and x-ratelimit-reset-requests (a duration such as 42s), with retry-after and x-request-id. These are read by the same definitions the gateway sends them with. Salyro limits requests per minute only, and sends no token headers.
• Anthropic's headers: every anthropic-ratelimit-* and anthropic-priority-* header on Anthropic's rate-limits page. That covers the limit, the remaining count (tokens are rounded to the nearest thousand) and the reset time in RFC 3339.
• retry-after and date: as RFC 9110 defines them. retry-after is a number of seconds or a date. date is the server's clock, and waits are counted from it when it is there.

Anything else is listed as not recognised, and not guessed at. That includes OpenAI's, Gemini's and xAI's own rate-limit headers, because their pages could not be read when this tool was built. Salyro uses OpenAI's spelling for its request headers, so those are read as Salyro's.

Which limit decides

• When a limit is used up, the one that resets last is the one that decides: you can retry once it is replenished. When a used-up limit gives no reset time, the wait is unknown, and the decoder says so.
• Anthropic rounds remaining tokens to the nearest thousand, so a 0 there means fewer than 500 left. It counts as used up only on a 429.
• Otherwise, it is the limit with the smallest share left.
• When retry-after is sent, it is the wait to follow.

What it does not know

• Your live limits. It reads the headers you paste; it does not call any API.
• What a header it does not recognise means. It says so rather than guessing.

FAQ

Why does my 429 have no retry-after?

Anthropic states that the 429 sent when a spend cap is reached carries no retry-after, and that retrying fails until access resumes. Otherwise a 429 from Anthropic or Salyro comes with a retry-after in seconds.

Why are the token counts round numbers?

Anthropic's page states that the remaining token counts are rounded to the nearest thousand.

Sources

Anthropic's headers are quoted from its rate-limits page on platform.claude.com. Salyro's come from the gateway's own definitions, and retry-after and date from RFC 9110.