[BUG] GPT-5.6 metering: cached tokens double-billed on full-price Inp Std meter

### API Spec link https://github.com/Azure/azure-rest-api-specs/tree/main/specification/consumption/resource-manager ### API Spec version 2023-05-01 ### Describe the bug For the newly launched **GPT-5.6 Sol Global Standard meter family**, the quantities returned by `Microsoft.Consumption/usageDetails` show that the rating pipeline places the deployment's **entire input token count** on the full-price input meter (`Inp Std`, $5.00/1M) and **additionally** rates the cached-input and cache-write quantities on their own meters (`Cd Inp Std` $0.50/1M, `Cd Wr Std` $6.25/1M). Result: input-side rated quantity ≈ **2× the tokens the deployment actually processed** (per Azure Monitor `InputTokens` and per the API's own `usage.cached_tokens` fields). Cached tokens are effectively billed at $5.50/1M and cache-write tokens at $11.25/1M — contradicting the published rates and the prompt-caching documentation. **Affected meters** (Global Standard, ShortCo, effective 2026-07-01; rates verified against `https://prices.azure.com/api/retail/prices` — the rates are correct and not disputed, the rated QUANTITY on `Inp Std` is wrong): | Meter | MeterId | Published rate | |---|---|---| | 5.6 sol ShortCo **Inp Std** Gl 1M Tokens | `cd1696d5-9956-5121-a0ec-f0940beee306` | $5.00 / 1M | | 5.6 sol ShortCo **Cd Inp Std** Gl 1M Tokens | `4f38fdce-1b5c-5343-abdc-74f893f29602` | $0.50 / 1M | | 5.6 sol ShortCo **Cd Wr Std** Gl 1M Tokens | `a6f9beb8-1a7b-5f8a-83e5-bd1c31d4a713` | $6.25 / 1M | | 5.6 sol ShortCo **Opt Std** Gl 1M Tokens | `fb483d52-8a48-5fa9-8abd-f16eb0e5508a` | $30.00 / 1M | This appears **systemic to the GPT-5.6 meter family**, not account-specific: an independent customer reported on Microsoft Q&A ([question 5949956](https://learn.microsoft.com/en-au/answers/questions/5949956/), posted 2026-07-17, [archived 2026-07-20 (https://web.archive.org/web/20260720091218/https://learn.microsoft.com/en-au/answers/questions/5949956/is-gpt-5-6-standard-global-pricing-currently-0-01)) that GPT-5.6 Sol/Luna/Terra Global Standard meters initially carried uniform unvalidated `$0.01/1M` placeholder rates across all four token categories, while GPT-5.5 meters in the same export showed correct differentiated rates. The timeline is consistent with: meters launched with placeholder rates → rates published/re-rated effective 2026-07-01 → re-rating placed **total** input on the full-price meter instead of the ordinary-input residual. An active Microsoft billing support case covers the same defect on my account (case numbers available to Microsoft staff on request). This issue is filed as the public record of a defect that evidently affects multiple customers. **Questions for the metering/pricing team:** 1. What is the intended rating formula for `Inp Std` vs `Cd Inp Std` vs `Cd Wr Std` on the GPT-5.6 meter family? (`Inp Std` = ordinary residual only, per the published pricing and prompt-caching docs?) 2. Why is `Inp Std` currently rated with the deployment's total input quantity while the cached/cache-write quantities are simultaneously rated on their own meters? 3. Was a retroactive re-rating applied to GPT-5.6 meters (from the `$0.01/1M` placeholder rates reported in Q&A 5949956), and did that re-rating introduce the quantity overlap? 4. Is a fix and re-rate planned for all affected customers of the GPT-5.6 Sol/Luna/Terra meter family? ### Expected behavior Per the published pricing (<https://azure.microsoft.com/en-us/pricing/details/azure-openai/>, [archived 2026-07-30](https://web.archive.org/web/20260730103839/https://azure.microsoft.com/en-us/pricing/details/azure-openai/)) and the prompt-caching documentation (<https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching>, [archived 2026-07-30](https://web.archive.org/web/20260730103829/https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/prompt-caching)), each input token is billed **once, in its category**: cache reads at the discounted cached-input rate, cache writes at the cache-write rate, and only the **ordinary (uncached, non-cache-write) residual** at the full input rate. Expected rating for my July 1–20 sample (1,700.83M total input tokens per Azure Monitor): | Category | Quantity | Rate | Expected USD | |---|---:|---:|---:| | Ordinary input (`Inp Std`) | 1.974 M | $5.00/1M | 9.87 | | Cached input (`Cd Inp Std`) | 1,524.96 M | $0.50/1M | 762.48 | | Cache writes (`Cd Wr Std`) | 173.90 M | $6.25/1M | 1,086.86 | | Output (`Opt Std`) | 3.60 M | $30.00/1M | 107.87 | | **Total** | | | **~1,967** | The rated quantity on any single input meter can never exceed the deployment's total input tokens reported by Azure Monitor for the same period. ### Actual behavior `usageDetails` rated quantities for the same deployment and period (July 1–20, 2026): | Meter | Rated quantity | Rated cost (EUR) | |---|---:|---:| | Inp Std | **1,700.83 M** | 7,463.05 | | Cd Inp Std | 1,524.96 M | 669.13 | | Cd Wr Std | 173.90 M | 953.81 | | Opt Std | 3.60 M | 94.66 | | **Input-side total rated** | **3,399.69 M** | | Azure Monitor `InputTokens` for the same deployment and period: **1,700,829,776** (output 3,594,802 — matching the `Opt Std` meter exactly, proving telemetry and the output meter agree; only the input side is defective). **In one line:** Azure Monitor says 1,700.83M input tokens existed; the input-side meters rated 3,399.69M tokens for them. **A daily identity holds across the entire period:** ``` Inp Std quantity = Cd Inp Std quantity + Cd Wr Std quantity (every single day) 1,700.83 M ≈ 1,524.96 M + 173.90 M (+ 1.97M ordinary input) ``` i.e. `Inp Std` is fed **total** input tokens (cached + cache-writes + ordinary) instead of the ordinary-input residual (~1.97M), and the cached and cache-write quantities are then rated a **second time** on their own meters. Cross-check with the service API itself: aggregated `usage` objects from 6,952 API responses in the period report 1,553.1M `cached_tokens` out of 1,701.5M total input (91% cache hit rate) — matching Azure Monitor and the `Cd Inp Std`/`Cd Wr Std` quantities, and confirming the ordinary-input residual is ~2M tokens, not 1,700M. Actual rated total: **~$10,461** vs expected **~$1,967** — duplicate portion **~$8,494 (≈ €7,454)** for a single deployment in 19 days. If the current rating were intentional, the effective prices would be $5.50/1M for cached input and $11.25/1M for cache writes — contradicting the published $0.50 and $6.25 rates. ### Reproduction Steps ```bash # 1. Actual tokens processed (Azure Monitor) az monitor metrics list \ --resource "<AIServices resource id>" \ --metric "InputTokens" --interval P1D \ --start-time 2026-07-01T00:00:00Z --end-time 2026-07-20T00:00:00Z \ --dimension ModelDeploymentName # → note total input tokens for the gpt-5.6 deployment # 2. Rated quantities (Consumption usageDetails) az rest --method get --url \ "https://management.azure.com/subscriptions/<sub>/providers/Microsoft.Consumption/usageDetails?api-version=2023-05-01&\$filter=properties/usageStart ge '2026-07-01'" # → filter meterId cd1696d5-9956-5121-a0ec-f0940beee306 (Inp Std): # its quantity equals TOTAL input tokens, not the uncached residual, # while 4f38fdce (Cd Inp Std) and a6f9beb8 (Cd Wr Std) are ALSO rated. # 3. Published rates (public, unauthenticated) curl "https://prices.azure.com/api/retail/prices?\$filter=meterId eq 'cd1696d5-9956-5121-a0ec-f0940beee306'" ``` Compare (1) vs (2): the `Inp Std` rated quantity equals the deployment's total input tokens while two other input-side meters are rated on top of it. Raw sanitized evidence (usageDetails / Monitor / Retail Prices API JSON responses, SHA-256 manifest) available on request or as a gist. ### Environment - Service: Azure OpenAI in Foundry Models (AIServices, S0), region Sweden Central - Deployment: gpt-5.6-sol, GlobalStandard - Billing: Microsoft Customer Agreement (MCA), billing currency EUR - Observation window: 2026-07-01 → 2026-07-20 (defect still present in rated usage as of 2026-07-30) - Data sources: Azure Monitor metrics API, Microsoft.Consumption usageDetails (api-version 2023-05-01), Azure Retail Prices API - Tooling: Azure CLI (az) — no SDK/IDE involved; this is a service-side metering defect, not a client issue