Azure GPT-5.6 terra/luna cost-map rows carry OpenAI's prices, not Azure's published meters

[marty-sullivan]

What is wrong

azure/gpt-5.6-terra and azure/gpt-5.6-luna, along with their azure/us/ and azure/eu/ data-zone siblings, currently hold OpenAI's direct post-cut prices. Azure never made that cut.

OpenAI reduced Terra by 20% and Luna by 80% on 2026-07-30. #35481 then applied the same reduction to the twelve Azure rows on 2026-08-05. Its stated basis was that "Azure global historically mirrors OpenAI global for these models"; the Azure link it cites is a Microsoft Foundry availability announcement, not a pricing page. @mihidumh raised exactly this objection in a comment on the merged PR the next morning ("Azure has not updated their pricing yet, this should be reverted for now"), and the change is still on main and litellm_internal_staging today.

Evidence

Azure's public retail prices API is the authoritative list-price source, and it needs no authentication:

curl -sS -G "https://prices.azure.com/api/retail/prices" \
  --data-urlencode "currencyCode=USD" \
  --data-urlencode "\$filter=contains(productName,'Azure OpenAI') and armRegionName eq 'eastus2'"

Every GPT-5.6 meter still carries effectiveStartDate of 2026-07-01 as a single version, so there is no cut applied and none future-dated. The values are identical in eastus2, westus3 and swedencentral, so this is not a regional anomaly. Global Standard rates, per 1M tokens:

Model	Field	Azure meter	Cost map today	Error
terra	input	$2.50	$2.00	20% under
terra	output	$15.00	$12.00	20% under
terra	cache read	$0.25	$0.20	20% under
luna	input	$1.00	$0.20	5x under
luna	output	$6.00	$1.20	5x under
luna	cache read	$0.10	$0.02	5x under

The relevant meter names are 5.6 terra ShortCo Inp Std Gl 1M Tokens and siblings, where Gl is Global and DZ is Data Zone at exactly 1.1x, Std is Standard and PP is Priority Processing at exactly 2x, and ShortCo/LongCo are the base and above-272k tiers. Those exact 1.1x and 2x ratios hold across the whole family, which is a good indication the rows are live rather than stale. Sol was not cut by either vendor and is correct as it stands.

Impact

Any Azure deployment of GPT-5.6 Terra or Luna under-reports spend by 20% and 80% respectively, silently, on every request. Luna is the worse case because the map bills a fifth of the real rate.

#35481 also added test_generic_cost_per_token_azure_gpt56, which asserts the incorrect Azure global and EU data-zone values. The wrong numbers are now test-locked, so a straight revert of the JSON alone will fail CI; the test needs correcting in the same change.

The same root cause is about to land again in #35125

#35125 is open and adds the missing cache_creation_input_token_cost fields to all twelve Azure GPT-5.6 entries. The underlying gap is real, since Azure does publish cache-write meters and the map currently bills those tokens at zero. The Sol and base-alias values in that PR match Azure exactly, but the Terra and Luna values are OpenAI-derived in the same way as #35481:

Key	Field	Azure meter	#35125
azure/gpt-5.6-terra	cache write	$3.125	$2.50
azure/gpt-5.6-terra	cache write above 272k	$6.25	$5.00
azure/gpt-5.6-luna	cache write	$1.25	$0.25
azure/gpt-5.6-luna	cache write above 272k	$2.50	$0.50

Separately, that PR derives the data-zone _priority cache-write fields with a 2.5x multiplier where Azure's Priority Processing meters are exactly 2x Standard, so azure/us/gpt-5.6 and azure/eu/gpt-5.6 come out at $17.1875 against a published $13.75, and the Sol rows likewise.

Suggested fix

Restore the Terra and Luna token prices on all twelve Azure rows to the meter values in the first table, and correct test_generic_cost_per_token_azure_gpt56 to match. For #35125, resource the Terra and Luna cache-write numbers from the Cd Wr meters and use 2x rather than 2.5x for the Priority Processing fields.

More generally, an OpenAI price change is not evidence about Azure. The retail prices API query above is cheap, unauthenticated and definitive, and it is worth making the standard check before porting any price movement onto an azure/ row.

I am happy to open the PR for either part if that helps.

[mateo-berri]

Hi Marty, thank you for raising this issue

I personally also tested with the exact same API before making LiteLLM's price decrease for Azure and witnessed the same stale pricing issue.

We were told in an official statement from the Azure team that:

Effective August 1st, Azure OpenAl customers will receive the same updated price decreases for GPT 5.6 Luna and Terra models recently announced by OpenAl.
Azure is committed to continuing to price parity for applicable Azure OpenAl Services offerings. the pricing page will have ~2-week lag for this update, customers can see the pricing via the blog and invoicing/observability.

The update to Azure pricing was intentional, not accidental. Did you not observe a cheaper bill from Azure?

[marty-sullivan]

Correcting my own report, and adding an item I missed.

Where I was wrong

I described the Microsoft post as "a Microsoft Foundry availability announcement, not a pricing page". That is wrong. It carries a full GPT-5.6 pricing table, and that table lists Azure terra at $2/$12 and luna at $0.20/$1.20 per 1M, with the note "This pricing also reflects the latest discounts announced by OpenAI on 7/30". So #35481's values match Microsoft's own published Azure prices, and my request to revert it rested on a bad reading of its source. I withdraw that request

What is still genuinely open

Microsoft's sources disagree with each other, which is the part worth a deliberate decision rather than a revert.

