Microsoft Foundry Models quotas and limits

This article provides a quick reference and detailed description of the quotas and limits for Foundry Models sold by Azure. For quotas and limits specific to the Azure OpenAI in Foundry Models, see Quotas and limits in Azure OpenAI.

Updates to quota management after 05/07/2026

Microsoft Foundry is introducing an update to quota management to bring consistency and predictability to how quota is managed across deployments. Starting with Realtime Translate and Realtime Whisper, quota for deployments is tracked at the subscription level—shared across all resources and regions—rather than being allocated separately per resource or per region.

This change consolidates quota into shared pools:

• Global Standard: Deployments of the same model and version share one quota pool across all regions in a subscription.
• Data Zone Standard: Deployments of the same model and version share one quota pool per data zone (for example, US or EU).

What’s changing for me?

For the models that are onboarded the new quota management system:

• All Global Standard deployments of the same model and version under a subscription now draw from a single shared quota pool across all regions.
• All Data Zone Standard deployments of the same model and version under a subscription now draw from a shared quota pool within each data zone.
• Existing approved quota is retained and automatically applies at the subscription level—no action required.

This consolidation allows Microsoft Foundry to offer supported models consistently across all Foundry regions, regardless of how quota is distributed across resources or regions.

Quotas and limits reference

The following sections provide a quick guide to the default quotas and limits that apply to Foundry Models. Quotas and limits aren't enforced at the tenant level. Instead, the highest level of quota restrictions is scoped at the Azure subscription level. Tokens per minute (TPM) and requests per minute (RPM) limits are defined per region, per subscription, and per model or deployment type.

Resource limits (per Azure subscription, per region)

Rate limits

The following table lists limits for Foundry Models for the following rates:

• Tokens per minute
• Requests per minute
• Concurrent request

To increase your quota:

• For Azure OpenAI, use Foundry Service: Request for Quota Increase to submit your request.
• For other models, see request increases to the default limits.

Due to high demand, limit increase requests are evaluated individually.

Other limits

1 Current APIs allow up to 10 custom headers, which the pipeline passes through and returns. If you exceed this header count, your request results in an HTTP 431 error. To resolve this error, reduce the header volume. Future API versions won't pass through custom headers. Don't depend on custom headers in future system architectures.

Usage tiers

Global Standard deployments use Azure's global infrastructure to dynamically route customer traffic to the data center with best availability for the customer's inference requests. This infrastructure enables more consistent latency for customers with low to medium levels of traffic. Customers with high sustained levels of usage might see more variabilities in response latency.

The Usage Limit determines the level of usage above which customers might see larger variability in response latency. A customer's usage is defined per model and is the total tokens consumed across all deployments in all subscriptions in all regions for a given tenant.

Request increases to the default limits

Submit the quota increase request form to request quota increases for Foundry Models sold by Azure, Azure OpenAI models, and Anthropic models. Except for Anthropic models, Models from partners and community don't support quota increases.

Quota increase requests are processed in the order they're received, and priority goes to customers who actively use their existing quota allocation. Requests that don't meet this condition might be denied.

General best practices to stay within rate limits

To minimize issues related to rate limits, use the following techniques:

• Implement retry logic in your application.
• Avoid sharp changes in the workload. Increase the workload gradually.
• Test different load increase patterns.
• Increase the quota assigned to your deployment. Move quota from another deployment, if necessary.

Setting client-side timeout

Set the client-side timeout explicitly based on the following guidance.

• Reasoning models (models that generate intermediate reasoning tokens before producing a summarized response): up to 29 minutes.
• Non-reasoning models:
  • For streaming, up to 60 seconds.
  • For non-streaming requests, up to 29 minutes.

29 minutes here doesn't mean all requests take 29 minutes but rather depending on context tokens, generated tokens, and cache hit rates, requests can take up to 29 minutes.

Set a timeout that's less than these values, tuned to your traffic patterns.

For reasoning models including streaming requests, all the reasoning tokens are first generated and then summarized before sending the first response token back to the user.

You can modify the reasoning effort parameter to control the number of reasoning tokens generated in the process.

Troubleshooting

Related content

• Models available in Foundry Models
• Manage and increase quotas for Foundry resources
• Quotas and limits in Azure OpenAI