Claude rate limits: two systems that share one name

Two systems, one name

Which one applies to you is decided by how you authenticated, not by which product you opened. Claude Code signed in with a Claude subscription is on the first. Claude Code with an API key in the environment is on the second, and so is any application you build.

The subscription side

Three caps run at once on a Claude subscription, and the same allowance covers Claude chat, Claude Code, and Cowork. They are enforced per account, so parallel sessions divide one pool rather than each getting their own.

The current session limit is rolling

This is the part people consistently misread. The five-hour limit is not a bucket that empties at a fixed clock time. It is a trailing measurement of what you consumed over the past five hours, so if you burned most of it between 09:00 and 11:00, capacity returns gradually through the early afternoon rather than all at once. Sitting and waiting for a reset moment is the wrong mental model; the message gives a time because that is when enough will have aged out, not because a counter flips.

/usage            # plan bars, plus attribution by skill, subagent, and MCP server
/status           # which credential is actually active
/usage-credits    # buy past the limit on Pro and Max, at standard API rates

The API side

The Claude API meters three things per model, per minute: requests (RPM), input tokens (ITPM), and output tokens (OTPM). Exceeding any one produces a 429 naming which limit you crossed, with a retry-after header giving the seconds to wait. Limits apply separately for each model, so you can drive several models up to their respective limits at once.

• Tiers are assigned automatically from usage history and account standing, and you move up over time. New organisations may start in an Evaluation tier with limits below the standard table while history is established.
• Capacity is a token bucket. It replenishes continuously up to your maximum rather than resetting at fixed intervals, which is why a 60 RPM limit can be enforced as roughly one request per second and a burst still fails.
• Acceleration limits are a separate cause of 429s. A sharp increase in an organisation's usage can trigger them even below the published numbers. Ramp traffic gradually.
• Spend caps are not rate limits. Start is $500/month, Build $1,000, Scale $200,000. Hitting one pauses API usage until the next calendar month unless you request more.

Reading the headers

Every API response carries the limit, the remaining amount, and the reset time. Anything that shows you live Claude headroom is reading these, because there is no other source for the number.

curl -sS -D - -o /dev/null https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-haiku-4-5","max_tokens":8,"messages":[{"role":"user","content":"hi"}]}' \
  | grep -i ratelimit

Cache-aware ITPM: the lever most people miss

Most providers count every token toward a combined per-minute limit. Anthropic does not. On most Claude models only uncached input tokens count toward ITPM, which makes prompt caching a throughput lever, not just a cost one.

The arithmetic Anthropic gives: with a 2,000,000 ITPM limit and an 80% cache hit rate you can effectively process 10,000,000 input tokens per minute, because the 8M read from cache do not count. Cached input is also billed at a reduced rate, so the same change moves both numbers.

Telling them apart in ten seconds

echo "${ANTHROPIC_API_KEY:-(unset)}"    # unset means subscription billing
claude
/status                               # confirm the active credential

Questions people ask

Keep reading