Azure OpenAI Pricing Explained: Pay-As-You-Go vs Provisioned Throughput

Azure OpenAI has two basic ways to pay. Standard, or pay-as-you-go, deployments charge per token and give you no reserved capacity, while provisioned deployments charge per provisioned throughput unit (PTU) per hour and hold a fixed amount of processing capacity for you, used or not. The right choice depends on how predictable your traffic is and how much latency consistency is worth to you. This article explains both models, shows the sizing arithmetic from Microsoft's documentation, and gives you a method for comparing cost before you commit.

Who this is for and what you will have

This is for cloud architects, IT managers and finance partners who need to forecast Azure OpenAI spend. By the end you will know how each billing model works, how to estimate PTUs for a workload, how reservations fit in, how spillover protects you from errors, and how to run a break-even comparison with your own prices. Microsoft's pricing page holds the current rates, and they differ by model and deployment type, so this article gives formulas and structure rather than quoting prices that will go out of date.

The deployment categories

Microsoft's documentation groups deployment types into four billing categories:

Within these categories you also choose where data is processed. The deployment types and SKU codes are:

Microsoft recommends starting with Global Standard for most workloads, because it launches first for new models, has the lowest price and the broadest region coverage. Move to another type only for a specific reason such as data residency, reserved throughput or batch processing. For the full comparison of types, see Azure OpenAI deployment types compared.

How pay-as-you-go billing works

With standard deployment types you pay for the tokens you use. Cost scales linearly with volume and drops to zero when you send nothing. The trade-offs are that capacity is shared across customers, throughput and latency can vary with demand, and large steady workloads can see greater latency variability. Microsoft's documentation says customers with high consistent volume on Global Standard and Data Zone Standard might experience greater latency variability, and points them to provisioned deployments for low variance at scale.

Standard deployments are also where you will meet rate limits. If you are seeing throttling on a pay-as-you-go deployment, see fixing Azure OpenAI 429 rate limit errors before assuming you need provisioned capacity.

Two ways to lower pay-as-you-go cost without changing the billing model:

• Batch deployments (Global Batch or Data Zone Batch) cost 50 percent less than Global Standard, with a 24-hour target turnaround and no real-time SLA.
• Flex processing is available on Global Standard for lower-cost, delay-tolerant workloads, and priority processing is available for faster responses on a pay-as-you-go basis.

How provisioned throughput billing works

A PTU is a unit of model processing capacity. When you create a provisioned deployment you specify the number of PTUs, and Foundry reserves and holds that capacity for the deployment. Key billing facts from Microsoft's documentation:

• You are billed hourly per PTU deployed, not per token. A 300 PTU deployment is billed at the hourly rate multiplied by 300, whether or not requests are flowing.
• A deployment that exists for part of an hour is prorated. For example, 15 minutes is charged at one quarter of the hourly rate, and resizing a deployment changes billing immediately, prorated to the minute.
• Provisioned deployments cannot be paused. Billing stops only when the deployment is deleted.
• PTUs are model-independent, so the same quota can deploy any supported model.
• PTU quota is granted per subscription, per region and per deployment type, and Global, Data Zone and Regional Provisioned are separate quota pools.
• Each model has a minimum deployment size and a scale increment. For example, for gpt-5.2 the documented minimum for Global and Data Zone Provisioned is 15 PTUs with increments of 5, and for Regional Provisioned the minimum is 50 PTUs with increments of 50.

Quota is not capacity. Microsoft is explicit that having PTU quota does not guarantee that capacity is available, that capacity changes through the day, and that scaling down releases capacity back to the regional pool with no guarantee you can get it back. Deployment creation fails if capacity is insufficient.

Check capacity before you plan

Use the Foundry portal deployment experience, which tells you whether capacity is available and lists alternative regions, or call the model capacities API to query the maximum deployable PTU count for a model and region. You can request more quota through the quota request form, and Microsoft notes approval might take several days.

Step 1: Size the PTUs you need

Microsoft's sizing guidance converts your traffic into a single normalized tokens-per-minute figure. You need peak requests per minute, average prompt size, average response size and the cache rate. The formulas are:

Input TPM        = Peak RPM x average prompt size
Output TPM       = Peak RPM x average response size
Normalized TPM   = (Input TPM x (1 - cache rate)) + (output-to-input ratio x Output TPM)
PTUs required    = Normalized TPM / Input TPM per PTU

The output-to-input ratio and the Input TPM per PTU come from the per-model table in the sizing article. The documentation's worked example uses gpt-5.2 on Data Zone provisioned throughput, with an Input TPM per PTU of 3,400 and an output-to-input ratio of 8:

Notice how much the cache rate matters: cached tokens are deducted from the utilization calculation for models that use that accounting, so a higher cache rate lowers the PTUs you need. Newer models that use normalized token accounting weight cached input and cache writes instead, so check the sizing article for the model you plan to use.

