Claude Platform on AWS is the Anthropic-operated offering that exposes the full Claude API surface through an AWS-native front door: SigV4 authentication, IAM-based access control, AWS Marketplace billing. Because it is Anthropic-operated, its rate limits are managed by Anthropic's own systems — not by AWS Service Quotas. And here Anthropic's documentation makes a distinction that matters a great deal for capacity planning: new organizations on Claude Platform on AWS start on the Start usage tier and do not move tiers automatically. Raising limits requires contacting Anthropic.
Contrast that with the first-party Claude API, where Anthropic documents that organizations move through usage tiers automatically over time — Start, then Build, then Scale — with each step raising the per-model requests-per-minute and token-per-minute ceilings. A team whose mental model comes from the first-party API expects growth to be met with quietly expanding headroom. On Claude Platform on AWS, that escalator is switched off.
What Start tier actually gives you
Claude Platform on AWS uses the same rate-limit structure as the first-party API: per-model limits on requests per minute (RPM), input tokens per minute (ITPM), and output tokens per minute (OTPM), enforced with a token-bucket algorithm. As an illustration of Start-tier scale, Anthropic's rate-limit page currently lists Opus-class, Sonnet, and Haiku 4.5 models at 1,000 RPM / 2,000,000 ITPM / 400,000 OTPM each, with Claude Fable 5 lower at 1,000 RPM / 500,000 ITPM / 100,000 OTPM. These figures are Anthropic's to change and do change — read them as "the shape of Start tier in mid-2026," not as commitments, and check the live rate-limits page for current values.
Helpfully, the ITPM math is cache-aware: cache-read tokens don't count toward the input limit for current models, so a workload with a high prompt-cache hit rate can process a large multiple of its nominal ITPM. That is often the cheapest headroom available while a limit-increase conversation is in flight.
Why the escalator is off
The documentation doesn't give a rationale, but the surrounding facts explain the posture. On the first-party API, tiers are tied to monthly spend thresholds and billing history with Anthropic. On Claude Platform on AWS, billing flows through AWS Marketplace in Claude Consumption Units, invoiced monthly in arrears — and several of the self-serve growth mechanisms of the first-party platform are documented as unavailable there: spend limits, per-workspace rate-limit configuration, and the programmatic Usage and Cost API among them. Limit management is simply a human process on this platform: your usage data lives in the Claude Console's Usage and Cost pages (which remain available), and the lever for more capacity is your Anthropic contact.
Signals you're hitting the ceiling
Because Claude Platform on AWS applies the same Anthropic-managed rate-limit system as the first-party API, the edge behaves the same way: exceeding a limit returns a 429 naming the exceeded limit, with a retry-after header telling you how long to wait. Rising 429s plus flat usage growth is the signature of an organization that has outgrown a tier that will not grow with it. Sharp spikes can also trip acceleration limits even below your nominal ceiling — see ramping traffic gradually — so distinguish "we burst too fast" from "we're genuinely too big for Start" before escalating.
One more planning note: because Claude Platform on AWS draws on its own capacity pool, separate from the Claude API and Bedrock, your first-party tier and history carry no weight here — signing up provisions a brand-new Anthropic organization tied to the AWS account, starting from Start.
Where to go next
See quota management on Claude Platform on AWS for day-to-day mechanics, rate-limit headers for reading headroom from responses, and Start-tier limits for streaming workloads for the throughput-shaping angle.