GPT-5.6 Luna on Foundry: PTU Sizing, PayGo vs. PTU + Spillover Pricing

A quick note before we start: While this article focuses on GPT-5.6 Luna to make the pricing and PTU calculations concrete, the same methodology applies to other models when their model-specific throughput and pricing values are substituted.

Provisioned Throughput provides a dedicated, fixed amount of processing capacity exclusively for your model deployment. Unlike Standard/PayGo, it provides a model-specific latency SLA, and its capacity is not shared across tenants.

Input	Description
Model and Version
The model determines which Input TPM per PTU and output-to-input ratio values to use. Each model has a
Deployment type
The provisioned deployment type: Global Provisioned, Data Zone Provisioned, or Regional Provisioned.
Peak RPM
The expected peak number of calls per minute sent to the model.
Average prompt size
The average number of input tokens per request.
Average response size
The average number of output tokens per request.
Cache rate
The percentage of input tokens served from the prompt cache. Cached tokens don't consume any PTU capacity.

FORMULAS
Input TPM = Peak RPM × Average input tokens per request
Output TPM = Peak RPM × Average output tokens per request
Effective Input TPM = Input TPM × (1 - Cache rate )
Normalized TPM = Effective Input TPM + (Output-to-input ratio × Output TPM )
Estimated PTUs = Normalized TPM / Input TPM per PTU

Note:Input TPM

is the workload-specific calculated volume, whereasInput TPM per PTU

is a model-specific sizing constant. For example, some listedInput TPM per PTU

values are 30,000 for GPT-5.6 Luna, 3,000 for GPT-5.6 Terra, and 1,200 for GPT-5.6 Sol.

Representative sample:

Let's suppose your application sends requests at a peak rate of 1,000 RPM, with an average prompt size of 1,200 tokens and an average response size of 200 tokens, using the gpt-5.6-luna model with a Global Provisioned deployment.

Based on the Microsoft Foundry PTU sizing table, gpt-5.6-luna

has these constants:

GPT-5.6 LUNA SIZING CONSTANT	VALUE
Input TPM per PTU	30,000
Output-to-input ratio	6
Minimum Global Provisioned deployment	15 PTUs
Global Provisioned scale increment	5 PTUs

CALCULATION
Input TPM = 1,000 × 1,200 = 1,200,000
Output TPM = 1,000 × 200 = 200,000
Normalized TPM = 1,200,000 + (6 × 200,000) = 2,400,000
Estimated PTUs = 2,400,000 / 30,000 = 80 PTUs
PTUs deployed = 80 PTUs

CALCULATION
Input TPM = 1,000 × 1,200 = 1,200,000
Effective Input TPM = 1,200,000 × (1 - 0.50) = 600,000
Output TPM = 1,000 × 200 = 200,000
Normalized TPM = 600,000 + (6 × 200,000) = 1,800,000
Estimated PTUs = 1,800,000 / 30,000 = 60 PTUs
PTUs deployed = 60 PTUs

Peak RPM	Prompt size	Response size	Cache rate	Effective Input TPM	Output TPM	Normalized TPM	Estimated PTUs	PTUs deployed
1,000	1,200	200	0%	1,200,000	200,000	2,400,000	80.00	80
1,000	1,200	200	50%	600,000	200,000	1,800,000	60.00	60

Representative sample: Let's suppose traffic fluctuates between 0 and 2,500 RPM over a typical 24-hour period, with an average input size of 1,200 tokens and an average response size of 200 tokens, using the gpt-5.6-luna model with a Global Standard (pay-as-you-go) deployment. For the 30-day estimate, this daily traffic profile is assumed to repeat every day.

We'll also assume that 50% of input tokens are cache reads and the remaining 50% are cache misses. Of all input tokens, 10 percentage points are cache writes, leaving 40 percentage points as regular input that is neither read from nor written to the cache. Prompt caching applies only to input tokens; output tokens are always charged at the regular output-token rate.

Illustrative RPM distribution over 24 hours
(RPM changes every 4 hours)

2500 ┤                         ██████
2250 ┤                         ██████
2000 ┤                         ██████  ██████
1750 ┤                         ██████  ██████
1500 ┤                         ██████  ██████
1250 ┤                         ██████  ██████
1000 ┤                 ██████  ██████  ██████  ██████
 750 ┤                 ██████  ██████  ██████  ██████
 500 ┤         ██████  ██████  ██████  ██████  ██████
 250 ┤         ██████  ██████  ██████  ██████  ██████
   0 ┼─────────────────────────────────────────────────
HOUR │ 00–04 │ 04–08 │ 08–12 │ 12–16 │ 16–20 │ 20–24
 RPM │     0 │   500 │ 1,000 │ 2,500 │ 2,000 │ 1,000

