Research-backed calculator guide

Azure OpenAI PTU Spillover Budget: 429s to PAYG

Calculate Azure OpenAI PTU spillover cost from 429-triggered PAYG attempts, retries, token mix, and the break-even point for adding PTUs.

PAYG spillover cost
= spillover attempts × (
    input tokens / 1,000,000 × input rate
  + cached tokens / 1,000,000 × cached-input rate
  + output tokens / 1,000,000 × output rate
)

PTU cost
= deployed PTUs × PTU $/hour × hours in the period

break-even attempts for more PTUs
= marginal PTU cost / PAYG cost per spillover attempt

This denominator matters. One customer task can produce an initial attempt and one or more retries. If a retry reaches the standard deployment, its tokens belong in the spillover budget even if your application later deduplicates the answer. Do not assume that a logical request and a billed provider attempt are the same event.

!Azure OpenAI PTU spillover cost inputs and outputs

What Azure spillover changes in the bill

A provisioned deployment reserves model-processing capacity. Microsoft describes PTUs as a fixed allocation and says provisioned deployments are billed per PTU per hour, or through a reservation, regardless of token consumption. Standard deployments use pay-as-you-go token billing. ^{[2] [4]} That means enabling spillover does not turn the PTU invoice into a per-request invoice. Instead, it adds a second cost path for the fraction of traffic that leaves the provisioned deployment.

The spillover documentation requires a matching standard deployment in the same Foundry resource. It supports enabling spillover for all requests or naming the target with the x-ms-spillover-deployment request header. When spillover occurs, response headers identify the source PTU deployment, the standard deployment that served the request, and the error that triggered the route. ^[1] Those headers are important for finance: they let you reconcile the standard deployment’s token usage to the originating PTU deployment instead of treating all PAYG traffic as ordinary traffic.

A 429 from exhausted PTU capacity is not the only trigger described by Microsoft. The service can also route selected non-200 outcomes such as certain long-context 400 responses and 500 or 503 server errors. ^[1] Therefore, a budget called “429 overflow” can understate the actual standard-deployment spend unless the ledger records the trigger code. Keep at least these dimensions: PTU deployment, standard deployment, model version, trigger status, IsSpillover, input tokens, cached tokens, output tokens, and request or attempt ID.

Spillover is a resilience and capacity policy, not a free retry service. Microsoft’s technical blog states that PTU-served requests incur the fixed hourly charge, while requests routed to standard incur input, cached, and output token charges. It also notes that standard capacity can be congested and can compete with other applications. ^[5] Your cost model should therefore carry both dollars and service outcomes: the cheapest overflow route may still violate a latency or availability target.

The cost denominator: completed tasks, requests, and attempts

Start with the business unit your finance or product team cares about. It might be a completed chat turn, an agent run, or a document processed. Then translate it into provider attempts.

Suppose 100,000 customer tasks are submitted in a month. A 4% application retry rate does not automatically mean 104,000 billable spillover attempts. Some retries may be rejected before reaching Azure, some may run on PTU, and some may reach standard. The useful quantity is:

spillover attempts
= attempts whose serving deployment is the standard spillover deployment

Use the x-ms-spillover-from-deployment response header and the standard-deployment token usage to identify those attempts. ^[1] If your gateway retries after a timeout, assign an idempotency or attempt key before the first call. Record the provider usage for every attempt. Then report at least two unit costs:

cost per spillover attempt = spillover dollars / spillover attempts
cost per completed task = all related spillover dollars / completed tasks

The second metric can be higher when retries, partial failures, or multiple model calls are needed for one outcome. It is the safer number for product margin. The first metric is the safer number for comparing the overflow route with adding a PTU block.

Do not call a failed first attempt “free” merely because the user never saw its output. Whether it generated billable tokens depends on where it was served and what the provider usage record says. This article uses a conservative accounting rule: include every standard-deployment attempt with recorded input, cached, or output tokens; separately investigate attempts with no usage record.

