Azure OpenAI Embeddings Metering and Billing Incident

We have identified an active and reproducible token metering and billing discrepancy affecting an Azure OpenAI deployment with the following configuration:

Region: France Central Model: text-embedding-ada-002, version 2 Deployment SKU: Standard API version: 2024-10-21 Billing meter: embedding-ada-regional Tokens

Historical Cost Management data reconciled with our application usage records within approximately 1% throughout June, July, and 1-25 August 2026. A clear and persistent change begins on 26 August 2026.

Historical comparison:

• June 2026: Azure/application ratio of 1.0097x - July 2026: Azure/application ratio of 1.0073x - 1-25 August 2026: Azure/application ratio of 1.0061x - 26-31 August 2026: Azure/application ratio of 1.8030x - 1-28 September 2026: Azure/application ratio of 1.8167x

On 25 August, Azure recorded 145,180,039 tokens compared with 143,909,683 application tokens, a ratio of 1.0088x. On 26 August, Azure recorded 265,723,156 tokens compared with 150,761,281 application tokens, increasing the ratio to 1.7625x. The discrepancy continued on subsequent days.

We also reproduced the issue with a controlled direct REST request on 29 September 2026. This test bypassed LangChain and all higher-level application libraries.

Controlled test results:

• Requests submitted: 1 - Local cl100k_base token count: 4,002 - Azure API usage.prompt_tokens: 4,002 - Azure API usage.total_tokens: 4,002 - Embedding vectors returned: 1 - Vector dimensions: 1,536 - Request window: 2026-09-29T12:15:12.932Z to 2026-09-29T12:15:13.511Z

The local tokenizer and the Azure REST response agreed exactly that the request contained and consumed 4,002 tokens.

However, Azure Monitor recorded one request but 8,004 tokens in every relevant token metric:

• AzureOpenAIRequests: 1 - InputTokens: 8,004 - ProcessedPromptTokens: 8,004 - TokenTransaction: 8,004 - TotalTokens: 8,004

This demonstrates that a single 4,002-token request was represented as 8,004 tokens in Azure Monitor. The client and service request identifiers are available through a private support channel for backend correlation.

For the complete UTC days from 1 through 28 September 2026:

• Application tokens logged immediately before requests: 3,175,592,812 - Tokens associated with successful calls: 3,157,661,862 - Tokens persisted by the application: 3,130,907,783 - Azure Monitor InputTokens: 6,354,834,803 - Azure billed meter quantity: 5,687,878,348 tokens

Azure Monitor is 2.001149x the total number of tokens logged before all application requests. Dividing the Azure Monitor total by two produces a result that matches the application baseline within approximately 0.0575%.

The billed quantity is 1.791123x the application-sent tokens. It exceeds all application-observed attempts by 2,512,285,536 tokens, or 79.11%.

Preliminary financial impact:

• Actual Azure cost for 1-28 September: EUR 590.9611 - Expected cost at the same realized meter rate: EUR 329.9388 - Demonstrated September excess cost: EUR 261.0223 - Estimated excess cost for 26-31 August: EUR 59.7492 - Preliminary total excess cost from 26 August through 28 September: approximately EUR 320.77

The August amount is an estimate because detailed pre-request application traces were not available for most of 26-31 August. Microsoft should perform the authoritative re-rating using backend request and billing records.

We evaluated the following potential causes:

1. LangChain or another client library: The issue was reproduced with a direct REST request, so LangChain is not required to trigger the duplication.
2. Local token estimation: The local tokenizer and the Azure REST response agreed exactly on 4,002 tokens during the controlled reproduction. The September aggregate also matches Azure Monitor divided by two within 0.0575%.
3. Hidden retries or failed requests: Failed and non-persisted processing account for an internal traceability gap of only 1.407%. This cannot explain the 79.11% billed excess or the controlled one-request reproduction.
4. Repeated application processing: Some legitimate embedding work is repeated by the application. However, every such request is already included in the application-sent baseline. It increases legitimate consumption but cannot explain Azure recording substantially more tokens than were submitted.
5. Another consumer or compromised credentials: We found no evidence of an additional consumer. The near-exact match between Azure Monitor divided by two and all application-sent tokens is inconsistent with a large volume of separate, unobserved traffic.

The available evidence therefore strongly indicates a problem within Azure telemetry or the Azure metering/rating pipeline. Only Microsoft can determine why Azure Monitor reports approximately 2.0x the submitted tokens while the rated billing quantity is approximately 1.8x.

We request that Microsoft:

1. Explain why one 4,002-token request produced 8,004 tokens in all Azure Monitor token metrics. 2. Re-rate all affected usage and issue the corresponding billing adjustment or credit. 3. Explain why Azure Monitor reports approximately 2.0x the submitted tokens while the billed quantity is approximately 1.8x. 4. Confirm the root cause and expected remediation date. 5. Confirm whether other resources, regions, subscriptions, deployments, or customers are affected.

The incident is still active and reproducible. It causes financial impact but no service outage.