Anthropic documents that Claude API rate limits — requests per minute, input tokens per minute, output tokens per minute, each enforced per organization per model — are implemented with a token-bucket algorithm with continuous replenishment, not a counter that zeroes out at fixed intervals. The mental model: you hold a bucket whose capacity is your limit. Every request removes tokens; the bucket refills at a constant drip equal to your limit spread across the minute. A 2M-ITPM limit is really "capacity 2M, refilling continuously at 2M per minute."
What continuous replenishment changes in practice
There is no top-of-minute amnesty. With fixed-interval resets, a throttled client can wait for the clock to roll over and instantly send a full minute's worth again. With a token bucket, capacity comes back gradually — if you drained the bucket, waiting three seconds buys you three seconds' worth of refill, not a fresh allocation. Retry logic written around "sleep until the next minute" is fighting the wrong mechanism; the retry-after header on a 429 response tells you the actual wait in seconds.
A quiet client earns a burst window. Because the bucket fills whenever you are under your rate, a workload that has been idle or light approaches full capacity — which it can then spend in a short burst faster than the steady-state rate. This is what makes token buckets friendly to spiky-but-modest traffic: a report job that fires 200 requests in five seconds once an hour can succeed even though "200 requests in five seconds" extrapolates to far above the per-minute rate. The bucket's capacity, not the instantaneous rate, is the hard boundary.
Sustained throughput is unchanged. The burst is a one-time spend of saved-up capacity. Over any long window your average rate cannot exceed the refill rate. Capacity plans should be built on the steady-state figure; the burst window is a shock absorber, not extra quota.
The ceiling on the ceiling: acceleration limits
A full bucket does not mean you can go from zero to maximum instantly and stay there. Anthropic documents that sharp usage spikes can trigger 429 errors from acceleration limits even when you have not exceeded your nominal rate limit — the system caps how quickly traffic may ramp, and the documented remedy is to increase traffic gradually. So the token bucket gives you a short burst window, and acceleration limits bound how aggressively you can exploit it: brief spikes from a warm, active client are the intended use; a cold client slamming to 100% and holding is what gets throttled. The launch-day implications are covered in the ramp-up article.
Reading the bucket's state
The Claude API reports the bucket back to you on every response through headers: anthropic-ratelimit-requests-limit / -remaining / -reset, with parallel families for tokens, input tokens, and output tokens. Reset times are RFC 3339 timestamps; token "remaining" values are rounded to the nearest thousand. One subtlety worth encoding in dashboards: the anthropic-ratelimit-tokens-* headers reflect the most restrictive limit currently in effect — if a workspace-level cap binds before the org limit, the headers show the workspace numbers. When a 429 does arrive, the error names which limit you exceeded, and official SDKs already retry 429s with exponential backoff honoring retry-after.
-remaining as bucket fill level, not a countdown to a reset. Alert on it trending toward zero under sustained load — that is a capacity problem; a brief dip during a burst is the algorithm working as intended.Not every platform is this bucket
This mechanism is documented for the Claude API, and Claude Platform on AWS uses the same rate-limit system. The other platforms enforce their own designs: Bedrock's current bedrock-mantle surface uses reservation-based admission control (input tokens plus max_tokens are reserved upfront and unused reservation is returned after completion), Vertex enforces per-lineage quota metrics through Google's quota system, and Foundry enforces RPM/ITPM without returning Anthropic's rate-limit headers at all — Microsoft directs you to Azure monitoring and backoff on 429s. Don't port bucket-reading logic across platforms unchecked.
Where to go next
Rate-limit headers covers the header family in detail; TPM vs RPM helps you figure out which bucket empties first; SDK rate-limit handling covers the client-side retry machinery.