The PTU Math Trap: When to Pivot from Pay-As-You-Go
to Provisioned Throughput
The two ways teams get PTU wrong are symmetric and equally expensive. Some commit too early — a big number impressed the CFO, so they buy 100 PTUs and run them at 22% average utilisation, paying more than pay-as-you-go would have cost. Others stay on pay-as-you-go long past the point where a monthly reservation would have cut the bill by two-thirds. The way you avoid both is not with a spreadsheet full of guesses. It is with 30 days of real telemetry and one honest formula.
# Two invoices that both represent a PTU decision made without the math:
# ─────── INVOICE A — committed too early ────────────
# Team bought 100 PTUs (GPT-4o Global) on a 1-year reservation "to save money."
# Actual traffic never came close to sustaining the capacity.
PTU reservation (100 × ~$0.30/hr × 730h × 12mo) $ 262,800 / year
Actual token volume served (billed to reservation) ~ 65% of capacity
↑
If purchased PAYG at REAL usage:
~ $ 168,000 / year
OVERSPEND: $ 94,800 / year (~57%)
# ─────── INVOICE B — stayed on PAYG too long ──────
# Steady 300M tokens/month on GPT-4o. Team "wasn't ready" for a commitment.
Pay-As-You-Go (300M tokens/mo, mixed input/output) $ 22,500 / month
Same workload on 25 PTUs @ monthly reservation
(25 × ~$0.36/hr × 730h) $ 6,570 / month
↑
UNDERSPEND OPPORTUNITY:
~ $ 15,930 / month left on the table
# The number the calculator won't tell you unless you ask it correctly:
Actual break-even is NOT "150M tokens/month." It is the intersection of
effective_TPM, output/input ratio, cache rate, and sustained utilisation.
Fix any one of those wrong and the answer is off by 40-60%.Symptom: The finance conversation reduces to "does PTU pay off?" — and either answer, chosen without data, is expensive. Failure point: Teams reach for a break-even number from a blog post, apply it to their workload without measuring, and buy the wrong amount of capacity in the wrong direction. Default platform behaviour: Azure will happily sell you 500 PTUs today, and it will also happily keep charging you PAYG at scale forever. Neither the portal nor billing will tell you which one is right for you.
APTU is not the discount voucher a lot of teams think it is. It is a capacity reservation with a shape — model, region, deployment scope, term — and its financial value depends entirely on how much of that capacity you actually use. Buy 100 PTUs and run them at 25% utilisation, and you have paid four times the effective rate you would have paid on PAYG for the tokens you actually consumed. Sit on PAYG at 300 million steady monthly tokens, and you are paying full retail for a workload the platform is offering you at a two-thirds discount if you would just commit. The mistake is symmetric: assuming that "PTU saves money" is a claim about PTU rather than a claim about your utilisation. The number that makes PTU cheaper than PAYG is not the reservation discount. It is your sustained utilisation of the capacity you bought, and the only way to know it is to measure it — for 30 days, on real production traffic, before you sign anything.
You have probably seen the claim that PTU breaks even at somewhere around 150–200 million GPT-4o tokens per month. That number circulates for a reason — it approximates a common case reasonably well — but shipped as an answer it is dangerous, because it is not what actually determines the answer. It is an output of the real formula, not the formula itself. Apply it to a workload whose shape differs from the implicit assumptions behind it and you will over-commit or under-commit by 40–60%.
Three assumptions hide inside that "150M tokens" number, and any one of them being different for you changes the answer materially:
- The utilisation assumption. The 150M figure typically assumes you sustain roughly 50%+ utilisation of whatever capacity you reserve. A workload that peaks at 300M tokens/month but averages 40M is not a "300M workload" for PTU purposes — it is a 40M workload with peaks that need to spill.
- The output/input mix assumption. PTU capacity accounts for the fact that output tokens are more expensive to generate than input tokens. Microsoft's own documentation is explicit: for GPT-5, one output token counts as eight input tokens toward your utilisation limit. For GPT-4.1, four. Older ratios differ. A summarisation workload (heavy output) is far more PTU-hungry per raw token than a classification workload (tiny output).
- The reservation term assumption. "PTU cheaper than PAYG" is one question. "Which PTU option is cheapest" is another. The break-even utilisation for hourly-no-commitment is much higher than for a monthly reservation, which is higher than for annual. The commercial term you pick is a variable, not a constant.
The 150–200M figure is fine to use as a first-pass sniff test — if you are at 20M tokens/month you almost certainly don't need to run this analysis, and if you are at 2 billion you almost certainly do. Everywhere in between, the honest answer is measure. Do not sign a 12-month commitment because a blog post said the break-even was in your neighbourhood.
Behind the break-even question is one simple economic identity — but its inputs are not the ones people usually pull. You need three measured numbers from real production traffic, not one estimate from a calculator.
| Number | What it is | Why it matters |
|---|---|---|
| Effective TPM | Input TPM + (output TPM × output-to-input ratio) − cached input TPM | The load on the model, in the same currency PTU is priced in. Not "tokens sent," but capacity consumed |
| P95 hourly TPM | The 95th percentile of your hour-by-hour effective TPM over the trailing 30 days | What PTU has to be sized to cover if you want the workload to fit inside it. Sizing to the mean means 5% of hours will burst out |
| Sustained utilisation | Average effective TPM ÷ P95 effective TPM | The variable that determines whether PTU pays. Peak-to-average matters more than absolute volume |
Notice what is not on this list: total monthly tokens. It is a lagging summary, and it hides the shape of the traffic — a 300M-token workload with a 5:1 peak-to-average ratio is a completely different PTU problem than a 300M-token workload with a 1.3:1 ratio.
This is the correction that most naive PTU sizings get wrong, and it comes straight from Microsoft's own sizing documentation. Each model has an output-to-input ratio that expresses how much more processing an output token requires. For GPT-5 the ratio is 8:1 — one output token counts as eight input tokens toward your utilisation limit, matching the pricing ratio. For GPT-4.1 it is 4:1. For Llama-3.3-70B, 4:1 (non-standard vs its price ratio). If you compute PTU size from "average tokens per minute" without normalising output tokens to their equivalent input tokens, you will undersize your deployment by a factor equal to the ratio for a heavily output-bound workload — and get throttled at exactly the moment you needed the capacity. Cached input tokens, on the other hand, are deducted 100% from utilisation, so a high cache rate can materially reduce the PTUs you need.
PTU no longer requires a 30-day minimum commitment — that changed in early 2025. You can now spin a provisioned deployment up on an hourly, no-commitment basis to run a benchmarking script this afternoon, and tear it down when you are done. This is genuinely useful, and it is also the setting most likely to cost you money if you leave it in place.
| Commercial option | Term | Savings vs hourly | Use for |
|---|---|---|---|
| Hourly, no commitment | Per hour | Baseline (0%) | Benchmarking, region migrations, short-lived campaigns, spike absorption |
| 1-month reservation | 30 days | Up to ~64% | Steady baseline workloads, quarter-by-quarter budget reviews |
| 1-year reservation | 365 days | Up to ~70% | Deeply predictable baselines with 12+ month confidence, mature production |
Two features of the current reservation model make the math cleaner than it was in 2024. Reservations are model-independent within a region and scope, so if you buy 500 PTUs of Global reservation you can freely allocate them across GPT-4o, GPT-5, DeepSeek-R1, and Llama-3.3 as your workload mix shifts. And the reservation and the deployment are decoupled — you can create your deployments first and buy the reservation to match them, which sidesteps the "committed to capacity that isn't available" trap.
Microsoft's own guidance is direct on this: the best practice is to always purchase the reservation after the deployments have been created. Otherwise you can end up owning a reservation for PTUs you cannot deploy — because capacity for your model, region and deployment type isn't currently available — and reservation over-purchase credits are limited. Reservations across Global, Data Zone, and Regional scopes are not interchangeable either. Match your reservation to the actual shape of your live deployments, then buy the term.
Global Provisioned routes across all Azure regions and has the lowest PTU minimum (15 for GPT-4o). Data Zone Provisioned keeps processing within a geographic zone (EU/US) for a residency compromise. Regional Provisioned pins to one region and has the highest minimum (50 for GPT-4o, scale in 50s). Quota is separate per scope — Global quota doesn't help you deploy Regional PTUs, and reservations for one don't apply to another. Choose the scope on residency and availability grounds first; the price and minimum implications follow.
Architectural Topology: Failing vs Remediated
| Layer | Failing configuration (current) | Remediated configuration (fix) |
|---|---|---|
| Decision input | "How many tokens per month?" (a summary) | 30-day P95 hourly effective TPM + sustained utilisation ratio |
| Token accounting | Raw input + raw output added naively | Input + (output × ratio) − cached input — the effective TPM |
| Sizing target | Sized to peak (over-provisioned) or mean (under-provisioned) | Sized to P95 baseline; peaks spill to PAYG |
| Commercial term | Chosen upfront on gut feel — often hourly OR jumped to annual | Chosen against measured utilisation for each term's break-even |
| Purchase order | Buy reservation first, then figure out deployment | Deploy first, prove capacity is available, then buy reservation |
| Deployment scope | Global by default without thinking about residency | Chosen deliberately on residency and PTU-minimum grounds |
| Burst handling | Requests hitting 429 when PTU exhausted; no fallback | Spillover to standard deployment on exhaustion — no user-visible failure |
| Review cadence | "Set and forget" until next year's budget cycle | Monthly re-check of utilisation; annual re-check of term |
Everything downstream — the formula, the reservation term, the scope, the hybrid architecture — depends on this measurement. Skip it and you are guessing, no matter how good the spreadsheet is.
The metrics you need
Two Azure Monitor metrics on your Azure OpenAI resource give you the raw data. Both are free to enable through diagnostic settings.
| Metric | What it tells you | Aggregation |
|---|---|---|
| ProcessedPromptTokens | Input tokens consumed per request (per model deployment) | Sum, per 5-minute bin |
| GeneratedCompletionTokens | Output tokens generated per request (per model deployment) | Sum, per 5-minute bin |
| Provisioned-Managed Utilization V2 | Actual PTU utilisation % (only if you have a provisioned deployment running) | Max, per minute |
The three numbers this query returns — mean_tpm, p95_tpm, and sustained_utilisation — are the entire input to the break-even question. If sustained_utilisation is below ~35%, the workload is too spiky for any reservation term to pay off cleanly; stay on PAYG or model a much smaller PTU baseline with spillover. If it is above ~50%, a monthly reservation almost certainly wins. If it is above ~70% and you have 12 months of confidence, annual is on the table. These are directional; the exact break-even follows in Section 6.
The temptation is to run a benchmark script for a day and extrapolate. Don't. Real production traffic has weekday/weekend seasonality, business-hour peaks, campaign spikes, and slow overnight drift that no synthetic loader will reproduce. The whole point of the 30-day window is to include a full seasonality cycle. If you don't have 30 days of PAYG data yet, run PAYG for 30 days first, then revisit this decision. This is the most-repeated advice from practitioners who have made the wrong PTU call: it is faster and cheaper to wait a month than to undo a bad reservation.
Here is the whole thing. Not "150M tokens/month" — the actual comparison, in four terms, that you can plug your measured numbers into and get a defensible answer.
A worked example — Python, real numbers, one paste
This is the calculation you actually run. Feed it your three measured numbers plus current published rates from the Azure OpenAI pricing page, and it prints a defensible recommendation for each reservation term.
The two numbers to be most careful about: output_to_input_ratio and tpm_per_ptu. Both come from Microsoft's model-specific sizing tables (currently at learn.microsoft.com/azure/foundry/openai/how-to/provisioned-throughput-sizing). For GPT-4o the tiering rule is different from GPT-4.1 and later, so the ratio you use for the older model is not the same. Do not copy these values across models. Use the Foundry portal's capacity calculator as your source of truth for the model+scope you plan to deploy on — it is authoritative in a way that a blog post cannot be.
Before you even look at the dollar output of the calculator, glance at the sustained_utilisation number. Under ~35% and no reservation is going to pay off — the workload is too spiky, and the reserved capacity will sit idle. Above ~50% and monthly is almost certainly winning. Above ~70% with year-long confidence, annual is worth modelling. If your dollar output disagrees with your utilisation intuition, one of your inputs — most often the output-to-input ratio or TPM-per-PTU — is wrong. Trust the utilisation ratio.