Worked cost example

Assume a Global Provisioned deployment has 20 PTUs and a standard deployment receives overflow. The following is an illustrative scenario, not a Microsoft quote. The Azure pricing page warns that displayed prices are estimates and can vary with agreement, date, currency, and other commercial terms. ^[4] Use the rate record on your own invoice or contract before making a purchase decision.

Assumptions for one standard-deployment spillover attempt:

• 2,400 new input tokens.
• 600 cached-input tokens.
• 1,200 output tokens.
• PAYG rates assumed for the example: $3.00 per 1 million new input tokens, $0.30 per 1 million cached-input tokens, and $12.00 per 1 million output tokens.
• PTU hourly rate assumed for the example: $1.00 per PTU-hour.
• 730 hours in the month.
• The marginal capacity decision is an additional 5 PTUs.

The attempt-level calculation is:

new input       = 2,400 / 1,000,000 × $3.00  = $0.007200
cached input    =   600 / 1,000,000 × $0.30  = $0.000180
output          = 1,200 / 1,000,000 × $12.00 = $0.014400
PAYG attempt cost                         = $0.021780

The fixed cost of the existing 20-PTU allocation under the illustrative hourly rate is 20 × $1.00 × 730 = $14,600 for the month. That cost exists whether spillover is zero or large. The incremental decision is different: five more PTUs would cost 5 × $1.00 × 730 = $3,650 in this scenario.

At 10,000 spillover attempts, PAYG overflow is $217.80. If a 10% retry rate results in 11,000 standard-deployment attempts, the cost is $239.58. At 100,000 attempts, it is $2,178.00. All three are below the illustrative $3,650 marginal-PTU cost. At about 167,585 attempts with this token mix and these assumed rates, the two marginal options are approximately equal.

This does not mean spillover is always the right operational choice below that count. More PTUs could reduce latency, remove a quota bottleneck, or protect a contractual SLO. Conversely, the extra PTUs could be unavailable in the region, or their effective reservation rate could differ. Microsoft says PTU capacity and quota are distinct, and available capacity can change over time. ^[2] Treat the dollar threshold as one input to a capacity decision, not as a promise about performance.

How to use the calculator without hiding spillover

The Azure OpenAI cost and PTU calculator is useful for establishing a baseline token scenario. Enter the model and rate record, request volume, calls or steps per task, new input tokens, cached tokens, output tokens, retry rate, and PTU assumptions. The screenshot above shows why “steps or calls per task” and retry inputs must remain visible: they change billed attempts rather than only changing a presentation label.

For each monthly scenario, create two rows in your workbook. The first is PTU-served traffic and contains no PAYG token charge for those requests. The second is standard-served spillover and contains the actual token mix. If you only enter total monthly requests, you cannot tell whether an increase came from more traffic, a higher spillover share, longer prompts, more output, or retries.

Microsoft’s sizing guidance converts peak RPM, average prompt tokens, average response tokens, and cache rate into normalized TPM, then divides by the model’s input TPM per PTU. The documented formulas are useful for estimating a new PTU block, but they are not a substitute for the spillover ledger because a peak-sizing estimate and a monthly overflow count answer different questions. ^[3] Sizing asks how much capacity is needed; spillover budgeting asks what the residual traffic costs when capacity is exceeded.

Keep rates versioned by model, deployment type, region or data zone, currency, and effective date. The model pricing comparison can help you compare rate records, while the AI token cost calculator is useful for testing how prompt and completion mix changes the per-attempt amount. For a complete workflow cost rather than one model call, use the LLM cost calculator and add the spillover attempts as a separate line item.

A practical break-even workflow

First, measure a representative period rather than extrapolating from one incident. Export standard-deployment usage and join it to the PTU source deployment using spillover headers or the gateway’s request metadata. Summarize attempts by model version and token class. If the model changes, do not blend old and new rates into one average without a dated weighting.

