Understanding Claude API rate limits

What a Claude API rate limit actually is

Claude API rate limits are throughput ceilings: how many requests and how many tokens your account may push through per minute. Exceed one and the API answers with HTTP 429 instead of a completion. apiToken.sale does not publish a fixed RPM table — a 429 there signals gateway or upstream capacity, and the durable fix is disciplined retries plus lower concurrency, not a bigger number in a config file.

On Anthropic's own API the ceilings are measured three ways: requests per minute, input tokens per minute and output tokens per minute, tracked per organization. Going direct, those ceilings rise through usage tiers as your cumulative spend grows. All three counters reset every minute, which is why a thirty-second burst can fail while your hourly average looks trivial.

See also: Claude API best practices

Reading a 429 response

A well-built client treats 429 as data, not failure. The body carries an error of type rate_limit_error, and the response usually includes a retry-after header with the number of seconds the server wants you to wait.

curl -i https://router.apitoken.sale/v1/messages \
  -H "x-api-key: sk-pool-•••" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 64,
    "messages": [{"role":"user","content":"hi"}]
  }'

# when throttled:
# HTTP/2 429
# retry-after: 17
# {"type":"error","error":{"type":"rate_limit_error","message":"..."}}

retry-after is a hint, not a contract, and not every 429 carries one. When the header is missing, fall back to exponential backoff with jitter — and never retry a 429 in a tight loop, which only deepens the congestion that caused it.

A retry policy that survives production

1. 01Queue bursts instead of firing them: each worker sends one request at a time.
2. 02On 429, read retry-after and sleep at least that many seconds.
3. 03When the header is absent, sleep base × 2^attempt plus random jitter, capped at ~30 seconds.
4. 04Stop after 4–6 attempts and fail the job loudly instead of retrying forever.
5. 05Log the model, wait time and attempt count so you have a pattern to show support if 429s persist.

const sleep = (ms: number) => new Promise((r) => setTimeout(r, ms));

async function callClaude(body: unknown): Promise<Response> {
  for (let attempt = 0; attempt < 5; attempt++) {
    const res = await fetch("https://router.apitoken.sale/v1/messages", {
      method: "POST",
      headers: {
        "x-api-key": process.env.APITOKEN_KEY!,
        "anthropic-version": "2023-06-01",
        "content-type": "application/json",
      },
      body: JSON.stringify(body),
    });
    if (res.status !== 429 && res.status < 500) return res;
    const retryAfter = Number(res.headers.get("retry-after"));
    const wait = retryAfter > 0
      ? retryAfter * 1000
      : Math.min(1000 * 2 ** attempt, 30_000) * (0.5 + Math.random() / 2);
    await sleep(wait);
  }
  throw new Error("Claude API still rate-limited after 5 attempts");
}

Why bursts trip limits before your averages do

Because the counters are per-minute, concurrency is the real lever. Fifty parallel calls at the top of a minute can exhaust the request budget even if you send nothing for the next hour. Token counters amplify this: every concurrent long generation keeps consuming output-token budget while it runs, so ten simultaneous 4,000-token answers put far more pressure on the limit than ten quick ones.

Streaming changes none of the accounting. A streamed call is still one request, metered and billed by the same input and output tokens as a non-streamed one — it only lets you render tokens sooner and abort early when an agent has what it needs.

Claude API streaming: SSE events and identical billing →

Throughput limits are not spending limits

Two systems get confused here. A rate limit is a traffic shaper: transient, per-minute, resolved by waiting. A spending guardrail is a budget brake: it decides how much a key may ever spend. On apiToken.sale the dashboard does not configure request throughput at all — the per-key guardrails it offers are an optional lifetime spending limit and an expiration date. A 429 says slow down; it says nothing about your balance, and topping up will not clear it.

Set a lifetime spending limit and expiration date on your key →

Lowering 429 pressure without raising the limit

• Stagger cron and batch jobs with random offsets so they do not stampede the same minute.
• Cap worker concurrency and let a queue absorb bursts.
• Trim context so each request carries fewer input tokens.
• Cap max_tokens to what the response actually needs.
• Cache large, stable context with prompt caching to cut billed input cost on repeats.

Most 429 storms are self-inflicted: a retry loop without jitter, a deploy that doubles workers, a scheduled job fanning out at :00. Fix the shape of the traffic before shopping for a higher ceiling.

When 429s become a capacity conversation

If smoothed traffic and correct retries still produce regular 429s at your target load, that is a capacity question, not a code question. Contact support with the model you use, your target requests and tokens per minute, and the shape of the workload — sustained higher throughput is handled as an account conversation, not a self-serve slider.

Frequently asked questions

Related guides