Azure OpenAI Pricing: PAYG vs. PTU

Part of a series on running AI workflows across model providers — this one is about two pricing shapes that punish the wrong workload in opposite directions.

Azure AI's pricing splits into two genuinely different models, and picking the wrong one for a given workload can mean paying substantially more than necessary — in either direction. Understanding when each one actually makes sense is worth more than memorizing specific rate numbers, which change over time anyway.

Pay-as-you-go: the default

Standard pay-as-you-go billing charges separately for input and output tokens, functioning essentially the same way the direct OpenAI API does — you pay for exactly what you use, with no commitment and no minimum. This is the right default for anything with variable, unpredictable, or low-to-moderate volume: a new feature still finding its usage pattern, an internal tool with irregular traffic, or anything still in the experimentation phase.

Provisioned Throughput Units: reserved capacity

Provisioned Throughput Units (PTUs) work completely differently: you reserve a fixed amount of model processing capacity and pay an hourly rate for it, regardless of whether you actually use all of it. There are minimums — 15 PTUs for Global and Data Zone deployments, 50 PTUs for Regional deployments (25 for smaller "mini" models) — and monthly or annual reservation commitments bring the effective hourly rate down compared to paying hour-by-hour.

Two fundamentally different pricing shapes — one scales with actual usage, the other is a fixed capacity commitment regardless of usage.

The math that actually decides which one is right

PTUs are, in plain terms, a utilization bet. You're betting that your sustained, predictable usage will be high enough, consistently enough, that the fixed hourly cost of reserved capacity comes in below what the equivalent volume would cost on pay-as-you-go token pricing. When that bet is right — genuinely sustained, high-volume, latency-sensitive production traffic — PTUs can meaningfully reduce cost and, just as importantly, guarantee throughput and latency consistency that shared pay-as-you-go capacity doesn't promise as strongly.

When the bet is wrong — bursty, unpredictable, or lower-volume traffic — PTUs mean paying for idle capacity during every quiet hour, which is a straightforwardly bad trade compared to paying only for the tokens actually used.

The core question is whether usage is sustained and predictable enough to make a fixed capacity commitment pay off.

A use case that shows the cost of guessing wrong

A team launching a new customer-facing feature committed to Provisioned Throughput from day one, reasoning that a customer-facing feature "should" get dedicated capacity. Actual usage in the first month was far bursty and lower-volume than projected — heavy during business hours, close to idle overnight and on weekends — meaning a large share of the reserved PTU hours went unused. Switching back to pay-as-you-go for that specific deployment, while keeping a separate, genuinely high-volume internal batch-processing workload on PTUs where the sustained-usage assumption actually held, brought total spend down without touching the batch workload's cost structure at all.

Testing usage patterns before committing

Since the PTU decision hinges entirely on actual usage patterns rather than assumptions, the practical approach is to run a workload on pay-as-you-go first, observe real traffic patterns — including how bursty or how sustained they actually are — and only move to Provisioned Throughput once there's real data supporting the sustained-volume assumption a PTU commitment requires.

Frequently asked questions

Can I mix pricing models across different deployments in the same Azure resource?

Yes — different deployments within the same resource can independently use pay-as-you-go or Provisioned Throughput, matched to that specific deployment's actual usage pattern.

Does DNotifier's sendAI() call behave differently depending on which pricing model a deployment uses?

No — the call shape is identical regardless of the underlying deployment's pricing model. Pricing is entirely an Azure-side configuration, invisible to the application code calling it.

Is Provisioned Throughput ever worth it for a smaller, less certain workload?

Generally not — the whole value proposition depends on sustained, predictable, high volume. A workload without that profile is close to definitionally the wrong fit.

How do I know if my actual usage pattern justifies switching to PTU?

Look at real production data over a meaningful window — weeks, not days — for consistency of volume across peak and off-peak periods, rather than projecting from launch-week or estimated traffic.

The Bottom Line

Next in this series: Azure's built-in content filtering compared honestly against DNotifier's own approach to safety and control.

Read part seven: Azure AI Content Safety vs. DNotifier. Explore dnotifier.com.