Microsoft Foundry organizes Claude around a two-level hierarchy: a Foundry resource holds security and billing configuration, and deployments inside it are the model instances you actually call. It's natural to assume each deployment brings its own rate limits. Microsoft's documentation says otherwise: quota is managed at the subscription level and shared. All Global Standard deployments of the same model and version within an Azure subscription draw from one pool — across resources, and across regions. Data Zone Standard deployments likewise share a pool within each data zone.
So a team that deploys claude-sonnet-5 in East US2 and again in Sweden Central hasn't doubled its Claude capacity. It has created two doors into the same room. Ten deployments spread across ten resources for ten internal teams still share exactly one subscription-wide allocation for that model version.
How the limits are measured
Foundry rate limits come in two dimensions: requests per minute (RPM) and uncached input tokens per minute (ITPM). The ITPM counter has its own particular accounting — uncached input tokens plus cache-write tokens count; output tokens and cache reads don't — covered in detail in what Foundry counts as input tokens.
The default sizes depend heavily on your Azure agreement type, and the published table (current as of Microsoft's June 2026 doc update, subject to change — always check the live page) is worth reading closely. For standard pay-as-you-go subscriptions, Microsoft lists 40 RPM / 40,000 ITPM for Opus-family models and Sonnet 5, and 80 RPM / 80,000 ITPM for Sonnet 4.6, Sonnet 4.5, and Haiku 4.5. Enterprise Agreement / MCA-E subscriptions get dramatically more: 2,000 RPM / 2,000,000 ITPM for Opus-family, Sonnet 5, and Fable 5, and 4,000 RPM / 4,000,000 ITPM for the Sonnet 4.x and Haiku 4.5 tier. Two edge cases stand out: claude-fable-5 defaults to 0 RPM / 0 ITPM on pay-as-you-go (it simply won't serve traffic without an enterprise agreement or an approved increase), and free-trial subscriptions get zero across the board.
What deployments are actually for
If deployments don't add capacity, why create more than one? Isolation of configuration, not capacity. Separate deployments give you separate deployment names, separate resources for RBAC and network boundaries (private endpoints attach at the resource level), separate regions for latency or data-zone requirements, and cleaner per-team cost attribution in the Foundry portal's monitoring. Those are good reasons. "More throughput" is not on the list.
This also means noisy-neighbor problems live inside your own subscription. A batch job hammering one deployment can starve a customer-facing service on a different deployment of the same model version, in a different region, owned by a different team. If two workloads must never contend, the subscription is the isolation boundary Foundry gives you: put them in different Azure subscriptions, each with its own pool.
Planning and raising the pool
Capacity planning on Foundry therefore happens at the subscription level: sum the expected RPM and ITPM of every workload that will touch a given model version anywhere in the subscription, and compare that against one number. When the defaults aren't enough, Microsoft directs quota increases beyond the defaults through its quota increase request form (linked from the Claude models page). Note that Foundry gives you no per-request headroom signal to watch — it doesn't return Anthropic's rate-limit headers — so subscription-level consumption has to be monitored through Azure Monitor metrics instead.
Where to go next
See Foundry quota types for the taxonomy, requesting a Foundry quota increase for the process, and pay-as-you-go vs enterprise limits for why agreement type is the biggest single lever on your default capacity.