Microsoft Foundry in Practice

Understanding Foundry Quota Types: TPM, RPM, and Request Limits

Claude on Foundry is rate-limited on two dimensions — requests per minute and input tokens per minute — and both are shared across your whole subscription. Knowing how they're counted keeps 429s from surprising you.

Claude 3P 101 · Updated July 2026 · Unofficial guide

Every managed Claude platform throttles traffic somehow, but each counts differently. On Microsoft Foundry, Claude rate limits are measured in Requests Per Minute (RPM) and uncached Input Tokens Per Minute (ITPM). You may see the generic term "TPM" (tokens per minute) around Azure — for Claude models the documented token dimension is specifically ITPM, and the "I" matters, because it changes what counts against your quota.

What counts, what doesn't

RPM is simple: each API request is one unit, regardless of size. ITPM counts uncached input tokens plus tokens written to the 5-minute and 1-hour prompt caches. Two things explicitly do not count: output tokens, and cache reads. That asymmetry is the design of your cost- and quota-efficiency lever — a long system prompt served from cache consumes no ITPM on subsequent requests, so effective prompt caching stretches the same quota across far more traffic. (Caching is generally available on Foundry; see Foundry prompt caching.)

The two dimensions interact as a pair of independent ceilings: whichever you hit first throttles you. Chatty low-token traffic exhausts RPM first; document-heavy workloads with big prompts exhaust ITPM first. Size against both.

Quota is subscription-level and shared

Quota is managed at the Azure subscription level, not per deployment. 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. Practical consequences: creating a second deployment of the same model doesn't create new capacity, a noisy dev workload can starve production in the same subscription, and putting production in its own subscription is the clean isolation move.

Default limits by model and agreement type

ModelPay-as-you-goEnterprise / MCA-E
Opus-family, Sonnet 540 RPM / 40,000 ITPM2,000 RPM / 2,000,000 ITPM
Sonnet 4.6, Sonnet 4.5, Haiku 4.580 RPM / 80,000 ITPM4,000 RPM / 4,000,000 ITPM
Claude Fable 50 RPM / 0 ITPM2,000 RPM / 2,000,000 ITPM
Any model, Free Trial subscription0 across the board (Claude requires a paid subscription)

Two rows deserve a second look. Free Trial subscriptions get zero quota — Claude on Foundry requires a paid, pay-as-you-go-billed subscription. And claude-fable-5 defaults to zero on pay-as-you-go: you can deploy it, but you can't send it traffic until you obtain quota, which for non-enterprise subscriptions means requesting a quota increase.

Reading your consumption — without rate-limit headers

Here Foundry differs sharply from the first-party Claude API: Foundry does not return Anthropic's standard anthropic-ratelimit-* response headers. Your application cannot inspect a response to learn how much quota remains. The documented approach is twofold: monitor consumption through Azure's monitoring tools, and treat HTTP 429 responses as the signal to back off, retrying with exponential backoff (add jitter so synchronized clients don't stampede). For per-model token and request detail, the Foundry portal's Monitoring tab breaks down usage; Azure Cost Management shows the billing side as a single Claude Consumption Unit line. Deeper patterns are in Foundry rate limit handling and Azure Monitor for Foundry.

Rule of thumb: capacity-plan on ITPM, not requests. Estimate average uncached input tokens per request, multiply by expected requests per minute, compare to your pool, and leave headroom for bursts. Then verify the estimate against the Monitoring tab after a week of real traffic.

Where to go next

If the defaults don't fit, the process and preparation are in requesting a quota increase. For how quota interacts with region and deployment-type choices, see choosing an Azure region; for the cross-platform view, quotas and limits.

Sources