Compare Azure OpenAI token costs with provisioned capacity
On this page
This check is due for a source refresh. Confirm the current documentation before you rely on provider-specific details.
Keep variable traffic on standard token billing until representative benchmarking and a complete cost comparison justify PTUs. Otherwise, idle deployed capacity is billed per PTU-hour even without requests. For sustained production, evaluate reservations only after deployments confirm available capacity.
What you need first
- Tool
- Use the offline worksheet in a spreadsheet or text editor. For sizing, use the Foundry capacity calculator, a guided PTU estimator, with the linked model-specific sizing guide.
- Access
- Ask authorized Azure billing and deployment colleagues for read-only quantities, agreement-specific rates, deployment sizes, reservation coverage and representative benchmark results for the chosen scope.
- If you do not use that tool
- Give those colleagues the subscription or resource group, deployment names, model/version, deployment type, region or data zone and comparison dates. Request completed worksheet inputs, a model-specific PTU estimate and representative benchmark results.
Why this is worth a look
Skipping this comparison can hide hourly PTU charges during idle periods and term payments for unused reservation coverage. Standard billing separates applicable input, cached-input, cache-write and output meters per million tokens. PTU sizing depends on model, version, deployment type, peak calls, prompt and response sizes, and cache rate, so token volume alone does not validate capacity or performance.
Run this check
CHECKLISTComplete offline from read-only billing and deployment records. Compare one closed billing period with a documented representative workload window. This checklist does not deploy resources or run traffic.
Scope and inputs
[ ] Record subscription/resource group, deployment names, model/version, deployment type, region or data zone, and currency.
[ ] Record comparison-period start/end and representative workload-window start/end.
[ ] Obtain billing quantities and current agreement-specific rates from the billing owner.
[ ] Obtain peak calls/minute, average prompt tokens/request, average response tokens/request, cache rate and representative benchmark results from the deployment owner.
[ ] Stop short of recommending a switch if representative benchmark results are missing.
Standard token cost
[ ] List each applicable pricing category separately: input, cached input, cache writes and output where shown for the exact model row.
[ ] Match quantities to the exact model and deployment-type pricing row. Do not count cached tokens again as ordinary input.
[ ] For each row priced per million tokens, calculate:
category_cost = category_tokens / 1000000 * rate_per_million_tokens
[ ] Sum category costs for the comparison period. Keep other service charges outside this comparison.
Capacity estimate
[ ] Use the Foundry capacity calculator or the sizing guide's current model-specific parameters.
[ ] Apply the model/version and deployment-type minimum PTUs, scale increments and cache accounting rules.
[ ] Compare the estimate with representative benchmark results and required performance. Do not treat an average prompt size as a validated benchmark.
Provisioned cost for the same period
[ ] For hourly-only capacity, calculate each interval with a constant PTU count:
interval_cost = deployed_PTUs * hourly_rate_per_PTU * interval_hours
[ ] Sum all intervals, including hours with no requests.
[ ] For a reservation scenario, record committed PTUs, term and payment commitment attributable to the comparison period, including unused coverage.
[ ] Verify matching deployment type, reservation scope and applicable region rules. Global reservations are not region-specific.
[ ] Include matching deployments that share the reservation when calculating remaining coverage.
[ ] Add hourly charges only for deployed PTUs beyond matching reservation coverage.
Decision record
[ ] Record standard cost, hourly provisioned cost and reservation-scenario cost separately.
[ ] Recommend provisioned capacity only if predictable demand, benchmarked performance and sustained use justify the cost.
[ ] For sustained production, evaluate a reservation rather than long-term hourly billing.
[ ] Do not recommend purchasing a reservation before required deployments are in place and capacity is confirmed.How to confirm it
- 01
Fix scope and gather inputs
Choose one closed billing period and one representative workload window. Ask billing and deployment owners for inputs covering the same model/version and deployment type. Record mismatches before comparing costs.
- 02
Price standard usage by category
Calculate each applicable token category with its matching pricing row and per-million-token unit, then sum the results. Use current agreement-specific rates in one currency, because public prices are estimates rather than quotes.
- 03
Validate the capacity estimate
Run the Foundry capacity calculator with model-specific parameters, then compare its estimate with representative benchmark results and required performance. Pause a switch recommendation when benchmark results are missing.
- 04
Compare idle and committed cost
Include every deployed PTU-hour, including hours without requests, and the payment commitment for unused reservation coverage. For sustained production, evaluate reservations after deployments confirm capacity. Charge hourly only for PTUs beyond matching reservation coverage.
Before making changes
Treat this as a token-versus-capacity comparison, not a total application bill. Assume the workload window represents the period being priced and the benchmark meets required performance. Use current model-specific cache rules. Reservations and deployments are separate: term payments continue for committed PTUs, while unmatched or excess deployed PTUs are charged hourly. Global reservations can span regions, but deployment type and scope must still match.