Second, calculate the marginal PTU cost using the actual increment available for that deployment type. The smallest deployable increment can be larger than one PTU. Microsoft’s sizing page documents model-specific minimums and scale increments, so the decision may be “add 5 PTUs” or “add 25 PTUs,” not “add exactly the calculated fractional PTU.” ^[3]

Third, calculate a distribution rather than only a mean. A short prompt with a long completion may be more expensive than a long prompt with a short completion, especially when output-to-input capacity ratios differ by model. Microsoft notes that output tokens can consume more PTU capacity than input tokens and that cache treatment is model-specific. ^{[2] [3]} Use P50, P95, and worst-observed token shapes in separate scenarios.

Finally, compare three outcomes: keep spillover, add the marginal PTU block, or change the traffic policy. A per-request header can let you reserve spillover for latency-sensitive or revenue-critical calls while keeping batch work on a different path. The policy choice should name its fail behavior: return the PTU error, spill to standard, retry with backoff, or route to another deployment. If the app retries after the gateway already spilled, count the second standard attempt separately.

Limitations and exclusions

This method estimates Azure model-serving charges only. It excludes Azure Monitor, API Management, gateway, network, storage, orchestration, human review, and application engineering costs. It also excludes the business cost of latency, failed requests, and degraded standard-deployment performance.

The worked rates are explicit assumptions, not a vendor quote. The Azure pricing page says public prices can change and may not match a customer’s agreement. ^[4] Replace them with the correct model-version and deployment-type rate record. Cached-input treatment also varies by model and billing record; do not infer a cache discount from a different model.

The method does not infer that every 429 is spillable. Verify that a matching standard deployment is configured, that the request policy enables spillover, and that the response headers identify the route. Microsoft’s documentation describes spillover triggers and identifies the final standard response when the fallback also fails. ^[1] A retry policy that is external to Azure can create additional attempts and must be measured independently.

FAQ

Is Azure OpenAI PTU spillover free?

No. The spillover feature does not add a separate surcharge in the documented billing model, but the standard deployment that serves overflow is billed at its token rates. PTU-served requests remain covered by the provisioned hourly or reservation charge, while standard-served requests add input, cached, and output token charges. ^{[1] [5]}

Does a PTU 429 mean I pay twice for one request?

Not automatically. If the service routes the request to standard and standard successfully serves it, the standard attempt is token-billed and the PTU allocation remains a fixed cost. That is two billing components for the overall architecture, not necessarily two token charges for one successful attempt. If your client independently retries and the retry reaches standard, that is another provider attempt and should be reconciled as such.

How should I budget retries and duplicate requests?

Budget attempts, not only logical tasks. Multiply the number of standard-served attempts by the token cost of the observed attempt shape. Keep an attempt ID, parent task ID, retry number, deployment name, and usage tokens. If a duplicate response is discarded by the application, retain its usage in the cost ledger unless the provider’s usage record proves no billable processing occurred.

When is buying more PTUs cheaper than PAYG spillover?

Calculate the monthly cost of the smallest additional PTU block and divide it by the PAYG cost of one standard-served attempt. In the worked assumptions, five PTUs cost $3,650 per month and one overflow attempt costs $0.021780, so the threshold is about 167,585 attempts per month. Recalculate with your model’s rates, token mix, hours, reservation term, and deployment increment.

Does spillover apply only to 429 responses?

No. Microsoft documents 429 capacity exhaustion as one trigger and also describes selected 400, 500, and 503 paths. ^[1] Track the trigger code so the budget explains whether overflow came from capacity, long context, or a service error. Do not label all standard traffic as 429 spillover without that evidence.

Can I enable spillover for every Azure OpenAI deployment?

Check the current model and deployment documentation. Microsoft’s current Foundry documentation says spillover is supported for Azure OpenAI models that support provisioned throughput, and it requires a corresponding standard deployment in the same Foundry resource. ^[1] Region, deployment type, model version, quota, and capacity still need verification before you treat a configuration as available.