Anthropic's rate-limits documentation contains a sentence that surprises most teams the first time it bites: in addition to the per-model RPM and token-per-minute limits, sharp usage spikes can trigger 429 errors from acceleration limits — and the documented remedy is to ramp traffic gradually rather than sending it all at once. In other words, the platform limits not only your rate but your rate of change of rate. Nominal headroom is necessary but not sufficient; how fast you climb toward it matters too.
Why a slope limit exists
Serving large models is a capacity-allocation problem. A steady 2M tokens per minute is traffic the platform can plan around; the same 2M arriving as a step function from zero looks, from the serving side, like an incident. Acceleration limits give the platform time to allocate for genuine growth while damping the pathological patterns — thundering-herd retries, a misconfigured load test, a fleet of workers all starting on the same cron tick. The token-bucket algorithm underneath the standard limits already tolerates short bursts from a warm client (see the burst-window article); acceleration limits are the guardrail on cold-start step functions and sustained vertical ramps.
Diagnosing an acceleration 429
The confusing symptom is 429s while your dashboards insist you are under quota. Useful signals on the Claude API: the 429 response names which limit was exceeded and carries a retry-after header with the seconds to wait; the anthropic-ratelimit-*-remaining headers show whether the standard buckets were actually near empty. If throttling coincides with a sharp traffic step and the headers showed plenty remaining, you have found the acceleration limiter. Also distinguish 429 from 529: a 529 overloaded_error reflects API-wide load, not your account — the response there is backoff and patience, not a quota ticket.
One more platform-specific impostor is worth ruling out. On Bedrock's current bedrock-mantle surface, admission control reserves your input tokens plus the full max_tokens against the input-TPM quota at request start, replenishing the unused portion only after completion. A spike of concurrent long-running requests with generous max_tokens can therefore 429 well below your apparent token consumption — a reservation problem that looks like a spike problem. AWS additionally warns that its EstimatedTPMQuotaUsage CloudWatch metric does not reflect this reservation accounting, so don't debug from that metric alone.
The launch pattern that works
Ramp over minutes, not milliseconds. Instead of cutting 100% of traffic over at once, step through the gradient — for example 10%, 25%, 50%, 100% with a few minutes' soak at each step, watching 429 rates and the rate-limit headers before advancing. Anthropic's guidance does not prescribe a specific schedule, so treat the shape (gradual, monitored) as the requirement and tune the numbers to your workload.
Stagger your workers. Batch jobs that start hundreds of workers on the same second create a step function by construction. Add jitter to worker start times and cron schedules so the ramp is built into the architecture.
Respect retry-after, with backoff and jitter. Official SDKs already retry 429s and 5xx errors with exponential backoff (twice by default) honoring retry-after. If you implement your own retries, never retry in a tight loop — synchronized immediate retries are themselves a spike, and they re-trigger the very limiter that rejected you.
Warm the cache before the wave. If your prompts share a large cached prefix, the first requests after launch are all cache writes, which count toward input-TPM. A small pre-warm trickle ahead of the ramp moves that cost out of the critical window (see caching and effective throughput).
Where to go next
Size the destination with the quota-estimation formula, understand the underlying meter in the token-bucket article, and wire up client behavior per SDK rate-limit handling.