HTTP 429 (no_capacity) on GPT-5.1 Deployment Despite Available Rate Limits in Sweden Central

Description

We are experiencing intermittent HTTP 429 responses from an Azure AI Foundry endpoint serving GPT-5.1 (gpt-5.1-2025-11-13) in the Sweden Central region.

The issue does not appear to be related to request rate limits or token quota exhaustion. Response headers indicate that substantial request and token quota remains available when the error occurs.

Successful Response Headers

x-ms-served-model: gpt-5.1-2025-11-13

x-ms-region: Sweden Central

x-ratelimit-limit-requests: 90000

x-ratelimit-remaining-requests: 89999

x-ratelimit-limit-tokens: 9000000

x-ratelimit-remaining-tokens: 8999797

Failed Response Headers

x-ms-region: Sweden Central

x-ratelimit-limit-requests: 90000

x-ratelimit-remaining-requests: 89999

x-ratelimit-limit-tokens: 9000000

x-ratelimit-remaining-tokens: 8999991

Retry-After: 30

Error Response

{

  "error": {

    "message": "The system is currently experiencing high demand and cannot process your request. Your request exceeds the maximum usage size allowed during peak load. For improved capacity reliability, consider switching to Provisioned Throughput.",

    "type": "too_many_requests",

    "param": null,

    "code": "no_capacity"

  }

}

Observations

• Resource Health reports the resource as healthy.
• No Azure Service Health incidents were observed during the impacted timeframe.
• Activity Logs show no recent deployment, configuration, or quota changes.
• The service returns Retry-After: 30, indicating a temporary service-side limitation.
• Request and token quotas remain largely unused when the error occurs.
• The error returned is too_many_requests with code: no_capacity.

Based on the available evidence, this does not appear to be a TPM/RPM exhaustion issue. Instead, it appears to be related to temporary service-side capacity constraints.

Questions

1. Can Microsoft confirm whether there were any model-level or regional capacity constraints affecting GPT-5.1 (gpt-5.1-2025-11-13) in Sweden Central during the impacted timeframe?
2. Is the no_capacity error expected even when request and token quotas remain largely available?
3. Are there any known backend throttling mechanisms, regional capacity limitations, or temporary service-side restrictions that could cause this behavior?
4. Is Provisioned Throughput the recommended mitigation for PAYG deployments receiving 429 no_capacity responses, or are there alternative recommendations?

Impact

The application receives HTTP 429 responses despite having substantial remaining request and token quota. This affects workload reliability and makes it difficult to distinguish between customer-side rate limiting and service-side capacity constraints.