For Standard/PayGo rates, as of August 27, 2026, the Azure OpenAI pricing page lists these USD rates for gpt-5.6-luna

Global Standard:

Meter	Symbol	Price per 1M tokens
Regular input	P_regular
$0.20
Cached input	P_cached
$0.02
Cache writes	P_write
$0.25
Output	P_output
$1.20

50% cache reads + 10% cache writes + 40% regular input = 100%

Symbol	Description
RPM
Requests per minute
a.i.T , a.o.T
Average input and output tokens per request
Hours
Duration of the batch in hours
r_cached , r_write
Cache-read and cache-write rates
C_batch
Total input-and-output token cost for one batch

Formula	Calculation
Total input tokens
T_input = RPM × a.i.T × 60 × Hours
Cached input tokens
T_cached = T_input × r_cached
Cache-write input tokens
T_write = T_input × r_write
Regular input tokens
T_regular = T_input - T_cached - T_write
Total output tokens
T_output = RPM × a.o.T × 60 × Hours
Batch cost
C_batch = (T_regular ·P_regular + T_cached ·P_cached + T_write ·P_write + T_output ·P_output ) / 1,000,000

Each column represents one 4-hour batch on a typical day. The daily traffic profile is assumed to repeat itself for 30 days. Token values are shown in billions (B).

Metric	00–04	04–08	08–12	12–16	16–20	20–24	Total per day
Batch duration
4 hours	4 hours	4 hours	4 hours	4 hours	4 hours	24 hours
RPM
0	500	1,000	2,500	2,000	1,000	—
T_regular
0	0.05760B	0.11520B	0.28800B	0.23040B	0.11520B	0.80640B
T_cached
0	0.07200B	0.14400B	0.36000B	0.28800B	0.14400B	1.00800B
T_write
0	0.01440B	0.02880B	0.07200B	0.05760B	0.02880B	0.20160B
T_output
0	0.02400B	0.04800B	0.12000B	0.09600B	0.04800B	0.33600B
C_4-hour batch
$0.00	$45.36	$90.72	$226.80	$181.44	$90.72	$635.04

30-day token totals:

• Regular input ( T_regular

):24.19200B- Cached input ( T_cached

):30.24000B- Cache writes ( T_write

):6.04800B- Output ( T_output

):10.08000B

Estimated pay-as-you-go cost per day: $635.04.

Estimated cost per 30-day month: $19,051.20.

Estimated cost per 365-day year: $231,789.60.

The following Sweden Central PTU rates were retrieved on August 27, 2026, using the Azure Retail Prices API. Sample queries and commands are included in the Appendix as a reference.

Tier	Retail API rate	Monthly equivalent per PTU
Hourly PTU	$1.00/PTU/hour	$720.00
Monthly reservation	$260.00/PTU/month	$260.00
One-year reservation	$2,652.00/PTU/year	$221.00

The hourly PTU monthly equivalent assumes 720 hours (30 days).

Warning:Hourly, non-reserved PTU is best suited to temporary or uncertain workloads, such as testing, benchmarking, capacity validation, short pilots, or migration exercises.

Let's take 250 RPM as the provisioned baseline and use Standard/PayGo spillover for bursts above it.

CALCULATION
Input TPM = 250 × 1,200 = 300,000
Effective Input TPM = 300,000 × (1 - 0.50) = 150,000
Output TPM = 250 × 200 = 50,000
Normalized TPM = 150,000 + (6 × 50,000) = 450,000
Estimated PTUs = 450,000 / 30,000 = 15 PTUs
Provisioned baseline = 15 PTUs

Time	Incoming RPM	Normalized TPM Demand	15-PTU Capacity (Normalized TPM)	Potential Spillover Demand
00–04	0	0	450,000	0
04–08	500	900,000	450,000	450,000
08–12	1,000	1,800,000	450,000	1,350,000
12–16	2,500	4,500,000	450,000	4,050,000
16–20	2,000	3,600,000	450,000	3,150,000
20–24	1,000	1,800,000	450,000	1,350,000

Incoming traffic ──▶ 15-PTU deployment (450,000 normalized TPM capacity)
                  X
                  X if throttled (HTTP 429)
                  │
                  └──▶ Automated Spillover to Standard/PayGo deployment if configured

Important:Spillover is optional and must be configured either for the provisioned deployment or per request. Once configured, Microsoft Foundry automatically routes eligible requests that the provisioned deployment cannot serve—such as requests receiving HTTP 429, 500, or 503—to the associated Standard deployment. Without this configuration, the application must implement its own fallback logic.

