Most quota increase requests are unnecessary, and the ones that are necessary get approved on evidence of existing usage. Both facts point at the same first step, and it is not opening the form.
Quota is now a tier, not a request
Microsoft replaced the old two-level scheme — a “Default” allocation and an “Enterprise” one, with a large gap and a slow process between them — with quota tiers. Its quotas and limits article, dated 2026-05-27 at the time of writing, describes a Free Tier plus Tiers 1 through 6, with each tier publishing an explicit RPM and TPM figure per model and per deployment type. Your starting tier is set from your existing consumption and your commercial relationship with Microsoft, and Microsoft states that tiers upgrade automatically as sustained usage grows.
That changes what the request is for. It is no longer the only route to more throughput; it is the exception route for when the automatic upgrade has not caught up with a step change you are about to make. Microsoft also documents that an approved request leaves your tier unchanged and simply assigns more quota on top.
You can read your current tier from the control plane rather than guessing at it:
az rest --method get \
--url "https://management.azure.com/subscriptions/$SUB_ID/providers/Microsoft.CognitiveServices/quotaTiers?api-version=2025-10-01-preview"
That API version is a preview at the time of writing and the tier tables are quoted from Microsoft’s quotas and limits article. Both the version string and the per-tier numbers are expected to move; read them from the API and the article rather than from any third-party page, including this one.
Measure what you have first
There are two different questions and two different APIs, and conflating them is why people request quota they already own. The Usages API answers “how much of my quota have I consumed against my limit”, scoped to a subscription and a region:
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.CognitiveServices/locations/{location}/usages?api-version=2024-10-01
Each entry carries a name.value in the form Provider.DeploymentType.Model — for example OpenAI.Standard.gpt-4o — along with currentValue and limit. Those quota line names are what you should paste into a support conversation, because they are unambiguous in a way that “our GPT quota in Europe” is not. Note that the limit is expressed in thousands of tokens per minute, matching the capacity field on a deployment.
Viewing any of this needs a role. Microsoft documents Cognitive Services Usages Reader as the minimal one, and notes that it only exists at subscription scope — assigning it on the resource does nothing. A developer who can call the model but cannot see the quota page almost always has the resource-scoped roles and not this one.
Rebalance before you ask
Because quota is a regional pool rather than a per-deployment grant, the fastest fix is usually redistribution. Microsoft’s worked example: with 240,000 TPM of quota for a model in East US you can run one 240K deployment, two 120K deployments, or any split across any number of resources so long as the total stays under 240K. Lowering the capacity on a staging deployment frees that capacity for production the moment the change lands.
- List every deployment of the model in the region, not just the ones you think are live. Old evaluation deployments are the usual culprit.
- Reduce
sku.capacityon anything not carrying production traffic. This is an update to the deployment, not a delete, so the endpoint keeps working at the lower rate. - Allow up to 15 minutes for the change to propagate — Microsoft documents that window explicitly — then re-read the Usages API before concluding it did not work.
- Only if the pool is genuinely exhausted, open the request form.
The request form
Microsoft routes all of this through one form at aka.ms/oai/stuquotarequest, which is also linked from the Quota page in the Foundry portal. It covers models sold directly by Azure, Azure OpenAI models and Anthropic models; Microsoft states that other partner and community models do not support quota increases at all, which is worth knowing before you spend an afternoon on the form.
What it wants is the capacity arithmetic, not a business case. Bring the subscription ID, the region, the exact model and deployment type, your current TPM allocation, and the TPM you are asking for — with the peak requests per minute, average prompt size and average response size that produce it. That last triple is the same input the provisioned sizing calculation uses, so if you have already worked out whether provisioned throughput is cheaper for your volume, you have already done this part.
The prioritisation rule is stated plainly in Microsoft’s docs and it is the single most useful thing to know about the queue: requests are processed in the order received, and priority goes to customers actively using their existing allocation. Requests that do not meet that condition may be denied. A subscription sitting at 5% utilisation asking for a tenfold increase is asking the wrong question; raise the load against the current allocation first, then ask.
Approval is not the end of the exercise, and this is where another day goes. An increase raises the subscription’s regional pool; it does not touch any existing deployment. The new headroom does nothing until you raise sku.capacity on the deployment that is actually being throttled, which is a separate change with its own propagation window. A team that receives the approval mail, redeploys nothing and keeps seeing identical 429s has hit exactly that, and the evidence is visible in the Usages API: the limit has moved and currentValue has not.
Quota is not capacity
One distinction survives the whole process. Quota is a policy limit — the maximum you are permitted to deploy — and it costs nothing. Capacity is the physical serving capability that actually exists in a region right now. Microsoft is explicit that having quota does not guarantee capacity, and that a deployment can fail for lack of capacity while your quota page shows plenty of headroom.
The Model Capacities API answers the capacity question across every region at once, which makes it the right pre-flight check before a scale-up or a regional move:
GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.CognitiveServices/modelCapacities?api-version=2024-10-01&modelFormat=OpenAI&modelName=gpt-4o&modelVersion=2024-08-06
It returns availableCapacity per location and skuName. Microsoft warns that both this API and the Usages API still return entries for retired models that can no longer be deployed, so a non-zero number against a model you have not checked the retirement date for is not the confirmation it appears to be. That interacts directly with how model versions differ between regions.
Top comments (0)