Quotas, Rate Limits, and What a 429 Is Telling You

What this slice covers

A deployment that works perfectly in testing can fail under load for reasons that have nothing to do with the model. Quota and rate limits are the governors Foundry places around your consumption, and they are enforced independently of whether you can afford the tokens. This note covers what is limited, at what scope, how the recent shift toward subscription-level quota changes the picture, and how to design an application that stays inside the boundaries.

Three things people conflate

Keep these apart, because scenario questions depend on it:

• Cost is what you pay for tokens consumed.
• Quota is the allocation of capacity you are permitted to assign to deployments.
• Rate limits are the per-minute ceilings that throttle traffic in flight.

You can have budget remaining and still be throttled. You can have quota available in one region and none in another. None of the three substitutes for the others.

Where limits are scoped

The first structural fact is negative and easy to get wrong: quotas and limits are not enforced at the tenant level. The highest level of restriction is the Azure subscription. Below that, tokens per minute (TPM) and requests per minute (RPM) limits are defined per region, per subscription, and per model or deployment type.

That compound scoping explains a common puzzle. Two teams in the same tenant but different subscriptions do not compete for quota. Two deployments of the same model in the same subscription and region very much do.

There are also flat resource ceilings to know: 100 Foundry resources per region per subscription, up to 250 projects per resource, and a maximum of 32 model deployments within a Foundry resource.

The shift to subscription-level quota

Foundry has been moving models onto subscription-level quota management, so that quota is tracked for the subscription rather than per resource or per region. Under that model, Global Standard deployments of the same model and version share one quota pool across all regions in the subscription, and Data Zone Standard deployments share a pool per data zone.

The benefit is predictability — every resource and region draws from the same pool — and existing approved quota carries over automatically with no action required. To find out which regime applies to a given model, look at the scope column on the portal's quota page: a value of Global or Data Zone means subscription-level management, while a region name means per-region management for that subscription and model.

The rate limits themselves

Limits vary by model. Azure OpenAI models have their own published figures that differ by model and SKU. Among other models sold by Azure, some large models carry substantially higher ceilings than the general case, and the fallback for the remainder is 400,000 tokens per minute, 1,000 requests per minute, and 300 concurrent requests. Image generation models are limited differently again — by request rate or capacity units rather than tokens.

Increases are requested through a quota increase form, and are evaluated individually. Priority goes to customers already using the allocation they have, so a request from a subscription sitting on idle quota may be declined. Note the asymmetry between the catalogue's two families: apart from Anthropic models, models from partners and community do not support quota increases at all.

Designing to stay inside the limits

The documented practices are unglamorous and effective:

• Implement retry logic. A 429 response means a per-minute limit was exceeded, and the correct handling is exponential backoff honouring the Retry-After header rather than an immediate retry.
• Avoid sudden jumps in workload; ramp up gradually and test different load patterns.
• Rebalance quota between deployments before assuming you need more of it.

Client-side timeouts deserve explicit thought too. Reasoning models can legitimately take up to 29 minutes, because reasoning tokens are generated and summarised before the first response token appears. Non-streaming requests to other models also allow up to 29 minutes, while streaming requests warrant around 60 seconds. Set your timeout below these values, tuned to your traffic — an unset timeout inherits whatever your client library happens to default to.

Mistakes to avoid

• Reading a 429 as a billing or authentication problem. It is a rate limit.
• Assuming quota follows your tenant. It follows the subscription.
• Requesting an increase before using what you already have.
• Retrying immediately on throttling, which deepens the congestion instead of clearing it.
• Expecting a quota increase path for every partner model. Most have none.

What to carry forward

Quota is allocated per subscription and increasingly pooled across regions; rate limits throttle per minute in tokens, requests, and concurrency. Handle 429 with backoff, ramp load gradually, and set timeouts that reflect the model class you are calling.