Pricing option	Retail API rate	1 PTU/month	15 PTUs/month	15 PTUs/day (approx.)
Hourly PTU	$1.00/PTU/hour	$720.00	$10,800.00	$360.00
Monthly reservation	$260.00/PTU/month	$260.00	$3,900.00	$130.00
One-year reservation	$2,652.00/PTU/year	$221.00	$3,315.00	$108.99

Monthly cost of a

yearly PTU reservationis an approximate equivalent calculated by dividing the annual price by 12.Daily cost of a

yearly PTU reservationis an approximate equivalent calculated by dividing the annual price by 365.Daily cost of

monthly PTU reservationis a rough estimation calculated by dividing the monthly price by 30.

Metric	00–04	04–08	08–12	12–16	16–20	20–24	Daily total
Incoming RPM
0	500	1,000	2,500	2,000	1,000	—
Estimated spillover RPM
0	250	750	2,250	1,750	750	—
T_regular
0	0.02880B	0.08640B	0.25920B	0.20160B	0.08640B	0.66240B
T_cached
0	0.03600B	0.10800B	0.32400B	0.25200B	0.10800B	0.82800B
T_write
0	0.00720B	0.02160B	0.06480B	0.05040B	0.02160B	0.16560B
T_output
0	0.01200B	0.03600B	0.10800B	0.08400B	0.03600B	0.27600B
C_PTU reservation
$21.67	$21.67	$21.67	$21.67	$21.67	$21.67	$130.00
C_PayGo spillover
$0.00	$22.68	$68.04	$204.12	$158.76	$68.04	$521.64
C_PTU + spillover
$21.67
$44.35
$89.71
$225.79
$180.43
$89.71
$651.64

Daily estimate using a monthly reservation:The $3,900 monthly PTU reservation amortizes to$130.00 per dayover a 30-day month. Estimated PayGo spillover is$521.64 per day, for a combined daily estimate of$651.64.

30-day estimate using a monthly reservation:PTU reservation$3,900.00; PayGo spillover$15,649.20; combined cost$19,549.20.

365-day estimate using a one-year reservation:PTU reservation$39,780.00; PayGo spillover$190,398.60; combined cost$230,178.60.Interval amounts are rounded independently. Daily and longer-term totals are calculated using unrounded values. Actual throughput and costs can vary with request concurrency, token-length distribution, caching behavior, model version, regional pricing, and throttling characteristics.

Let's take 500 RPM as the provisioned baseline and use Standard/PayGo spillover for bursts above it.

CALCULATION
Input TPM = 500 × 1,200 = 600,000
Effective Input TPM = 600,000 × (1 - 0.50) = 300,000
Output TPM = 500 × 200 = 100,000
Normalized TPM = 300,000 + (6 × 100,000) = 900,000
Estimated PTUs = 900,000 / 30,000 = 30 PTUs
Provisioned baseline = 30 PTUs

Time	Incoming RPM	Normalized TPM Demand	30-PTU Capacity (Normalized TPM)	Potential Spillover Demand
00–04	0	0	900,000	0
04–08	500	900,000	900,000	0
08–12	1,000	1,800,000	900,000	900,000
12–16	2,500	4,500,000	900,000	3,600,000
16–20	2,000	3,600,000	900,000	2,700,000
20–24	1,000	1,800,000	900,000	900,000

Incoming traffic ──▶ 30-PTU deployment (900,000 normalized TPM capacity)
                  X
                  X if throttled (HTTP 429)
                  │
                  └──▶ Automated Spillover to Standard/PayGo deployment if configured

Important:Spillover is optional and must be configured either for the provisioned deployment or per request. Once configured, Microsoft Foundry automatically routes eligible requests that the provisioned deployment cannot serve—such as requests receiving HTTP 429, 500, or 503—to the associated Standard deployment. Without this configuration, the application must implement its own fallback logic.

Pricing option	Retail API rate	1 PTU/month	30 PTUs/month	30 PTUs/day (approx.)
Hourly PTU	$1.00/PTU/hour	$720.00	$21,600.00	$720.00
Monthly reservation	$260.00/PTU/month	$260.00	$7,800.00	$260.00
One-year reservation	$2,652.00/PTU/year	$221.00	$6,630.00	$217.97

Monthly cost of a

yearly PTU reservationis an approximate equivalent calculated by dividing the annual price by 12.Daily cost of a

yearly PTU reservationis an approximate equivalent calculated by dividing the annual price by 365.Daily cost of

monthly PTU reservationis a rough estimation calculated by dividing the monthly price by 30.

