Intermittent no_capacity errors with GPT-6.1 Sol on Azure OpenAI Global Standard

I am getting this as well. is it something to do with the pricing tier you are on?

Hello @Sam Macbeth ,

Thank you for providing the exact timestamps, model version, deployment type, quota allocation, request size, and the tests you performed with a lower maximum output-token value.

The symptoms you reported on October 19, 2026, between approximately 05:20 and 05:55 UK time, are consistent with a temporary service-side capacity event affecting this model and the Global Standard deployment type. The event was mitigated. If the same no_capacity errors continue outside that window, they should be investigated as a new occurrence rather than assumed to be part of the same event.

Quota versus runtime capacity

Your assigned 150,000 TPM and 150 RPM define the deployment’s quota and request-admission envelope. However, they do not guarantee that every request can be served at every moment on a Standard deployment.

Microsoft documents that Standard inference capacity is shared and that assigned quota only partially determines achievable throughput. Quota participates in admission logic, while actual throughput can vary with the model and version, request shape, input and output sizes, per-call latency, and current system demand.

Therefore, the no_capacity message should not be interpreted as exhausted customer TPM or RPM quota unless the usage and rate-limit metrics support that conclusion. A capacity-related HTTP 429 is distinct from a normal rate_limit_exceeded response caused by exceeding the deployment’s TPM or RPM.

Why similar requests can produce different outcomes

With shared Standard capacity, each request is evaluated when it arrives. A request may be admitted when processing capacity is available and rejected later when service demand has changed, even if its apparent size is similar.

Also verify the actual token count of each request. In a multi-turn conversation, earlier messages are commonly included in later calls, so the effective prompt can grow even when the latest user message is unchanged.

Microsoft does not currently publish a guaranteed “safe” prompt size or maximum-output-token threshold that prevents no_capacity for this model. The applicable context-window limit is model-specific, but remaining below that limit does not guarantee admission during transient capacity pressure.

Bounding the output-token parameter to the application’s realistic requirement is still recommended. Azure OpenAI uses the requested maximum generation size when estimating tokens for admission and rate limiting. Depending on the API and model, the applicable parameter may be max_tokens, max_completion_tokens, or max_output_tokens, so please verify the parameter supported by the API operation you are using.

Reducing an unnecessarily high maximum output value and trimming unneeded conversation history can lower request demand, but these are optimizations rather than guaranteed workarounds for a service-side capacity event.

Streaming

Streaming can improve perceived responsiveness by returning generated output incrementally. It does not reduce total generation work or correct an admission-time no_capacity rejection. If a request is rejected before inference begins, enabling streaming will not make that request succeed.

Recommended production handling

For a customer-facing application, I recommend implementing the following layers:

Bounded retry handling

• Honor Retry-After or retry-after-ms when returned.
• Otherwise, use exponential backoff with randomized jitter.
• Limit retries by both attempt count and an overall retry-time budget.
• Avoid immediate or synchronized retries from multiple application instances.
• After the retry budget is exhausted, use a circuit breaker and return a clear temporary-unavailability message.

Diagnostics and monitoring

• Log the UTC timestamp, HTTP status, Azure OpenAI error code, request or correlation ID, deployment name, model version, and deployment type.
• Record approximate input tokens and the configured maximum output tokens without logging confidential prompt content.
• Monitor Azure OpenAI Requests, Processed Prompt Tokens, Generated Completion Tokens, and relevant 429/error metrics.
• Track errors separately by deployment, model version, and error code so that quota throttling and no_capacity events are not combined.

Workload controls

• Keep conversation history and requested output bounded to actual application requirements.
• Load-test representative multi-turn conversations, concurrency, and bursts rather than testing only isolated prompts.
• Consider an application-level fallback deployment or model where quality, data-residency, and compliance requirements permit it.
• Retries improve resilience during transient pressure, but they are not a capacity guarantee and might not succeed during sustained exhaustion.

Would another region or deployment type help?

Moving the Azure resource or recreating the deployment in another region should not be presented as a guaranteed fix. Global Standard can process inference globally, subject to the deployment’s data-processing rules, so the Azure resource’s East US location does not by itself establish the processing location for every request.

Global Standard, Data Zone Standard, geography-based Standard, Priority Processing, and Provisioned Throughput have different availability, residency, cost, latency, and capacity characteristics. Availability is model-and-version specific. Before changing the deployment, confirm which options are currently offered for GPT-6.1 Sol version 2026-09-29 in the Microsoft Foundry model catalog.

Current public Priority Processing documentation does not list this exact GPT-6.1 Sol version among the documented supported models. It should therefore not be recommended for this deployment without verifying support in the model catalog.

When to evaluate Provisioned Throughput

Provisioned Throughput is appropriate to evaluate when predictable processing capacity and latency are important enough to justify capacity planning and PTU-based cost. Unlike Standard deployments, which use shared processing capacity, a provisioned deployment allocates fixed model-processing capacity for that deployment.

However:

• PTU quota and deployable capacity are separate. Having PTU quota does not itself guarantee that capacity is available for a new deployment.
• The workload must be sized using request rate, input tokens, output tokens, and prompt-cache behavior.
• Provisioned deployments are billed per PTU per hour or through an Azure reservation.
• The model version, deployment type, and regional availability must be verified before making this change.
• PTU improves capacity predictability but does not mean an application can omit retry, overload, and failover handling.

If the issue continues

If no_capacity errors continue after the October 19 event or materially affect production:

1. Review Azure Service Health for the affected subscription.
2. Capture UTC timestamps and request/correlation IDs for failed calls.
3. Record the complete HTTP status, error code, and error message.
4. Record the deployment name, model version, deployment type, and Azure resource region.
5. Record approximate input tokens, the configured maximum output-token value, and whether the same request succeeds after a delayed retry.
6. Check TPM, RPM, request, prompt-token, completion-token, and error metrics around the failure window.
7. Open an Azure Support request so the service team can correlate the failures with platform telemetry.

Please do not publish subscription IDs, resource names, API keys, customer prompts, or confidential payloads in Microsoft Q&A. Provide sensitive identifiers privately through the Azure Support request.

Microsoft documentation:

• Azure OpenAI performance and latency
• Manage Azure OpenAI quota
• Azure OpenAI quotas and limits
• Azure OpenAI 429 handling guidance
• Provisioned Throughput concepts
• Operate Provisioned Throughput deployments
• Microsoft Foundry deployment types
• Azure OpenAI monitoring metrics
• Priority Processing availability

Hello @Sam Macbeth

I wanted to follow up and check whether you had a chance to review the response above. Please let me know if you have any further questions or need additional clarification.

Thank you