The blog publishes the post-cut prices for Azure. The retail prices API does not: every gpt-5.6 terra and luna meter still carries a single effectiveStartDate of 2026-07-01 with no second version, identical in eastus2, westus3 and swedencentral. And actual billing agrees with the API, not the blog. Cost Management for a real Azure subscription, over 2026-08-01 to 08-06, well after the 7/30 cut:

meter	1M-tok billed	effective $/1M	blog says
5.6 terra ShortCo Inp Std Gl	48.30	2.5062	2.00
5.6 terra ShortCo Opt Std Gl	2.45	15.0375	12.00
5.6 luna ShortCo Inp Std Gl	162.96	1.0025	0.20
5.6 luna ShortCo Opt Std Gl	22.69	6.0150	1.20

Those rates are identical to a 2026-07-20 to 07-29 window, so nothing moved across the 7/30 boundary. The uniform 1.0025 factor over list appears on every meter including sol, so it is a small consistent uplift rather than a discount.

Sol is a useful control: never cut by either vendor, and the blog, the meters and the invoice all agree on it. The disagreement is confined to terra and luna, which is consistent with the blog table having had OpenAI's percentages applied to it.

The practical consequence is that anyone tracking Azure gpt-5.6 spend on the current map under-reports against what Azure actually invoices, by 20% on terra and 5x on luna, until Azure's billing catches up to the announcement. That may well be the right call given Microsoft advertises the lower price, and it is not for me to decide which source LiteLLM should track. It is worth deciding on purpose, and worth a comment in the map or the test if the answer is "follow the announcement"

The item I missed

No azure/gpt-5.6* row has cache_creation_input_token_cost, so Azure prompt-cache writes bill at $0 on every one of the twelve rows. These are real billable meters, not a hypothetical: the same invoice shows 5.6 terra ShortCo Cd Wr Std Gl, and the luna and sol equivalents, charging actual money. The blog publishes them too, at $6.25 for sol, $2.50 for terra and $0.25 for luna per 1M global.

Cache write is uniformly 1.25x the input price for this family in every source, on the meters and in the blog alike, which is the same relationship the openai gpt-5.6 rows already encode.

#35125 is open and adds exactly these fields, and its terra and luna values match the blog. Two things look worth fixing there before it merges. Its data-zone _priority cache-write fields are derived with a 2.5x multiplier where this family's Priority Processing meters are exactly 2x Standard, so azure/us/gpt-5.6 and azure/eu/gpt-5.6 come out at $17.1875 against a published $13.75, and the sol rows the same way. And whichever basis is chosen for terra and luna, the token prices and the cache-write column need to come from the same one, because mixing them breaks the 1.25x ratio: #35481's token prices combined with meter-derived cache writes would have luna billing cache writes at 6.25x its own input rate.

Happy to open a PR for the cache-write fields against whichever basis the maintainers prefer, or to leave it to #35125 if that one is close to landing

[mmarras]

Yes this is wrong:

The entry for azure/gpt-5.6-luna (and the azure/us/ and azure/eu/ variants)
prices the model well below what Azure publishes.

In the table:

"input_cost_per_token":  2.2e-07,   // $0.22 / 1M
"output_cost_per_token": 1.32e-06,  // $1.32 / 1M
"cache_read_input_token_cost": 2.2e-08

On Azure's pricing page, GPT-5.6-luna (short context, Data Zone):

	published	table
input / 1M	€0.97	$0.22	4.4×
output / 1M	€5.80	$1.32	4.4×
cached input / 1M	€0.10	$0.022	4.5×

Two things suggest this is not simply a tier we are reading wrong:

• the gap is uniform across every field, cached reads included, which looks
  more like a scale error than a deployment-type difference;
• the out:in ratio is identical in both (~6.0), i.e. it is the same model priced
  on a different basis rather than a different model.

Deployment type may still explain it — Global Standard is cheaper than Data Zone
— but a 4.4× spread seems large for that, and the entry carries no marker saying
which basis it is on. If it is intentionally Global Standard, it would help to
say so, since consumers reading it as "the price of this model" will be out by
4.4× on any other deployment type.

Reported from a downstream tool that shows users a running cost estimate: it read
$0.46 for a session that was billed $2.08.

[marty-sullivan]

So definitively, Azure does publish a blog that shows the reduced pricing, but it clearly isn't actually being reflected in the billing nor their actual pricing pages. This is a pure Azure / Microsoft failure

[mmarras]

Adding a Microsoft source and correcting my earlier comment.

I argued from the Azure pricing page. That page is stale, as @mateo-berri and @marty-sullivan already established above, so my comparison was against the wrong number and I withdraw it.

Microsoft's own Q&A on why the page was not updated: https://learn.microsoft.com/en-us/answers/questions/5963447/why-microsoft-didnt-update-the-gpt-5-6-luna-terra

That leaves the one thing this thread has not settled: what customers are actually billed. Page and blog disagree, and only an invoice resolves it.

[mateo-berri]

Hi we dug deeper into this

A customer's invoice suggests the new rates, so we're keeping the new lower rates. We're meeting Azure tomorrow to get more clarity on this. In the meantime, please override input_cost_per_token/output_cost_per_token if yours differs

[marty-sullivan]

@mateo-berri thanks! I think an update may also be needed for the cache write pricing so if you're able to clarify that as well, that may need to be updated in the cost map for these two models. Currently, those are set to the higher pricing still for these two models in Azure.

[Pyrax]

@mateo-berri is there any update you can share with us from the Azure meeting?