Every Azure service carries limits, and Claude on Microsoft Foundry layers its own on top: quota pools, per-model rate limits, region constraints, and even rules about which kinds of subscription may deploy Claude at all. Teams usually discover these one 429 at a time. This article collects the documented limits worth checking before a scale-up, roughly in the order they tend to surprise people.
Subscription eligibility — the limit before the limits
Claude in Foundry requires a paid Azure subscription with a pay-as-you-go billing method and Azure Marketplace access. Free trial, student, and credit-only subscriptions are not supported, and Microsoft lists further unsupported types including Enterprise Accounts in South Korea, Cloud Solution Provider (CSP) subscriptions, and sponsored subscriptions running only on Azure credits. If your production landing zone is provisioned under a different commercial construct than your sandbox, verify eligibility early — this is a procurement conversation, not an engineering fix. Deployment also requires Contributor or Owner on the resource group and acceptance of Anthropic's Azure Marketplace terms.
Quota is per subscription, and shared
The limit teams most often misjudge: Foundry manages Claude quota at the subscription level, and all Global Standard deployments of the same model and version in a subscription draw from one shared pool across regions (Data Zone Standard deployments share a pool within each data zone). Creating more deployments, more resources, or a second region does not create more capacity. Three teams each running their own claude-sonnet-5 deployment in one subscription are silently sharing a single budget — and the noisiest team wins. If organizational isolation matters, isolate at the subscription boundary or apportion the pool with a gateway (see APIM in front of Foundry).
Default rate limits, by the numbers
Rate limits are measured in requests per minute (RPM) and uncached input tokens per minute (ITPM); ITPM counts uncached input tokens plus 5-minute and 1-hour cache-write tokens, while output tokens and cache reads don't count. Documented defaults as of July 2026:
| Models | Pay-as-you-go default | Enterprise / MCA-E |
|---|---|---|
| Opus family, Sonnet 5 | 40 RPM / 40,000 ITPM | 2,000 RPM / 2,000,000 ITPM |
| Sonnet 4.6, Sonnet 4.5, Haiku 4.5 | 80 RPM / 80,000 ITPM | 4,000 RPM / 4,000,000 ITPM |
| Claude Fable 5 | 0 RPM / 0 ITPM | 2,000 RPM / 2,000,000 ITPM |
Two readings of that table matter. First, 40,000 input tokens per minute is small for document-heavy workloads — a handful of large-context requests can consume it. Second, claude-fable-5 defaults to zero on pay-as-you-go: the deployment will provision successfully and every call will fail until quota is granted. Increases beyond defaults go through Microsoft's quota increase request form — build the lead time into your rollout plan rather than discovering it during launch week. And because Foundry does not return Anthropic's anthropic-ratelimit-* headers, your only signals are 429s and Azure monitoring; instrument accordingly and back off exponentially.
Structural limits that masquerade as details
Regions. Global Standard deployments are available in East US2 and Sweden Central; Data Zone Standard (US) covers a subset of models. A resource in any other region fails with "Region not available," and Anthropic's Supported Regions Policy can further restrict availability by billing country.
Immutable deployment names. The deployment name is the model value in API requests and cannot be changed after creation. At scale, an inconsistent naming scheme becomes a permanent tax; pick a convention while you have few deployments.
Per-model ceilings. Context windows differ (1M tokens for Fable 5, Opus 4.8/4.7/4.6, Sonnet 5, and Sonnet 4.6; 200K for others including Haiku 4.5 and Sonnet 4.5), as do max output tokens (128K for the 1M-context models, less for older ones). These bound your architecture per deployment, independent of quota.
Missing escape valves. Some pressure-relief mechanisms available elsewhere don't exist on Foundry: there is no Message Batches API, so bulk work must be paced through the same synchronous quota as interactive traffic.
Generic Azure ceilings. Ordinary Azure subscription and resource-group limits (resource counts, API keys per resource, and similar) also apply to Foundry resources; Microsoft's Claude docs don't call out Claude-specific numbers here, so check Azure's general subscription limits documentation when planning very large estates.
Where to go next
See Foundry quota types and requesting quota increases for the remediation path, and rate-limit handling for the client-side defenses.