You can also use the capacity calculator in the Foundry portal, on the Quota page. Microsoft advises benchmarking a deployment against representative traffic rather than relying only on estimates, particularly if prompt sizes vary widely.

Step 2: Choose hourly billing or a reservation

Provisioned deployments support two billing modes.

Hourly billing suits short-term work, such as benchmarking a model before committing or temporarily scaling for an event. Microsoft advises against scaling production deployments up and down with traffic to stay on hourly billing, for two reasons: continuous hourly billing at high utilization typically costs more than a reservation, and capacity might not be available when you need to scale back up.

Azure reservations give a discounted effective $/PTU/hour in exchange for a one-month or one-year commitment. Key facts:

• Reservations are a financial discount on the PTU billing meter, not on the deployment itself, and deployments and reservations are loosely coupled.
• They are purchased per deployment type, so a Global Provisioned reservation does not cover a Regional Provisioned deployment.
• A Global reservation is not region-specific and can cover Global PTU deployments across regions, up to the reserved quantity.
• Matching is by deployment type, region (for Data Zone and Regional) and scope, not by model.
• PTUs deployed beyond the reservation quantity are billed at the hourly rate, and reserved PTUs without a matching deployment are unused coverage.
• Cancellation or exchange can incur fees, and exchanges between deployment types are not supported.
• Reservations do not guarantee capacity.

Because of that last point, the order of operations matters: create the deployment first, confirm it works, then buy the reservation. After purchase, open the Reservations page in the Azure portal and check the Utilization (%) value. Below 100 percent means some reserved PTUs are not matched to a running deployment.

Step 3: Add spillover for bursts

Spillover is an optional setting that routes overflow requests from a fully used provisioned deployment to a corresponding standard deployment in the same Foundry resource. When the provisioned deployment returns non-200 responses, such as a 429 when PTUs are exhausted, spillover redirects those requests. It can apply to all requests on a deployment or per request using the x-ms-spillover-deployment header. Microsoft states that Azure OpenAI models that support provisioned throughput also support spillover, while some other providers' models do not currently.

This pattern lets you size PTUs for typical load rather than the rarest peak, and pay per token for the overflow. Test it: overflow requests are served by a standard deployment and will not carry provisioned latency targets.

Step 4: Compare costs with a break-even calculation

Get your actual prices from the Azure OpenAI pricing page or the Azure pricing calculator for the model, deployment type and region you plan to use. Then calculate:

Provisioned monthly cost = PTUs x effective $/PTU/hour x hours in month
Pay-as-you-go monthly cost = (input tokens x input price) + (output tokens x output price)
Break-even utilization = Provisioned monthly cost / Pay-as-you-go cost of the same tokens at 100% utilization

If your realistic average utilization is below the break-even figure, pay-as-you-go is cheaper on price alone.

Microsoft's sizing article includes an illustration for newer models: it assumes one PTU at $260.00 per month, 100 percent sustained utilization and no discounts, and shows provisioned and pay-as-you-go costs come out approximately equal at full utilization. The article labels this a capacity comparison, not a quote. The practical point is that provisioned cost is fixed while pay-as-you-go cost depends on use, so lower utilization raises your effective cost per token under PTUs. If your realistic average utilization is well below what you pay for, pay-as-you-go will be cheaper, and the case for PTUs rests on latency consistency and guaranteed throughput rather than price.

Decision guide

Troubleshooting

Deployment fails with a capacity error. Quota is not capacity. Try fewer PTUs, another region or a Global deployment type, and retry later because availability changes during the day.

You are paying for a provisioned deployment nobody uses. Billing continues until the deployment is deleted. Delete it, and check whether a reservation is now under-utilized.

Utilization is low. Review your sizing inputs, cache rate and traffic shape. Consider reducing PTUs, although scaling down releases capacity you may not get back.

429 responses on a provisioned deployment. PTUs are exhausted. Add PTUs within quota and capacity, reduce request size, raise cache hit rates or configure spillover.

The reservation discount does not appear. Check that deployment type, region and scope match, and that the reservation shows as Active.

Checklist

• Choose a deployment type based on data residency and traffic pattern.
• Start with Global Standard unless a requirement says otherwise.
• Size PTUs with the formula and the capacity calculator, then benchmark.
• Verify capacity before planning and before buying anything.
• Deploy first, reserve second, and check reservation utilization monthly.
• Configure spillover if bursts are expected.
• Use Cost Management to track PTU and reservation costs.

References

• Microsoft Learn, Provisioned throughput for Foundry Models: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/provisioned-throughput
• Microsoft Learn, Provisioned throughput billing and cost management: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/provisioned-throughput-billing
• Microsoft Learn, Determine PTU sizing for a workload: https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/provisioned-throughput-sizing
• Microsoft Learn, Understanding deployment types in Microsoft Foundry Models: https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/deployment-types
• Azure OpenAI pricing: https://azure.microsoft.com/pricing/details/cognitive-services/openai-service/