Metric	00–04	04–08	08–12	12–16	16–20	20–24	Daily total
Incoming RPM
0	500	1,000	2,500	2,000	1,000	—
Estimated spillover RPM
0	0	500	2,000	1,500	500	—
T_regular
0	0	0.05760B	0.23040B	0.17280B	0.05760B	0.51840B
T_cached
0	0	0.07200B	0.28800B	0.21600B	0.07200B	0.64800B
T_write
0	0	0.01440B	0.05760B	0.04320B	0.01440B	0.12960B
T_output
0	0	0.02400B	0.09600B	0.07200B	0.02400B	0.21600B
C_PTU reservation
$43.33	$43.33	$43.33	$43.33	$43.33	$43.33	$260.00
C_PayGo spillover
$0.00	$0.00	$45.36	$181.44	$136.08	$45.36	$408.24
C_PTU + spillover
$43.33
$43.33
$88.69
$224.77
$179.41
$88.69
$668.24

Daily estimate using a monthly reservation:The $7,800 monthly PTU reservation amortizes to$260.00 per dayover a 30-day month. Estimated PayGo spillover is$408.24 per day, producing a combined daily estimate of$668.24.

30-day estimate using a monthly reservation:PTU reservation$7,800.00; PayGo spillover$12,247.20; combined cost$20,047.20.

365-day estimate using a one-year reservation:PTU reservation$79,560.00; PayGo spillover$149,007.60; combined cost$228,567.60.Interval amounts are rounded independently. Daily and longer-term totals are calculated using unrounded values. Actual throughput and costs can vary with request concurrency, token-length distribution, caching behavior, model version, regional pricing, and throttling characteristics.

Period and pricing basis	PayGo only	250-RPM baseline (15 PTUs) + spillover	Difference vs. PayGo	500-RPM baseline (30 PTUs) + spillover	Difference vs. PayGo
Daily — monthly reservation	$635.04	$651.64	+$16.60 (+2.61%)
$668.24	+$33.20 (+5.23%)
30-day month — monthly reservation	$19,051.20	$19,549.20	+$498.00 (+2.61%)
$20,047.20	+$996.00 (+5.23%)
365-day year — one-year reservation	$231,789.60	$230,178.60	−$1,611.00 (−0.70%)
$228,567.60	−$3,222.00 (−1.39%)

With monthly reservation pricing, PayGo-only is the least expensive option. The 250-RPM baseline costs $498.00 more per 30-day month, while the 500-RPM baseline costs $996.00 more.

With one-year reservation pricing, the result reverses. The 250-RPM baseline saves $1,611.00 per year relative to PayGo-only, while the 500-RPM baseline saves $3,222.00 per year. Under this representative traffic profile, the 500-RPM baseline therefore provides the lowest annual cost of the three options.

If cost is the primary objective, use PTUs to cover the workload's stable, sustained baseline and route variable or burst traffic to PayGo. Avoid reserving PTUs for capacity that may remain idle; each additional PTU block should save more in PayGo charges than it costs to reserve.

That said, cost is not the only objective of PTUs. A correctly sized provisioned deployment also provides dedicated throughput, more predictable latency, a defined latency SLA, and more consistent benchmark results than shared PayGo capacity. The best choice therefore depends on both economics and performance requirements.

You are billed on PTUs deployed, not tokens processed: an idle deployment costs exactly the same as a saturated one. Deployments cannot be d, so under hourly billing, charges stop only when the deployment is deleted.

Reservations and deployments are created independently, with two consequences:

Scaling down also releases capacity back to the regional pool with no guarantee of reclaiming it, so cycling a production deployment up and down is a poor cost-control strategy. A reservation on a steady deployment is usually cheaper and safer.

{
    curl -s "https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview&\$filter=productName%20eq%20%27Azure%20OpenAI%27%20and%20armRegionName%20eq%20%27swedencentral%27"

    curl -s "https://prices.azure.com/api/retail/prices?api-version=2023-01-01-preview&\$filter=productName%20eq%20%27Azure%20AI%20Foundry%20Provisioned%20Throughput%20Reservation%27%20and%20armRegionName%20eq%20%27swedencentral%27"
} | jq -rs '
    ["Pricing option", "USD / PTU", "Reservation term"],
    (
        .[].Items[]
        | select(.skuName == "Provisioned Managed Global")
        | [
                (if .reservationTerm == null
                 then "Hourly"
                 else .reservationTerm
                 end),
                .retailPrice,
                (.reservationTerm // "None")
            ]
    )
    | @tsv'

source & further reading

dev.to — original article Building an x402-aware crawler in Go: what Cloudflare's Monetization Gateway means for web scraping My test report printed "0/96, 0% pass rate". The truth was my account was out of credit Feature detection lies: two things I learned shipping on WebMCP