Unlike a virtual machine, Claude capacity is not something you provision; it is something you are permitted. Bedrock, Vertex AI, Foundry, and Claude Platform on AWS each meter usage through quotas and rate limits, typically expressed as requests and tokens per unit of time, with defaults that suit experimentation rather than production. The specific numbers vary by platform, model, region, and account, and they change, so this article covers the method: estimate your demand in tokens, compare it with your granted limits, and close the gap before launch day rather than during it.
Estimate demand in tokens, not requests
Platforms meter tokens as well as requests, and tokens are almost always the binding constraint for prompt-heavy enterprise workloads. The estimate is four numbers multiplied together. As a worked illustration, assume a document-processing feature with a peak of 5 requests per second, averaging 3,000 input tokens and 500 output tokens per request. Peak demand is 5 × (3,000 + 500) = 17,500 tokens per second, or about 1.05 million tokens per minute, alongside 300 requests per minute. Run this per model tier, because quotas are typically granted per model: if 80% of that traffic goes to Haiku 4.5 and 20% to Opus 4.8, each needs its own line in the plan.
Get the peak number honestly. Business workloads are rarely flat: support traffic peaks after product launches, document pipelines peak at month-end close, retail peaks in seasonal bursts. Size against the busiest expected hour, not the daily average, and note that averages routinely understate the binding peak by several times.
Compare against granted limits, with headroom
Look up your current limits in your platform's console rather than in documentation, because granted limits are account-specific. Then apply two corrections before declaring yourself covered. First, add headroom: running at the edge of a quota means every minor traffic fluctuation produces throttling errors, so plan for meaningful slack above projected peak. Second, account for retries: a system that retries failures multiplies its own request volume exactly when it is under stress, so a plan with zero margin fails in a self-reinforcing way. If projected peak plus headroom exceeds granted limits, file the increase request now. Quota increases involve human review at every provider and take time, which is why they belong in the launch plan next to security review, not in the incident channel.
Engineering the peak down
Quota increases are one lever; shrinking the peak is the other, and it is often faster. The biggest win is moving non-urgent work out of the peak entirely: nightly report generation, bulk document backfills, and re-processing jobs have no business competing with interactive traffic at 2 p.m. Where the Batch API is available (Claude Platform on AWS, but notably not Bedrock or Vertex AI), it is the natural home for this work; elsewhere, a simple queue that drains during quiet hours achieves the same flattening. Beyond scheduling: client-side rate limiting and request queues turn a thundering herd into an orderly line; prompt trimming and caching-friendly prompt structure reduce the token side of the equation; and tiering routine work to Haiku 4.5 moves demand onto a separate, cheaper pool of quota. Graceful degradation is the final backstop, so decide in advance what happens when you are throttled anyway: queue and notify, or fall back per your resilience plan.
Watch it like a utility
After launch, capacity planning becomes a monitoring habit. Track consumption as a percentage of granted limits per model and region, and alert well before saturation; rising retry rates with flat user traffic are the earliest warning that you are outgrowing a quota. Review the trend monthly and file increases while they are still routine requests. Teams that treat quota utilization like disk utilization (a boring graph someone owns) simply do not have launch-day throttling incidents.
Where to go next
See Quotas and Rate Limits: How Each Platform Meters Claude for the per-platform mechanics, and Retries, Timeouts, and Fallbacks for handling the throttling you did not prevent. The launch checklist puts this in sequence.